移动互联网时代，推送(Push)服务成为App应用不可或缺的重要组成部分，推送服务可以提升用户的活跃度和留存率。我们的手机每天接收到各种各样的广告和提示消息等大多数都是通过推送服务实现的。
随着物联网的发展，大多数的智能家居都支持移动推送服务，未来所有接入物联网的智能设备都将是推送服务的客户端，这就意味着推送服务未来会面临海量的设备和终端接入。
移动推送服务的主要特点如下：
使用的网络主要是运营商的无线移动网络，网络质量不稳定，例如在地铁上信号就很差，容易发生网络闪断；
海量的客户端接入，而且通常使用长连接，无论是客户端还是服务端，资源消耗都非常大；
由于谷歌的推送框架无法在国内使用，Android的长连接是由每个应用各自维护的，这就意味着每台安卓设备上会存在多个长连接。即便没有消息需要推送，长连接本身的心跳消息量也是非常巨大的，这就会导致流量和耗电量的增加；
不稳定：消息丢失、重复推送、延迟送达、过期推送时有发生；
垃圾消息满天飞，缺乏统一的服务治理能力。
为了解决上述弊端，一些企业也给出了自己的解决方案，例如京东云推出的推送服务，可以实现多应用单服务单连接模式，使用AlarmManager定时心跳节省电量和流量。
Netty海量接入服务的技术要点
作为高性能的NIO框架，利用Netty开发高效的推送服务技术上是可行的，但是由于推送服务自身的复杂性，想要开发出稳定、高性能的推送服务并非易事，需要在设计阶段针对推送服务的特点进行合理设计。
最大句柄数修改
百万长连接接入，首先需要优化的就是Linux内核参数，其中Linux最大文件句柄数是最重要的调优参数之一，默认单进程打开的最大句柄数是1024，通过ulimit -a可以查看相关参数，
当单个推送服务接收到的链接超过上限后，就会报“too many open files”，所有新的客户端接入将失败。
通过vi /etc/security/limits.conf 添加如下配置参数：修改之后保存，注销当前用户，重新登录，通过ulimit -a 查看修改的状态是否生效。
需要指出的是，尽管我们可以将单个进程打开的最大句柄数修改的非常大，但是当句柄数达到一定数量级之后，处理效率将出现明显下降，因此，需要根据服务器的硬件配置和处理能力进行合理设置。如果单个服务器性能不行也可以通过集群的方式实现。
当心CLOSE_WAIT
从事移动推送服务开发的同学可能都有体会，移动无线网络可靠性非常差，经常存在客户端重置连接，网络闪断等。
在百万长连接的推送系统中，服务端需要能够正确处理这些网络异常，设计要点如下：
客户端的重连间隔需要合理设置，防止连接过于频繁导致的连接失败（例如端口还没有被释放）；
客户端重复登陆拒绝机制；
服务端正确处理I/O异常和解码异常等，防止句柄泄露。
最后特别需要注意的一点就是close_wait 过多问题，由于网络不稳定经常会导致客户端断连，如果服务端没有能够及时关闭socket，就会导致处于close_wait状态的链路过多。close_wait状态的链路并不释放句柄和内存等资源，如果积压过多可能会导致系统句柄耗尽，发生“Too many open files”异常，新的客户端无法接入，涉及创建或者打开句柄的操作都将失败。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
close_wait是被动关闭连接是形成的，根据TCP状态机，服务器端收到客户端发送的FIN，TCP协议栈会自动发送ACK，链接进入close_wait状态。但如果服务器端不执行socket的close()操作，状态就不能由close_wait迁移到last_ack，则系统中会存在很多close_wait状态的连接。通常来说，一个close_wait会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆close_wait消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。
导致close_wait过多的可能原因如下：
程序处理Bug，导致接收到对方的fin之后没有及时关闭socket，这可能是Netty的Bug，也可能是业务层Bug，需要具体问题具体分析；
关闭socket不及时：例如I/O线程被意外阻塞，或者I/O线程执行的用户自定义Task比例过高，导致I/O操作处理不及时，链路不能被及时释放。
下面我们结合Netty的原理，对潜在的故障点进行分析。
设计要点1：不要在Netty的I/O线程上处理业务（心跳发送和检测除外）。Why? 对于Java进程，线程不能无限增长，这就意味着Netty的Reactor线程数必须收敛。Netty的默认值是CPU核数 * 2，通常情况下，I/O密集型应用建议线程数尽量设置大些，但这主要是针对传统同步I/O而言，对于非阻塞I/O，线程数并不建议设置太大，尽管没有最优值，但是I/O线程数经验值是[CPU核数 + 1，CPU核数*2 ]之间。
假如单个服务器支撑100万个长连接，服务器内核数为32，则单个I/O线程处理的链接数L = 100/(32 * 2) = 15625。 假如每5S有一次消息交互（新消息推送、心跳消息和其它管理消息），则平均CAPS = 15625 / 5 = 3125条/秒。这个数值相比于Netty的处理性能而言压力并不大，但是在实际业务处理中，经常会有一些额外的复杂逻辑处理，例如性能统计、记录接口日志等，这些业务操作性能开销也比较大，如果在I/O线程上直接做业务逻辑处理，可能会阻塞I/O线程，影响对其它链路的读写操作，这就会导致被动关闭的链路不能及时关闭，造成close_wait堆积。
设计要点2：在I/O线程上执行自定义Task要当心。Netty的I/O处理线程NioEventLoop支持两种自定义Task的执行：
普通的Runnable: 通过调用NioEventLoop的execute(Runnable task)方法执行；
定时任务ScheduledFutureTask:通过调用NioEventLoop的schedule(Runnable command, long delay, TimeUnit unit)系列接口执行。
为什么NioEventLoop要支持用户自定义Runnable和ScheduledFutureTask的执行，并不是本文要讨论的重点，后续会有专题文章进行介绍。本文重点对它们的影响进行分析。
在NioEventLoop中执行Runnable和ScheduledFutureTask，意味着允许用户在NioEventLoop中执行非I/O操作类的业务逻辑，这些业务逻辑通常用消息报文的处理和协议管理相关。它们的执行会抢占NioEventLoop I/O读写的CPU时间，如果用户自定义Task过多，或者单个Task执行周期过长，会导致I/O读写操作被阻塞，这样也间接导致close_wait堆积。
所以，如果用户在代码中使用到了Runnable和ScheduledFutureTask，请合理设置ioRatio的比例，通过NioEventLoop的setIoRatio(int ioRatio)方法可以设置该值，默认值为50，即I/O操作和用户自定义任务的执行时间比为1：1。
我的建议是当服务端处理海量客户端长连接的时候，不要在NioEventLoop中执行自定义Task，或者非心跳类的定时任务。
设计要点3：IdleStateHandler使用要当心。很多用户会使用IdleStateHandler做心跳发送和检测，这种用法值得提倡。相比于自己启定时任务发送心跳，这种方式更高效。但是在实际开发中需要注意的是，在心跳的业务逻辑处理中，无论是正常还是异常场景，处理时延要可控，防止时延不可控导致的NioEventLoop被意外阻塞。例如，心跳超时或者发生I/O异常时，业务调用Email发送接口告警，由于Email服务端处理超时，导致邮件发送客户端被阻塞，级联引起IdleStateHandler的AllIdleTimeoutTask任务被阻塞，最终NioEventLoop多路复用器上其它的链路读写被阻塞。
对于ReadTimeoutHandler和WriteTimeoutHandler，约束同样存在。
合理的心跳周期
百万级的推送服务，意味着会存在百万个长连接，每个长连接都需要靠和App之间的心跳来维持链路。合理设置心跳周期是非常重要的工作，推送服务的心跳周期设置需要考虑移动无线网络的特点。
当一台智能手机连上移动网络时，其实并没有真正连接上Internet，运营商分配给手机的IP其实是运营商的内网IP，手机终端要连接上Internet还必须通过运营商的网关进行IP地址的转换，这个网关简称为NAT(NetWork Address Translation)，简单来说就是手机终端连接Internet 其实就是移动内网IP，端口，外网IP之间相互映射。
GGSN(GateWay GPRS Support Note)模块就实现了NAT功能，由于大部分的移动无线网络运营商为了减少网关NAT映射表的负荷，如果一个链路有一段时间没有通信时就会删除其对应表，造成链路中断，正是这种刻意缩短空闲连接的释放超时，原本是想节省信道资源的作用，没想到让互联网的应用不得以远高于正常频率发送心跳来维护推送的长连接。以中移动的2.5G网络为例，大约5分钟左右的基带空闲，连接就会被释放。
由于移动无线网络的特点，推送服务的心跳周期并不能设置的太长，否则长连接会被释放，造成频繁的客户端重连，但是也不能设置太短，否则在当前缺乏统一心跳框架的机制下很容易导致信令风暴（例如微信心跳信令风暴问题）。具体的心跳周期并没有统一的标准，180S也许是个不错的选择，微信为300S。
内存池
推送服务器承载了海量的长链接，每个长链接实际就是一个会话。如果每个会话都持有心跳数据、接收缓冲区、指令集等数据结构，而且这些实例随着消息的处理朝生夕灭，这就会给服务器带来沉重的GC压力，同时消耗大量的内存。
最有效的解决策略就是使用内存池，每个NioEventLoop线程处理N个链路，在线程内部，链路的处理时串行的。假如A链路首先被处理，它会创建接收缓冲区等对象，待解码完成之后，构造的POJO对象被封装成Task后投递到后台的线程池中执行，然后接收缓冲区会被释放，每条消息的接收和处理都会重复接收缓冲区的创建和释放。如果使用内存池，则当A链路接收到新的数据报之后，从NioEventLoop的内存池中申请空闲的ByteBuf，解码完成之后，调用release将ByteBuf释放到内存池中，供后续B链路继续使用。
使用内存池优化之后，单个NioEventLoop的ByteBuf申请和GC次数从原来的N = 1000000/64 = 15625 次减少为最少0次（假设每次申请都有可用的内存）。
下面我们以Twitter使用Netty4的PooledByteBufAllocator进行GC优化作为案例（点击查看该文章），对内存池的效果进行评估，结果如下：
垃圾生成速度是原来的1/5，而垃圾清理速度快了5倍。使用新的内存池机制，几乎可以把网络带宽压满。
Netty 4之前的版本问题如下：每当收到新信息或者用户发送信息到远程端，Netty 3均会创建一个新的堆缓冲区。这意味着，对应每一个新的缓冲区，都会有一个new byte[capacity]。这些缓冲区会导致GC压力，并消耗内存带宽。为了安全起见，新的字节数组分配时会用零填充，这会消耗内存带宽。然而，用零填充的数组很可能会再次用实际的数据填充，这又会消耗同样的内存带宽。如果Java虚拟机（JVM）提供了创建新字节数组而又无需用零填充的方式，那么我们本来就可以将内存带宽消耗减少50%，但是目前没有那样一种方式。
在Netty 4中实现了一个新的ByteBuf内存池，它是一个纯Java版本的 jemalloc （Facebook也在用）。现在，Netty不会再因为用零填充缓冲区而浪费内存带宽了。不过，由于它不依赖于GC，开发人员需要小心内存泄漏。如果忘记在处理程序中释放缓冲区，那么内存使用率会无限地增长。