【Netty系列】Netty百万级推送服务设计要点

一. 背景

1.1. 话题来源

最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我，咨询推送服务相关的问题。问题五花八门，在帮助大家答疑解惑的过程中，我也对问题进行了总结，大概可以归纳为如下几类：整理分享2021Java核心知识点

1.Netty是否可以做推送服务器？

2.如果使用Netty开发推送服务，一个服务器最多可以支撑多少个客户端？

3.使用Netty开发推送服务遇到的各种技术问题。

由于咨询者众多，关注点也比较集中，我希望通过本文的案例分析和对推送服务设计要点的总结，帮助大家在实际工作中少走弯路。

1.2. 推送服务

移动互联网时代，推送(Push)服务成为App应用不可或缺的重要组成部分，推送服务可以提升用户的活跃度和留存率。我们的手机每天接收到各种各样的广告和提示消息等大多数都是通过推送服务实现的。

随着物联网的发展，大多数的智能家居都支持移动推送服务，未来所有接入物联网的智能设备都将是推送服务的客户端，这就意味着推送服务未来会面临海量的设备和终端接入。

1.3. 推送服务的特点

移动推送服务的主要特点如下：

1.使用的网络主要是运营商的无线移动网络，网络质量不稳定，例如在地铁上信号就很差，容易发生网络闪断；

2.海量的客户端接入，而且通常使用长连接，无论是客户端还是服务端，资源消耗都非常大；

3.由于谷歌的推送框架无法在国内使用，Android的长连接是由每个应用各自维护的，这就意味着每台安卓设备上会存在多个长连接。即便没有消息需要推送，长连接本身的心跳消息量也是非常巨大的，这就会导致流量和耗电量的增加；

4.不稳定：消息丢失、重复推送、延迟送达、过期推送时有发生；

5.垃圾消息满天飞，缺乏统一的服务治理能力。

为了解决上述弊端，一些企业也给出了自己的解决方案，例如京东云推出的推送服务，可以实现多应用单服务单连接模式，使用AlarmManager定时心跳节省电量和流量。

二. 智能家居领域的一个真实案例

2.1. 问题描述

智能家居MQTT消息服务中间件，保持10万用户在线长连接，2万用户并发做消息请求。程序运行一段时间之后，发现内存泄露，怀疑是Netty的Bug。其它相关信息如下：

1.MQTT消息服务中间件服务器内存16G，8个核心CPU；

2.Netty中boss线程池大小为1，worker线程池大小为6，其余线程分配给业务使用。该分配方式后来调整为worker线程池大小为11，问题依旧；

3.Netty版本为4.0.8.Final。

2.2. 问题定位

首先需要dump内存堆栈，对疑似内存泄露的对象和引用关系进行分析，如下所示：

1.我们发现Netty的ScheduledFutureTask增加了9076%，达到110W个左右的实例，通过对业务代码的分析发现用户使用IdleStateHandler用于在链路空闲时进行业务逻辑处理，但是空闲时间设置的比较大，为15分钟。

2.Netty的IdleStateHandler会根据用户的使用场景，启动三类定时任务，分别是：ReaderIdleTimeoutTask、WriterIdleTimeoutTask和AllIdleTimeoutTask，它们都会被加入到NioEventLoop的Task队列中被调度和执行。

由于超时时间过长，10W个长链接链路会创建10W个ScheduledFutureTask对象，每个对象还保存有业务的成员变量，非常消耗内存。用户的持久代设置的比较大，一些定时任务被老化到持久代中，没有被JVM垃圾回收掉，内存一直在增长，用户误认为存在内存泄露。

3.事实上，我们进一步分析发现，用户的超时时间设置的非常不合理，15分钟的超时达不到设计目标，重新设计之后将超时时间设置为45秒，内存可以正常回收，问题解决。

2.3. 问题总结

如果是100个长连接，即便是长周期的定时任务，也不存在内存泄露问题，在新生代通过minor GC就可以实现内存回收。正是因为十万级的长连接，导致小问题被放大，引出了后续的各种问题。

事实上，如果用户确实有长周期运行的定时任务，该如何处理？对于海量长连接的推送服务，代码处理稍有不慎，就满盘皆输，下面我们针对Netty的架构特点，介绍下如何使用Netty实现百万级客户端的推送服务。

三. Netty海量推送服务设计要点

作为高性能的NIO框架，利用Netty开发高效的推送服务技术上是可行的，但是由于推送服务自身的复杂性，想要开发出稳定、高性能的推送服务并非易事，需要在设计阶段针对推送服务的特点进行合理设计。

3.1. 最大句柄数修改

百万长连接接入