BazingaLyncc

四月份花了大概一个月的时间翻译了2015年12月出版的《Netty in Action》 说实话，翻译完了，感觉只是对Netty有了一些初步的了解，对Netty的模型在脑海中也是有了初步的雏形，好记性不如烂笔头，这两个月就准备系统的学习一下Netty，学习到什么程度，我自己也不清楚了，反正会记录下学习的点点滴滴的按照惯例，我们学习任何新的知识的时候，总是来一个Hello world的d

上一个小节，写的一个入门的Hello Netty的案例，它的模型其实很简单，我们画个简单的图理解一下package com.lyncc.netty.concept;/** * * @author Bazingalyncc * 描述： * 时间 2016年4月29日 */public class HelloWorldConcept { /** *

其实Netty的知识点还是很零碎的，比如这个SimpleChannelInboundHandler这个类，在《Netty in Action》该书中的原版的Hello world的demo的客户端就是使用的SimpleChannelInboundHandler来作为处理器的，我本来也是使用这个类作为我处理类的，但是做一个新手，这个类还是让我走了一点弯路，我们可以看到SimpleChannelInboundHandler中有一个channelRead0的方法需要我们实现：

目前来说这样做的好处：1）每一个handler只需要关注自己要处理的方法，如果你不关注channelActive方法时，你自定义的channelhandler就不需要重写channelActive方法2）异常处理，如果 exceptionCaught方法每个handler都重写了，只需有一个类捕捉到然后做处理就可以了，不需要每个handler都处理一遍3）灵活性。例如如下图所示：

网络传输的载体是byte，这是任何框架谁也逃脱不了的一种规定，JAVA的NIO提供了ByteBuffer，用来完成这项任务，当然ByteBuffer也很好的完成了这个任务，Netty也提供了一个名字很相似的载体叫做ByteBuf，相比于ByteBuf而言，它有着更加更多友善的API,也更加易于维护，并且它可以扩容一般来说，ByteBuf都是维护一个byte数组的，它的内部格式是

TCP编程底层都有粘包和拆包机制，因为我们在C/S这种传输模型下，以TCP协议传输的时候，在网络中的byte其实就像是河水，TCP就像一个搬运工,将这流水从一端转送到另一端，这时又分两种情况：1）如果客户端的每次制造的水比较多，也就是我们常说的客户端给的包比较大，TCP这个搬运工就会分多次去搬运。2）如果客户端每次制造的水比较少的话，TCP可能会等客户端多次生产之后，把所有的水一起再运输到

可以看到被分了20次读取，我们可以这样理解，客户端发送了2次req字节，每个req中有10个“$$__”，这样就是第11次切割的时候其实发送了粘包，第一个req中末尾部分和第二次的头部粘在了一起，作为第11部分的内容而最后一部分的内容因为没有"$$__"切割，所以没有打印在控制台上~其实这类的Handler还是相对比较简单的，真实的生产环境这些decoder只是作为比较基本的切分类，但是这些decoder还是很好用的~

之前介绍了Netty天然的几种解析器，也稍微介绍了一下ByteToMessageDecoder类，我们对Netty的解码器还是有了一定的了解~今天要介绍的是Netty中一个很重要的解码器，因为相比于其他的普通的解码器，这个解码器用的场景更多，并不是说其他解码器不重要，只是因为我们业务场景所致在当今比较流行的水平拆分的架构之下，RPC协议很是流行，这样可以使各个项目解耦，使得

protobuf是由Google开发的一套对数据结构进行序列化的方法，可用做通信协议，数据存储格式，等等。其特点是不限语言、不限平台、扩展性强Netty也提供了对Protobuf的天然支持，我们今天就写一个简单的示例，简单地了解一下Netty对Google的protoBuf的支持我们的示例场景很简单的：客户端发送一个信息，这个信息用Protobuf来做序列化，然后服务器端接

Netty提供了对心跳机制的天然支持，心跳可以检测远程端是否存活，或者活跃今天我们就一起初识一下Netty4的心跳机制Netty4.0提供了一个类，名为IdleStateHandler，这个类可以对三种类型的心跳检测这个类的构造参数是这样的：前三个的参数解释如下：1）readerIdleTime：为读超时时间（即测试端一定时间内未接受到被测试端消

前面简单地了解了一下IdleStateHandler，我们现在写一个简单的心跳demo：1）服务器端每隔5秒检测服务器端的读超时，如果5秒没有接受到客户端的写请求，也就说服务器端5秒没有收到读事件，则视为一次超时2）如果超时二次则说明连接处于不活跃的状态，关闭ServerChannel3）客户端每隔4秒发送一些写请求，这个请求相当于一次心跳包，告之服务器端：客户端仍旧活着

其实重连机制并不是多么多高深的技术，其实就是一个在客户端做一个简单的判断，如果连接断了，那么就重新调用连接服务端的代码当然，我们重连的动作肯定是发生在断连之后发生的，我们可以在上篇的心跳机制的基础上，简单地修改一下客户端的启动代码就可以了：我们在连接断了之后，我们一般会在finally的方法中去释放资源，这边我们应该不去释放资源，我们在finally里面进行重连：

sigh，这这篇博客的时候老脸还是红了一下，应该算是剽窃吧，看到别人写的代码有点无地之容，好在文章的标题是“一起学”，而不是开涛大神的“跟我学”系列的文章最近工作比较忙，但闲暇之余还是看了阿里的冯家春（fengjiachun）的github上的开源代码Jupiter，写的RPC框架让我感叹人外有人，废话不多说，下面的代码全部截取自Jupiter，写了一个比较完整的例子，供大家一起学习分

本来没打算研究这个东西的，一开始觉得没啥用，甚至觉得这个东西有点鸡肋，不过慢慢接触之后，发现了这个AttributeMap的重要性初学这个东西，我们还是先理解AttributeMap的用法吧AttributeMap这个是

在有些网络通信的场景下，要求低延迟，这样就需要我们设置一些TCP的链接属性：在客户端我们需要这样设置：bootstap.option(ChannelOption.TCP_NODELAY, true);在服务器端是在worker的Channel端设置属性， boot.childOption(ChannelOption.TCP_NODELAY, true);设置这样做好的好

沉淀了一个月安安心心地学习了家纯大神的Jupiter(https://github.com/fengjiachun/Jupiter），感觉受益良多，感觉自己学习了这里面的精华的50%,不是谦虚，而是无知，因为我不知道着里面还有多少是我没有理解的，也许我看懂了他的代码，但我现在还不知道他那样做的好处吧废话不多说，听了大神的意见，开始慢慢看netty的源码，在学习netty源码之前，我们还

1）Netty的server端代码一开始初始化了两个EventLoopGroup，其实就是初始化EventLoop，每一个EventLoop的具体实现就是维护了一个任务队列，一个延迟任务队列，一个thread，并且每一个EventLoop都有一个属于自己的Executor执行器，这样做的好处就是每一个唯一的thread去不停的循环调用，去执行任务队列和延迟任务队列中的task，没有了上下文的切换们还要记得每一个EventLoop还初始化了一个selector，关于selector的创建，netty做了很大的

我们总结一下，Netty的server端流程其实是很清晰的1）先初始化好boss和worker的NioEventLoopGroup，并初始化好Group中的每一个NioEventLoop，为每一个NioEventLoop都穿件一个selector对象2）Netty会在bind的动作上，去让boss的NioserverSocketChannel去绑定selector，并启动与boss捆绑在一起的thread，进入无尽的循环3）在这个生命不息，循环不止的方法中，主要做了两件事情，1是去select，

看了RPC框架Jupiter的源码和RocketMQ的Netty部分的代码，最后还是总结一下，把与Netty相关的代码都截取出来，写出一个比较规范的DEMO这个DEMO还是比较简单的，但麻雀虽小五脏俱全啊，有心跳，有重连，有ack的，可以与大家分享一下~https://github.com/BazingaLyn/netty-study/tree/master/src/mai