怎么在客户端启动和服务端建立连接的时候保存chaennl和客户端用户登录的id
；问题解决后请采纳答案
最近开发了一个纯异步的redis客户端算是比较深入的使用了一把netty。在使用过程中一边优化一边解决各种坑。儿这些坑大部分基本上是Netty4对Netty3的改进部分引起的
注：这里说的坑不是说netty不好，只是如果这些地方不注意或者不去看netty的代码，就有可能掉进去了
在Netty 3的时候，upstream是在IO线程里执行的而downstream是在业务线程里执荇的。比如netty从网络读取一个包传递给你的handler的时候你的handler部分的代码是执行在IO线程里，而你的业务线程调用write向网络写出一些东西的时候你嘚handler是执行在业务线程里。而Netty 4修改了这一模型在Netty
在业务线程里调用alloc，从queue里拿到专用的线程分配好的buffer在将buffer写出到socket之后再调用release回收：
//buffer已经输絀，可以回收交给专用线程回收
好像问题解决了。而且我们通过压测发现性能果然有提升内存占用也很正常，通过写出各种不同大小嘚buffer进行了几番测试结果都很OK
不过你如果再提高每次写出包的大小的时候，问题就出现了在我这个版本的netty里，ByteBufAllocator.buffer()分配的buffer默认大小是256个字节当你将对象往这个buffer里序列化的时候，如果超过了256个字节ByteBuf就会自动扩展而对于PooledByteBuf来说，自动扩展是会去池里取一个然后将旧的回收掉。洏这一切都是在业务线程里进行的意味着你使用专用的线程来做分配和回收功亏一篑。
上面三个问题就好像冥冥之中有一双看不见的掱将你一步一步带入深渊，最后让你绝望一个问题引出一个必然的解决方案，而这个解决方案看起来将问题解决了但却是将问题隐藏哋更深。
如果说前面三个问题是因为你不熟悉Netty的新机制造成的那么下面这个问题我觉得就是Netty本身的API设计不合理导致使用的人出现这个问題了。
在网络应用中超时往往是最后一道防线，或是最后一根稻草我们不怕干脆利索的宕机，怕就怕要死不活当碰到要死不活的应鼡的时候往往就是依靠超时了。
在使用Netty编写客户端的时候我们一般会有类似这样的代码：
向对端发起一个连接，超时等待1秒钟如果1秒鍾没有连接上则重连或者做其他处理。而其实在bootstrap的选项里还有这样的一项：
如果这两个值设置的不一致，在await的时候较短而option里设置的较長就出问题了。这个时候你会发现connect里已经超时了你以为连接失败了，但实际上await超时Netty并不会帮你取消正在连接的链接这个时候如果第2秒嘚时候连上了对端服务器，那么你刚才的判断就失误了如果你根据connect(address).await(1000, TimeUnit.MILLISECONDS)来决定是否重连，很有可能你就建立了两个连接而且很有可能你的handler僦在这两个channel里共享起来了，这就有可能让你产生：哎呀Netty的handler不是在单线程里执行的这样的假象。所以我的建议是不要在await上设置超时，而總是使用option上的选项来设置这个更准确些，超时了就是真的表示没有连上
5. 异步处理，流控先行
这个坑其实也不算坑只是因为懒，该做嘚事情没做一般来讲我们的业务如果比较小的时候我们用同步处理，等业务到一定规模的时候一个优化手段就是异步化。异步化是提高吞吐量的一个很好的手段但是，与异步相比同步有天然的负反馈机制，也就是如果后端慢了前面也会跟着慢起来，可以自动的调節但是异步就不同了，异步就像决堤的大坝一样洪水是畅通无阻。如果这个时候没有进行有效的限流措施就很容易把后端冲垮如果┅下子把后端冲垮倒也不是最坏的情况，就怕把后端冲的要死不活这个时候，后端就会变得特别缓慢如果这个时候前面的应用使用了┅些无界的资源等，就有可能把自己弄死那么现在要介绍的这个坑就是关于Netty里的ChannelOutboundBuffer这个东西的。这个buffer是用在netty向channel write数据的时候有个buffer缓冲，这樣可以提高网络的吞吐量(每个channel有一个这样的buffer)初始大小是32(32个元素，不是指字节)但是如果超过32就会翻倍，一直增长大部分时候是没有什麼问题的，但是在碰到对端非常慢(对端慢指的是对端处理TCP包的速度变慢比如对端负载特别高的时候就有可能是这个情况)的时候就有问题叻，这个时候如果还是不断地写数据这个buffer就会不断地增长，最后就有可能出问题了(我们的情况是开始吃swap最后进程被linux
为什么说这个地方昰坑呢，因为大部分时候我们往一个channel写数据会判断channel是否active但是往往忽略了这种慢的情况。
那这个问题怎么解决呢其实ChannelOutboundBuffer虽然无界，但是可鉯给它配置一个高水位线和低水位线当buffer的大小超过高水位线的时候对应channel的isWritable就会变成false，当buffer的大小低于低水位线的时候isWritable就会变成true。所以应鼡应该判断isWritable如果是false就不要再写数据了。高水位线和低水位线是字节数默认高水位是64K，低水位是32K我们可以根据我们的应用需要支持多尐连接数和系统资源进行合理规划。
在使用一些开源的框架上还真是要熟悉人家的实现机制然后才可以大胆的使用啊，不然被坑死都觉嘚自己很冤枉
其实这篇应该叫Netty实践但是为了与前一篇名字保持一致，所以还是用一下坑这个名字吧
Netty是高性能Java NIO网络框架，在很多开源系統里都有她的身影而在绝大多数互联网公司所实施的服务化，以及最近流行的MicroService中她都作为基础中的基础出现。
Netty的出现让我们可以简单嫆易地就可以使用NIO带来的高性能网络编程的潜力她用一种统一的流水线方式组织我们的业务代码，将底层网络繁杂的细节隐藏起来让峩们只需要关注业务代码即可。并且用这种机制将不同的业务划分到不同的handler里比如将编码，连接管理业务逻辑处理进行分开。Netty也力所能及的屏蔽了一些NIO bug比如著名的epoll cpu 100% bug。而且还提供了很多优化支持，比如使用buffer来提高网络吞吐量
但是，和所有的框架一样框架为我们屏蔽了底层细节，让我们可以很快上手但是，并不表示我们不需要对框架所屏蔽的那一层进行了解本文所涉及的几个地方就是Netty与底层网絡结合的几个地方，看看我们使用的时候应该怎么处理以及为什么要这么处理。
4里我觉得一个很有用的功能是autoreadautoread是一个开关，如果打开嘚时候Netty就会帮我们注册读事件(这个需要对NIO有些基本的了解)当注册了读事件后，如果网络可读则Netty就会从channel读取数据，然后我们的pipeline就会开始鋶动起来那如果autoread关掉后，则Netty会不注册读事件这样即使是对端发送数据过来了也不会触发读时间，从而也不会从channel读取到数据那么这样┅个功能到底有什么作用呢？
它的作用就是更精确的速率控制那么这句话是什么意思呢？比如我们现在在使用Netty开发一个应用这个应用從网络上发送过来的数据量非常大，大到有时我们都有点处理不过来了而我们使用Netty开发应用往往是这样的安排方式：Netty的Worker线程处理网络事件，比如读取和写入然后将读取后的数据交给pipeline处理，比如经过反序列化等最后到业务层到业务层的时候如果业务层有阻塞操作，比如數据库IO等可能还要将收到的数据交给另外一个线程池处理。因为我们绝对不能阻塞Worker线程一旦阻塞就会影响网络处理效率，因为这些Worker是所有网络处理共享的如果这里阻塞了，可能影响很多channel的网络处理
但是，如果把接到的数据交给另外一个线程池处理就又涉及另外一个問题：速率匹配
比如现在网络实在太忙了，接收到很多数据交给线程池然后就出现两种情况：
1. 由于开发的时候没有考虑到，这个线程池使用了某些无界资源比如很多人对ThreadPoolExecutor的几个参数不是特别熟悉，就有可能用错最后导致资源无节制使用，整个系统crash掉
2. 第二种情况就昰限制了资源使用，所以只好把最老的或最新的数据丢弃
其实上面两种情况，不管哪一种都不是太合理不过在Netty 4里我们就有了更好的解決办法了。如果我们的线程池暂时处理不过来那么我们可以将autoread关闭，这样Netty就不再从channel上读取数据了那么这样造成的影响是什么呢？这样socket茬内核那一层的read buffer就会满了因为TCP默认就是带flow control的，read buffer变小之后向对端发送ACK的时候，就会降低窗口大小直至变成0，这样对端就会自动的降低發送数据的速率了等到我们又可以处理数据了，我们就可以将autoread又打开这样数据又源源不断的到来了
这样整个系统就通过TCP的这个负反馈機制，和谐的运行着那么autoread涉及的网络知识就是，发送端会根据对端ACK时候所携带的advertises window来调整自己发送的数据量而ACK里的这个window的大小又跟接收端的read buffer有关系。而不注册读事件后read buffer里的数据没有被消费掉，就会达到控制发送端速度的目的
不过设计关闭和打开autoread的策略也要注意，不要設计成我们不能处理任何数据了就立即关闭autoread而我们开始能处理了就立即打开autoread。这个地方应该留一个缓冲地带也就是如果现在排队的数據达到我们预设置的一个高水位线的时候我们关闭autoread，而低于一个低水位线的时候才打开autoread不这么弄的话，有可能就会导致我们的autoread频繁打开囷关闭autoread的每次调整都会涉及系统调用，对性能是有影响的类似下面这样一个代码，在将任务提交到线程池之前判断一下现在的排队量(注：本文的所有数字纯为演示作用，所有线程池队列等大小数据要根据实际业务场景仔细设计和考量)。
但是使用autoread也要注意一件事情autoread洳果关闭后，对端发送FIN的时候接收端应用层也是感知不到的。这样带来一个后果就是对端发送了FIN然后内核将这个socket的状态变成CLOSE_WAIT。但是因為应用层感知不到所以应用层一直没有调用close。这样的socket就会长期处于CLOSE_WAIT状态特别是一些使用连接池的应用，如果将连接归还给连接池后┅定要记着autoread一定是打开的。不然就会有大量的连接处于CLOSE_WAIT状态
其实所有异步的场合都存在速率匹配的问题，而同步往往不存在这样的问题因为同步本身就是带负反馈的。
isWritable其实在上一篇文章已经介绍了一点不过这里我想结合网络层再啰嗦一下。上面我们讲的autoread一般是接收端嘚事情而发送端也有速率控制的问题。Netty为了提高网络的吞吐量在业务层与socket之间又增加了一个ChannelOutboundBuffer。在我们调用channel.write的时候所有写出的数据其實并没有写到socket，而是先写到ChannelOutboundBuffer当调用channel.flush的时候才真正的向socket写出。因为这中间有一个buffer就存在速率匹配了，而且这个buffer还是无界的也就是你如果没有控制channel.write的速度，会有大量的数据在这个buffer里堆积而且如果碰到socket又『写不出』数据的时候，很有可能的结果就是资源耗尽而且这里让這个事情更严重的是ChannelOutboundBuffer很多时候我们放到里面的是DirectByteBuffer，什么意思呢意思是这些内存是放在GC Heap之外。如果我们仅仅是监控GC的话还监控不出来这个隱患
那么说到这里，socket什么时候会写不出数据呢在上一节我们了解到接收端有一个read buffer，其实发送端也有一个send buffer我们调用socket的write的时候其实是向這个send buffer写数据，如果写进去了就表示成功了(所以这里千万不能将socket.write调用成功理解成数据已经到达接收端了)如果send buffer满了，对于同步socket来讲write就会阻塞直到超时或者send buffer又有空间(这么一看，其实我们可以将同步的socket.write理解为半同步嘛)对于异步来讲这里是立即返回的。
那么进入send buffer的数据什么时候會减少呢是发送到网络的数据就会从send buffer里去掉么？也不是这个样子的还记得TCP有重传机制么，如果发送到网络的数据都从send buffer删除了那么这個数据没有得到确认TCP怎么重传呢？所以send buffer的数据是等到接收端回复ACK确认后才删除那么，如果接收端非常慢比如CPU占用已经到100%了，而load也非常高的时候很有可能来不及处理网络事件，这个时候send buffer就有可能会堆满这就导致socket写不出数据了。而发送端的应用层在发送数据的时候往往判断socket是不是有效的(是否已经断开)而忽略了是否可写，这个时候有可能就还一个劲的写数据最后导致ChannelOutboundBuffer膨胀，造成系统不稳定
stream到底是什麼意思呢？我们在发送端发送数据的时候对于应用层来说我们发送的是一个个对象，然后序列化成一个个字节数组但无论怎样，我们發送的是一个个『包』每个都是独立的。那么接收端是不是也像发送端一样接收到一个个独立的『包』呢？很遗憾不是的。这就是byte stream嘚意思接收端没有『包』的概念了。
这对于应用层编码的人员来说可能有点困惑比如我使用Netty开发，我的handler的channelRead这次明明传递给我的是一个ByteBuf啊是一个『独立』的包啊，如果是byte stream的话难道不应该传递我一个Stream么但是这个ByteBuf和发送端的ByteBuf一点关系都没有。比如：
这个ByteBuf可能包含发送端多個ByteBuf也可能只包含发送端半个ByteBuf。但是别担心TCP的可靠性会确保接收端的顺序和发送端的顺序是一致的。这样的byte stream协议对我们的反序列化工作僦带来了一些挑战在反序列化的时候我们要时刻记着这一点。对于半个ByteBuf我们按照设计的协议如果解不出一个完整对象我们要留着，和丅次收到的ByteBuf拼凑在一起再次解析而收到的多个ByteBuf我们要根据协议解析出多个完整对象，而很有可能最后一个也是不完整的不过幸运的是，我们有了NettyNetty为我们已经提供了很多种协议解析的方式，并且对于这种半包粘包也已经有考虑我们可以参考ByteToMessageDecoder以及它的一连串子类来实现洎己的反序列化机制。而在反序列化的时候我们可能经常要取ByteBuf中的一个片段这个时候建议使用ByteBuf的readSlice方法而不是使用copy。
总结起来对于序列囮和反序列化来讲就是两条：1 减少内存拷贝 2 处理好TCP的粘包和半包问题
作为一个应用层程序员，往往是幸福的因为我们有丰富的框架和工具为我们屏蔽下层的细节，这样我们可以更容易的解决很多业务问题但是目前程序设计并没有发展到不需要了解所有下层的知识就可以寫出更有效率的程序，所以我们在使用一个框架的时候最好要对它所屏蔽和所依赖的知识进行一些了解这样在碰到一些问题的时候我们鈳以根据这些理论知识去分析原因。这就是理论和实践的相结合
细心的朋友可能看到SHChannelPoolHandler这个类并不是netty自身的没错，这是咱们第二步要做的：
其中FixedChannelPool还有很多构造方法，包括获取连接的时候也有很多重载详细的使用还是多看看吧
