Netty系列之Netty百萬級推送服務設計要點

1. 背景

1.1. 話題來源

最近很多從事移動網際網路和物聯網開發的同學給我發郵件或者微網誌私信我，咨詢推送服務相關的問題。問題五花八門，在幫助大家答疑解惑的過程中，我也對問題進行了總結，大概可以歸納為如下幾類：

1. Netty是否可以做推送伺服器？
2. 如果使用Netty開發推送服務，一個伺服器最多可以支撐多少個用戶端？
3. 使用Netty開發推送服務遇到的各種技術問題。

由于咨詢者衆多，關注點也比較集中，我希望通過本文的案例分析和對推送服務設計要點的總結，幫助大家在實際工作中少走彎路。

1.2. 推送服務

移動網際網路時代，推送(Push)服務成為App應用不可或缺的重要組成部分，推送服務可以提升使用者的活躍度和留存率。我們的手機每天接收到各種各樣的廣告和提示消息等大多數都是通過推送服務實作的。

随着物聯網的發展，大多數的智能家居都支援移動推送服務，未來所有接入物聯網的智能裝置都将是推送服務的用戶端，這就意味着推送服務未來會面臨海量的裝置和終端接入。

1.3. 推送服務的特點

移動推送服務的主要特點如下：

1. 使用的網絡主要是營運商的無線移動網絡，網絡品質不穩定，例如在地鐵上信号就很差，容易發生網絡閃斷；
2. 海量的用戶端接入，而且通常使用長連接配接，無論是用戶端還是服務端，資源消耗都非常大；
3. 由于谷歌的推送架構無法在國内使用，Android的長連接配接是由每個應用各自維護的，這就意味着每台安卓裝置上會存在多個長連接配接。即便沒有消息需要推送，長連接配接本身的心跳消息量也是非常巨大的，這就會導緻流量和耗電量的增加；
4. 不穩定：消息丢失、重複推送、延遲送達、過期推送時有發生；
5. 垃圾消息滿天飛，缺乏統一的服務治理能力。

為了解決上述弊端，一些企業也給出了自己的解決方案，例如京東雲推出的推送服務，可以實作多應用單服務單連接配接模式，使用AlarmManager定時心跳節省電量和流量。

2. 智能家居領域的一個真實案例

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記憶體堆棧，對疑似記憶體洩露的對象和引用關系進行分析，如下所示：

我們發現Netty的ScheduledFutureTask增加了9076%，達到110W個左右的執行個體，通過對業務代碼的分析發現使用者使用IdleStateHandler用于在鍊路空閑時進行業務邏輯處理，但是空閑時間設定的比較大，為15分鐘。

Netty的IdleStateHandler會根據使用者的使用場景，啟動三類定時任務，分别是：ReaderIdleTimeoutTask、WriterIdleTimeoutTask和AllIdleTimeoutTask，它們都會被加入到NioEventLoop的Task隊列中被排程和執行。

由于逾時時間過長，10W個長連結鍊路會建立10W個ScheduledFutureTask對象，每個對象還儲存有業務的成員變量，非常消耗記憶體。使用者的持久代設定的比較大，一些定時任務被老化到持久代中，沒有被JVM垃圾回收掉，記憶體一直在增長，使用者誤認為存在記憶體洩露。

事實上，我們進一步分析發現，使用者的逾時時間設定的非常不合理，15分鐘的逾時達不到設計目标，重新設計之後将逾時時間設定為45秒，記憶體可以正常回收，問題解決。

2.3. 問題總結

如果是100個長連接配接，即便是長周期的定時任務，也不存在記憶體洩露問題，在新生代通過minor GC就可以實作記憶體回收。正是因為十萬級的長連接配接，導緻小問題被放大，引出了後續的各種問題。

事實上，如果使用者确實有長周期運作的定時任務，該如何處理？對于海量長連接配接的推送服務，代碼處理稍有不慎，就滿盤皆輸，下面我們針對Netty的架構特點，介紹下如何使用Netty實作百萬級用戶端的推送服務。

3. Netty海量推送服務設計要點

作為高性能的NIO架構，利用Netty開發高效的推送服務技術上是可行的，但是由于推送服務自身的複雜性，想要開發出穩定、高性能的推送服務并非易事，需要在設計階段針對推送服務的特點進行合理設計。

3.1. 最大句柄數修改

百萬長連接配接接入，首先需要優化的就是Linux核心參數，其中Linux最大檔案句柄數是最重要的調優參數之一，預設單程序打開的最大句柄數是1024，通過ulimit -a可以檢視相關參數，示例如下：

[root@lilinfeng ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 256324
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024

......後續輸出省略      

當單個推送服務接收到的連結超過上限後，就會報“too many open files”，所有新的用戶端接入将失敗。

通過vi /etc/security/limits.conf 添加如下配置參數：修改之後儲存，登出目前使用者，重新登入，通過ulimit -a 檢視修改的狀态是否生效。

*  soft　　nofile　　1000000
*  hard　　nofile　　1000000      

需要指出的是，盡管我們可以将單個程序打開的最大句柄數修改的非常大，但是當句柄數達到一定數量級之後，處理效率将出現明顯下降，是以，需要根據伺服器的硬體配置和處理能力進行合理設定。如果單個伺服器性能不行也可以通過叢集的方式實作。

3.2. 當心CLOSE_WAIT

從事移動推送服務開發的同學可能都有體會，移動無線網絡可靠性非常差，經常存在用戶端重置連接配接，網絡閃斷等。

在百萬長連接配接的推送系統中，服務端需要能夠正确處理這些網絡異常，設計要點如下：

1. 用戶端的重連間隔需要合理設定，防止連接配接過于頻繁導緻的連接配接失敗（例如端口還沒有被釋放）；
2. 用戶端重複登陸拒絕機制；
3. 服務端正确處理I/O異常和解碼異常等，防止句柄洩露。

最後特别需要注意的一點就是close_wait 過多問題，由于網絡不穩定經常會導緻用戶端斷連，如果服務端沒有能夠及時關閉socket，就會導緻處于close_wait狀态的鍊路過多。close_wait狀态的鍊路并不釋放句柄和記憶體等資源，如果積壓過多可能會導緻系統句柄耗盡，發生“Too many open files”異常，新的用戶端無法接入，涉及建立或者打開句柄的操作都将失敗。

下面對close_wait狀态進行下簡單介紹，被動關閉TCP連接配接狀态遷移圖如下所示：

圖3-1 被動關閉TCP連接配接狀态遷移圖

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過多的可能原因如下：

1. 程式處理Bug，導緻接收到對方的fin之後沒有及時關閉socket，這可能是Netty的Bug，也可能是業務層Bug，需要具體問題具體分析；
2. 關閉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的執行：

1. 普通的Runnable: 通過調用NioEventLoop的execute(Runnable task)方法執行；
2. 定時任務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，限制同樣存在。

3.3. 合理的心跳周期

百萬級的推送服務，意味着會存在百萬個長連接配接，每個長連接配接都需要靠和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。

在Netty中，可以通過在ChannelPipeline中增加IdleStateHandler的方式實作心跳檢測，在構造函數中指定鍊路空閑時間，然後實作空閑回調接口，實作心跳的發送和檢測，代碼如下：

public void initChannel({@link Channel} channel) {
 channel.pipeline().addLast("idleStateHandler", new {@link   IdleStateHandler}(0, 0, 180));
 channel.pipeline().addLast("myHandler", new MyHandler());
}
攔截鍊路空閑事件并處理心跳：
 public class MyHandler extends {@link ChannelHandlerAdapter} {
     {@code @Override}
      public void userEventTriggered({@link ChannelHandlerContext} ctx, {@link Object} evt) throws {@link Exception} {
          if (evt instanceof {@link IdleStateEvent}} {
              //心跳處理
          }
      }
  }      

3.4. 合理設定接收和發送緩沖區容量

對于長連結，每個鍊路都需要維護自己的消息接收和發送緩沖區，JDK原生的NIO類庫使用的是java.nio.ByteBuffer,它實際是一個長度固定的Byte數組，我們都知道數組無法動态擴容，ByteBuffer也有這個限制，相關代碼如下：

public abstract class ByteBuffer
    extends Buffer
    implements Comparable{
    final byte[] hb; // Non-null only for heap buffers
    final int offset;
    boolean isReadOnly;      

容量無法動态擴充會給使用者帶來一些麻煩，例如由于無法預測每條消息封包的長度，可能需要預配置設定一個比較大的ByteBuffer，這通常也沒有問題。但是在海量推送服務系統中，這會給服務端帶來沉重的記憶體負擔。假設單條推送消息最大上限為10K，消息平均大小為5K，為了滿足10K消息的處理，ByteBuffer的容量被設定為10K，這樣每條鍊路實際上多消耗了5K記憶體，如果長連結鍊路數為100萬，每個鍊路都獨立持有ByteBuffer接收緩沖區，則額外損耗的總記憶體 Total(M) = 1000000 * 5K = 4882M。記憶體消耗過大，不僅僅增加了硬體成本，而且大記憶體容易導緻長時間的Full GC，對系統穩定性會造成比較大的沖擊。

實際上，最靈活的處理方式就是能夠動态調整記憶體，即接收緩沖區可以根據以往接收的消息進行計算，動态調整記憶體，利用CPU資源來換記憶體資源，具體的政策如下：

1. ByteBuffer支援容量的擴充和收縮，可以按需靈活調整，以節約記憶體；
2. 接收消息的時候，可以按照指定的算法對之前接收的消息大小進行分析，并預測未來的消息大小，按照預測值靈活調整緩沖區容量，以做到最小的資源損耗滿足程式正常功能。

幸運的是，Netty提供的ByteBuf支援容量動态調整，對于接收緩沖區的記憶體配置設定器，Netty提供了兩種：

1. FixedRecvByteBufAllocator：固定長度的接收緩沖區配置設定器，由它配置設定的ByteBuf長度都是固定大小的，并不會根據實際資料報的大小動态收縮。但是，如果容量不足，支援動态擴充。動态擴充是Netty ByteBuf的一項基本功能，與ByteBuf配置設定器的實作沒有關系；
2. AdaptiveRecvByteBufAllocator：容量動态調整的接收緩沖區配置設定器，它會根據之前Channel接收到的資料報大小進行計算，如果連續填充滿接收緩沖區的可寫空間，則動态擴充容量。如果連續2次接收到的資料報都小于指定值，則收縮目前的容量，以節約記憶體。

相對于FixedRecvByteBufAllocator，使用AdaptiveRecvByteBufAllocator更為合理，可以在建立用戶端或者服務端的時候指定RecvByteBufAllocator，代碼如下：

 Bootstrap b = new Bootstrap();
            b.group(group)
             .channel(NioSocketChannel.class)
             .option(ChannelOption.TCP_NODELAY, true)
             .option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)      

如果預設沒有設定，則使用AdaptiveRecvByteBufAllocator。

另外值得注意的是，無論是接收緩沖區還是發送緩沖區，緩沖區的大小建議設定為消息的平均大小，不要設定成最大消息的上限，這會導緻額外的記憶體浪費。通過如下方式可以設定接收緩沖區的初始大小：

/**
	 * Creates a new predictor with the specified parameters.
	 * 
	 * @param minimum
	 *            the inclusive lower bound of the expected buffer size
	 * @param initial
	 *            the initial buffer size when no feed back was received
	 * @param maximum
	 *            the inclusive upper bound of the expected buffer size
	 */
	public AdaptiveRecvByteBufAllocator(int minimum, int initial, int maximum)      

對于消息發送，通常需要使用者自己構造ByteBuf并編碼，例如通過如下工具類建立消息發送緩沖區：

圖3-2 構造指定容量的緩沖區

3.5. 記憶體池

推送伺服器承載了海量的長連結，每個長連結實際就是一個會話。如果每個會話都持有心跳資料、接收緩沖區、指令集等資料結構，而且這些執行個體随着消息的處理朝生夕滅，這就會給伺服器帶來沉重的GC壓力，同時消耗大量的記憶體。

最有效的解決政策就是使用記憶體池，每個NioEventLoop線程處理N個鍊路，線上程内部，鍊路的處理時串行的。假如A鍊路首先被處理，它會建立接收緩沖區等對象，待解碼完成之後，構造的POJO對象被封裝成Task後投遞到背景的線程池中執行，然後接收緩沖區會被釋放，每條消息的接收和處理都會重複接收緩沖區的建立和釋放。如果使用記憶體池，則當A鍊路接收到新的資料報之後，從NioEventLoop的記憶體池中申請空閑的ByteBuf，解碼完成之後，調用release将ByteBuf釋放到記憶體池中，供後續B鍊路繼續使用。

使用記憶體池優化之後，單個NioEventLoop的ByteBuf申請和GC次數從原來的N = 1000000/64 = 15625 次減少為最少0次（假設每次申請都有可用的記憶體）。

下面我們以推特使用Netty4的PooledByteBufAllocator進行GC優化作為案例，對記憶體池的效果進行評估，結果如下：

垃圾生成速度是原來的1/5，而垃圾清理速度快了5倍。使用新的記憶體池機制，幾乎可以把網絡帶寬壓滿。

Netty4之前的版本問題如下：每當收到新資訊或者使用者發送資訊到遠端端，Netty 3均會建立一個新的堆緩沖區。這意味着，對應每一個新的緩沖區，都會有一個new byte[capacity]。這些緩沖區會導緻GC壓力，并消耗記憶體帶寬。為了安全起見，新的位元組數組配置設定時會用零填充，這會消耗記憶體帶寬。然而，用零填充的數組很可能會再次用實際的資料填充，這又會消耗同樣的記憶體帶寬。如果Java虛拟機（JVM）提供了建立新位元組數組而又無需用零填充的方式，那麼我們本來就可以将記憶體帶寬消耗減少50%，但是目前沒有那樣一種方式。

在Netty 4中實作了一個新的ByteBuf記憶體池，它是一個純Java版本的 jemalloc （Facebook也在用）。現在，Netty不會再因為用零填充緩沖區而浪費記憶體帶寬了。不過，由于它不依賴于GC，開發人員需要小心記憶體洩漏。如果忘記在處理程式中釋放緩沖區，那麼記憶體使用率會無限地增長。

Netty預設不使用記憶體池，需要在建立用戶端或者服務端的時候進行指定，代碼如下：

Bootstrap b = new Bootstrap();
            b.group(group)
             .channel(NioSocketChannel.class)
             .option(ChannelOption.TCP_NODELAY, true)
             .option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)      

使用記憶體池之後，記憶體的申請和釋放必須成對出現，即retain()和release()要成對出現，否則會導緻記憶體洩露。

值得注意的是，如果使用記憶體池，完成ByteBuf的解碼工作之後必須顯式的調用ReferenceCountUtil.release(msg)對接收緩沖區ByteBuf進行記憶體釋放，否則它會被認為仍然在使用中，這樣會導緻記憶體洩露。

3.6. 當心“日志隐形殺手”

通常情況下，大家都知道不能在Netty的I/O線程上做執行時間不可控的操作，例如通路資料庫、發送Email等。但是有個常用但是非常危險的操作卻容易被忽略，那便是記錄日志。

通常，在生産環境中，需要實時列印接口日志，其它日志處于ERROR級别，當推送服務發生I/O異常之後，會記錄異常日志。如果目前磁盤的WIO比較高，可能會發生寫日志檔案操作被同步阻塞，阻塞時間無法預測。這就會導緻Netty的NioEventLoop線程被阻塞，Socket鍊路無法被及時關閉、其它的鍊路也無法進行讀寫操作等。

以最常用的log4j為例，盡管它支援異步寫日志（AsyncAppender），但是當日志隊列滿之後，它會同步阻塞業務線程，直到日志隊列有空閑位置可用，相關代碼如下：

 synchronized (this.buffer) {
      while (true) {
        int previousSize = this.buffer.size();
        if (previousSize < this.bufferSize) {
          this.buffer.add(event);
          if (previousSize != 0) break;
          this.buffer.notifyAll(); break;
        }
        boolean discard = true;
        if ((this.blocking) && (!Thread.interrupted()) && (Thread.currentThread() != this.dispatcher)) //判斷是業務線程
        {
          try
          {
            this.buffer.wait();//阻塞業務線程
            discard = false;
          }
          catch (InterruptedException e)
          {
            Thread.currentThread().interrupt();
          }

        }      

類似這類BUG具有極強的隐蔽性，往往WIO高的時間持續非常短，或者是偶現的，在測試環境中很難模拟此類故障，問題定位難度非常大。這就要求讀者在平時寫代碼的時候一定要當心，注意那些隐性地雷。

3.7. TCP參數優化

常用的TCP參數，例如TCP層面的接收和發送緩沖區大小設定，在Netty中分别對應ChannelOption的SO_SNDBUF和SO_RCVBUF，需要根據推送消息的大小，合理設定，對于海量長連接配接，通常32K是個不錯的選擇。

另外一個比較常用的優化手段就是軟中斷，如圖所示：如果所有的軟中斷都運作在CPU0相應網卡的硬體中斷上，那麼始終都是cpu0在處理軟中斷，而此時其它CPU資源就被浪費了，因為無法并行的執行多個軟中斷。

圖3-3 中斷資訊

大于等于2.6.35版本的Linux kernel核心，開啟RPS，網絡通信性能提升20%之上。RPS的基本原理：根據資料包的源位址，目的位址以及目的和源端口，計算出一個hash值，然後根據這個hash值來選擇軟中斷運作的cpu。從上層來看，也就是說将每個連接配接和cpu綁定，并通過這個hash值，來均衡軟中斷運作在多個cpu上，進而提升通信性能。

3.8. JVM參數

最重要的參數調整有兩個：

• -Xmx:JVM最大記憶體需要根據記憶體模型進行計算并得出相對合理的值；
• GC相關的參數: 例如新生代和老生代、永久代的比例，GC的政策，新生代各區的比例等，需要根據具體的場景進行設定和測試，并不斷的優化，盡量将Full GC的頻率降到最低。

4. 作者簡介