基于Netty的百万级推送服务设计要点
1. 背景
1.1. 話(huà)題來(lái)源
最近很多從事移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)開(kāi)發(fā)的同學(xué)給我發(fā)郵件或者微博私信我，咨詢(xún)推送服務(wù)相關(guān)的問(wèn)題。問(wèn)題五花八門(mén)，在幫助大家答疑解惑的過(guò)程中，我也對(duì)問(wèn)題進(jìn)行了總結(jié)，大概可以歸納為如下幾類(lèi)：
1，?Netty是否可以做推送服務(wù)器？
2，?如果使用Netty開(kāi)發(fā)推送服務(wù)，一個(gè)服務(wù)器最多可以支撐多少個(gè)客戶(hù)端？
3，?使用Netty開(kāi)發(fā)推送服務(wù)遇到的各種技術(shù)問(wèn)題。
由于咨詢(xún)者眾多，關(guān)注點(diǎn)也比較集中，我希望通過(guò)本文的案例分析和對(duì)推送服務(wù)設(shè)計(jì)要點(diǎn)的總結(jié)，幫助大家在實(shí)際工作中少走彎路。
1.2. 推送服務(wù)
移動(dòng)互聯(lián)網(wǎng)時(shí)代，推送(Push)服務(wù)成為App應(yīng)用不可或缺的重要組成部分，推送服務(wù)可以提升用戶(hù)的活躍度和留存率。我們的手機(jī)每天接收到各種各樣的廣告和提示消息等大多數(shù)都是通過(guò)推送服務(wù)實(shí)現(xiàn)的。
隨著物聯(lián)網(wǎng)的發(fā)展，大多數(shù)的智能家居都支持移動(dòng)推送服務(wù)，未來(lái)所有接入物聯(lián)網(wǎng)的智能設(shè)備都將是推送服務(wù)的客戶(hù)端，這就意味著推送服務(wù)未來(lái)會(huì)面臨海量的設(shè)備和終端接入。
1.3. 推送服務(wù)的特點(diǎn)
移動(dòng)推送服務(wù)的主要特點(diǎn)如下：
1，?使用的網(wǎng)絡(luò)主要是運(yùn)營(yíng)商的無(wú)線移動(dòng)網(wǎng)絡(luò)，網(wǎng)絡(luò)質(zhì)量不穩(wěn)定，例如在地鐵上信號(hào)就很差，容易發(fā)生網(wǎng)絡(luò)閃斷；
2，?海量的客戶(hù)端接入，而且通常使用長(zhǎng)連接，無(wú)論是客戶(hù)端還是服務(wù)端，資源消耗都非常大；
3，?由于谷歌的推送框架無(wú)法在國(guó)內(nèi)使用，Android的長(zhǎng)連接是由每個(gè)應(yīng)用各自維護(hù)的，這就意味著每臺(tái)安卓設(shè)備上會(huì)存在多個(gè)長(zhǎng)連接。即便沒(méi)有消息需要推送，長(zhǎng)連接本身的心跳消息量也是非常巨大的，這就會(huì)導(dǎo)致流量和耗電量的增加；
4，?不穩(wěn)定：消息丟失、重復(fù)推送、延遲送達(dá)、過(guò)期推送時(shí)有發(fā)生；
5，?垃圾消息滿(mǎn)天飛，缺乏統(tǒng)一的服務(wù)治理能力。
為了解決上述弊端，一些企業(yè)也給出了自己的解決方案，例如京東云推出的推送服務(wù)，可以實(shí)現(xiàn)多應(yīng)用單服務(wù)單連接模式，使用AlarmManager定時(shí)心跳節(jié)省電量和流量。
2. 智能家居領(lǐng)域一個(gè)真實(shí)案例
2.1. 問(wèn)題描述
智能家居MQTT消息服務(wù)中間件，保持10萬(wàn)用戶(hù)在線長(zhǎng)連接，2萬(wàn)用戶(hù)并發(fā)做消息請(qǐng)求。程序運(yùn)行一段時(shí)間之后，發(fā)現(xiàn)內(nèi)存泄露，懷疑是Netty的Bug。其它相關(guān)信息如下：
1，?MQTT消息服務(wù)中間件服務(wù)器內(nèi)存16G，8個(gè)核心CPU；
2，?Netty中boss線程池大小為1，worker線程池大小為6，其余線程分配給業(yè)務(wù)使用。該分配方式后來(lái)調(diào)整為worker線程池大小為11，問(wèn)題依舊；
3，?Netty版本為4.0.8.Final。
2.2. 問(wèn)題定位
首先需要dump內(nèi)存堆棧，對(duì)疑似內(nèi)存泄露的對(duì)象和引用關(guān)系進(jìn)行分析，如下所示：
我們發(fā)現(xiàn)Netty的ScheduledFutureTask增加了9076%，達(dá)到110W個(gè)左右的實(shí)例，通過(guò)對(duì)業(yè)務(wù)代碼的分析發(fā)現(xiàn)用戶(hù)使用IdleStateHandler用于在鏈路空閑時(shí)進(jìn)行業(yè)務(wù)邏輯處理，但是空閑時(shí)間設(shè)置的比較大，為15分鐘。
Netty的IdleStateHandler會(huì)根據(jù)用戶(hù)的使用場(chǎng)景，啟動(dòng)三類(lèi)定時(shí)任務(wù)，分別是：ReaderIdleTimeoutTask、WriterIdleTimeoutTask和AllIdleTimeoutTask，它們都會(huì)被加入到NioEventLoop的Task隊(duì)列中被調(diào)度和執(zhí)行。
由于超時(shí)時(shí)間過(guò)長(zhǎng)，10W個(gè)長(zhǎng)鏈接鏈路會(huì)創(chuàng)建10W個(gè)ScheduledFutureTask對(duì)象，每個(gè)對(duì)象還保存有業(yè)務(wù)的成員變量，非常消耗內(nèi)存。用戶(hù)的持久代設(shè)置的比較大，一些定時(shí)任務(wù)被老化到持久代中，沒(méi)有被JVM垃圾回收掉，內(nèi)存一直在增長(zhǎng)，用戶(hù)誤認(rèn)為存在內(nèi)存泄露。
事實(shí)上，我們進(jìn)一步分析發(fā)現(xiàn)，用戶(hù)的超時(shí)時(shí)間設(shè)置的非常不合理，15分鐘的超時(shí)達(dá)不到設(shè)計(jì)目標(biāo)，重新設(shè)計(jì)之后將超時(shí)時(shí)間設(shè)置為45秒，內(nèi)存可以正常回收，問(wèn)題解決。
2.3. 問(wèn)題總結(jié)
如果是100個(gè)長(zhǎng)連接，即便是長(zhǎng)周期的定時(shí)任務(wù)，也不存在內(nèi)存泄露問(wèn)題，在新生代通過(guò)minor GC就可以實(shí)現(xiàn)內(nèi)存回收。正是因?yàn)槭f(wàn)級(jí)的長(zhǎng)連接，導(dǎo)致小問(wèn)題被放大，引出了后續(xù)的各種問(wèn)題。
事實(shí)上，如果用戶(hù)確實(shí)有長(zhǎng)周期運(yùn)行的定時(shí)任務(wù)，該如何處理？對(duì)于海量長(zhǎng)連接的推送服務(wù)，代碼處理稍有不慎，就滿(mǎn)盤(pán)皆輸，下面我們針對(duì)Netty的架構(gòu)特點(diǎn)，介紹下如何使用Netty實(shí)現(xiàn)百萬(wàn)級(jí)客戶(hù)端的推送服務(wù)。
3. Netty海量推送服務(wù)設(shè)計(jì)要點(diǎn)
作為高性能的NIO框架，利用Netty開(kāi)發(fā)高效的推送服務(wù)技術(shù)上是可行的，但是由于推送服務(wù)自身的復(fù)雜性，想要開(kāi)發(fā)出穩(wěn)定、高性能的推送服務(wù)并非易事，需要在設(shè)計(jì)階段針對(duì)推送服務(wù)的特點(diǎn)進(jìn)行合理設(shè)計(jì)。
3.1. 最大句柄數(shù)修改
百萬(wàn)長(zhǎng)連接接入，首先需要優(yōu)化的就是Linux內(nèi)核參數(shù)，其中Linux最大文件句柄數(shù)是最重要的調(diào)優(yōu)參數(shù)之一，默認(rèn)單進(jìn)程打開(kāi)的最大句柄數(shù)是1024，通過(guò)ulimit -a可以查看相關(guān)參數(shù)，示例如下：
[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
......后續(xù)輸出省略
當(dāng)單個(gè)推送服務(wù)接收到的鏈接超過(guò)上限后，就會(huì)報(bào)“too many open files”，所有新的客戶(hù)端接入將失敗。
通過(guò)vi /etc/security/limits.conf 添加如下配置參數(shù)：修改之后保存，注銷(xiāo)當(dāng)前用戶(hù)，重新登錄，通過(guò)ulimit -a 查看修改的狀態(tài)是否生效。
* soft nofile 1000000
* hard nofile 1000000
需要指出的是，盡管我們可以將單個(gè)進(jìn)程打開(kāi)的最大句柄數(shù)修改的非常大，但是當(dāng)句柄數(shù)達(dá)到一定數(shù)量級(jí)之后，處理效率將出現(xiàn)明顯下降，因此，需要根據(jù)服務(wù)器的硬件配置和處理能力進(jìn)行合理設(shè)置。如果單個(gè)服務(wù)器性能不行也可以通過(guò)集群的方式實(shí)現(xiàn)。
3.2. 當(dāng)心CLOSE_WAIT
從事移動(dòng)推送服務(wù)開(kāi)發(fā)的同學(xué)可能都有體會(huì)，移動(dòng)無(wú)線網(wǎng)絡(luò)可靠性非常差，經(jīng)常存在客戶(hù)端重置連接，網(wǎng)絡(luò)閃斷等。
在百萬(wàn)長(zhǎng)連接的推送系統(tǒng)中，服務(wù)端需要能夠正確處理這些網(wǎng)絡(luò)異常，設(shè)計(jì)要點(diǎn)如下：
1，?客戶(hù)端的重連間隔需要合理設(shè)置，防止連接過(guò)于頻繁導(dǎo)致的連接失敗（例如端口還沒(méi)有被釋放）；
2，?客戶(hù)端重復(fù)登陸拒絕機(jī)制；
3，?服務(wù)端正確處理I/O異常和解碼異常等，防止句柄泄露。
最后特別需要注意的一點(diǎn)就是close_wait 過(guò)多問(wèn)題，由于網(wǎng)絡(luò)不穩(wěn)定經(jīng)常會(huì)導(dǎo)致客戶(hù)端斷連，如果服務(wù)端沒(méi)有能夠及時(shí)關(guān)閉socket，就會(huì)導(dǎo)致處于close_wait狀態(tài)的鏈路過(guò)多。close_wait狀態(tài)的鏈路并不釋放句柄和內(nèi)存等資源，如果積壓過(guò)多可能會(huì)導(dǎo)致系統(tǒng)句柄耗盡，發(fā)生“Too many open files”異常，新的客戶(hù)端無(wú)法接入，涉及創(chuàng)建或者打開(kāi)句柄的操作都將失敗。
下面對(duì)close_wait狀態(tài)進(jìn)行下簡(jiǎn)單介紹，被動(dòng)關(guān)閉TCP連接狀態(tài)遷移圖如下所示：
圖3-1 被動(dòng)關(guān)閉TCP連接狀態(tài)遷移圖
close_wait是被動(dòng)關(guān)閉連接是形成的，根據(jù)TCP狀態(tài)機(jī)，服務(wù)器端收到客戶(hù)端發(fā)送的FIN，TCP協(xié)議棧會(huì)自動(dòng)發(fā)送ACK，鏈接進(jìn)入close_wait狀態(tài)。但如果服務(wù)器端不執(zhí)行socket的close()操作，狀態(tài)就不能由close_wait遷移到last_ack，則系統(tǒng)中會(huì)存在很多close_wait狀態(tài)的連接。通常來(lái)說(shuō)，一個(gè)close_wait會(huì)維持至少2個(gè)小時(shí)的時(shí)間（系統(tǒng)默認(rèn)超時(shí)時(shí)間的是7200秒，也就是2小時(shí)）。如果服務(wù)端程序因某個(gè)原因?qū)е孪到y(tǒng)造成一堆close_wait消耗資源，那么通常是等不到釋放那一刻，系統(tǒng)就已崩潰。
導(dǎo)致close_wait過(guò)多的可能原因如下：
1，?程序處理Bug，導(dǎo)致接收到對(duì)方的fin之后沒(méi)有及時(shí)關(guān)閉socket，這可能是Netty的Bug，也可能是業(yè)務(wù)層Bug，需要具體問(wèn)題具體分析；
2，?關(guān)閉socket不及時(shí)：例如I/O線程被意外阻塞，或者I/O線程執(zhí)行的用戶(hù)自定義Task比例過(guò)高，導(dǎo)致I/O操作處理不及時(shí)，鏈路不能被及時(shí)釋放。
下面我們結(jié)合Netty的原理，對(duì)潛在的故障點(diǎn)進(jìn)行分析。
設(shè)計(jì)要點(diǎn)1：不要在Netty的I/O線程上處理業(yè)務(wù)（心跳發(fā)送和檢測(cè)除外）。
Why? 對(duì)于Java進(jìn)程，線程不能無(wú)限增長(zhǎng)，這就意味著Netty的Reactor線程數(shù)必須收斂。Netty的默認(rèn)值是CPU核數(shù) * 2，通常情況下，I/O密集型應(yīng)用建議線程數(shù)盡量設(shè)置大些，但這主要是針對(duì)傳統(tǒng)同步I/O而言，對(duì)于非阻塞I/O，線程數(shù)并不建議設(shè)置太大，盡管沒(méi)有最優(yōu)值，但是I/O線程數(shù)經(jīng)驗(yàn)值是[CPU核數(shù) + 1，CPU核數(shù)*2 ]之間。
假如單個(gè)服務(wù)器支撐100萬(wàn)個(gè)長(zhǎng)連接，服務(wù)器內(nèi)核數(shù)為32，則單個(gè)I/O線程處理的鏈接數(shù)L = 100/(32 * 2) = 15625。 假如每5S有一次消息交互（新消息推送、心跳消息和其它管理消息），則平均CAPS = 15625 / 5 = 3125條/秒。這個(gè)數(shù)值相比于Netty的處理性能而言壓力并不大，但是在實(shí)際業(yè)務(wù)處理中，經(jīng)常會(huì)有一些額外的復(fù)雜邏輯處理，例如性能統(tǒng)計(jì)、記錄接口日志等，這些業(yè)務(wù)操作性能開(kāi)銷(xiāo)也比較大，如果在I/O線程上直接做業(yè)務(wù)邏輯處理，可能會(huì)阻塞I/O線程，影響對(duì)其它鏈路的讀寫(xiě)操作，這就會(huì)導(dǎo)致被動(dòng)關(guān)閉的鏈路不能及時(shí)關(guān)閉，造成close_wait堆積。
設(shè)計(jì)要點(diǎn)2：在I/O線程上執(zhí)行自定義Task要當(dāng)心。Netty的I/O處理線程N(yùn)ioEventLoop支持兩種自定義Task的執(zhí)行：
1，?普通的Runnable: 通過(guò)調(diào)用NioEventLoop的execute(Runnable task)方法執(zhí)行；
2，?定時(shí)任務(wù)ScheduledFutureTask:通過(guò)調(diào)用NioEventLoop的schedule(Runnable command, long delay, TimeUnit unit)系列接口執(zhí)行。
為什么NioEventLoop要支持用戶(hù)自定義Runnable和ScheduledFutureTask的執(zhí)行，并不是本文要討論的重點(diǎn)，后續(xù)會(huì)有專(zhuān)題文章進(jìn)行介紹。本文重點(diǎn)對(duì)它們的影響進(jìn)行分析。
在NioEventLoop中執(zhí)行Runnable和ScheduledFutureTask，意味著允許用戶(hù)在NioEventLoop中執(zhí)行非I/O操作類(lèi)的業(yè)務(wù)邏輯，這些業(yè)務(wù)邏輯通常用消息報(bào)文的處理和協(xié)議管理相關(guān)。它們的執(zhí)行會(huì)搶占NioEventLoop I/O讀寫(xiě)的CPU時(shí)間，如果用戶(hù)自定義Task過(guò)多，或者單個(gè)Task執(zhí)行周期過(guò)長(zhǎng)，會(huì)導(dǎo)致I/O讀寫(xiě)操作被阻塞，這樣也間接導(dǎo)致close_wait堆積。
所以，如果用戶(hù)在代碼中使用到了Runnable和ScheduledFutureTask，請(qǐng)合理設(shè)置ioRatio的比例，通過(guò)NioEventLoop的setIoRatio(int ioRatio)方法可以設(shè)置該值，默認(rèn)值為50，即I/O操作和用戶(hù)自定義任務(wù)的執(zhí)行時(shí)間比為1：1。
我的建議是當(dāng)服務(wù)端處理海量客戶(hù)端長(zhǎng)連接的時(shí)候，不要在NioEventLoop中執(zhí)行自定義Task，或者非心跳類(lèi)的定時(shí)任務(wù)。
設(shè)計(jì)要點(diǎn)3：IdleStateHandler使用要當(dāng)心。很多用戶(hù)會(huì)使用IdleStateHandler做心跳發(fā)送和檢測(cè)，這種用法值得提倡。相比于自己?jiǎn)⒍〞r(shí)任務(wù)發(fā)送心跳，這種方式更高效。但是在實(shí)際開(kāi)發(fā)中需要注意的是，在心跳的業(yè)務(wù)邏輯處理中，無(wú)論是正常還是異常場(chǎng)景，處理時(shí)延要可控，防止時(shí)延不可控導(dǎo)致的NioEventLoop被意外阻塞。例如，心跳超時(shí)或者發(fā)生I/O異常時(shí)，業(yè)務(wù)調(diào)用Email發(fā)送接口告警，由于Email服務(wù)端處理超時(shí)，導(dǎo)致郵件發(fā)送客戶(hù)端被阻塞，級(jí)聯(lián)引起IdleStateHandler的AllIdleTimeoutTask任務(wù)被阻塞，最終NioEventLoop多路復(fù)用器上其它的鏈路讀寫(xiě)被阻塞。
對(duì)于ReadTimeoutHandler和WriteTimeoutHandler，約束同樣存在。
3.3. 合理的心跳周期
百萬(wàn)級(jí)的推送服務(wù)，意味著會(huì)存在百萬(wàn)個(gè)長(zhǎng)連接，每個(gè)長(zhǎng)連接都需要靠和App之間的心跳來(lái)維持鏈路。合理設(shè)置心跳周期是非常重要的工作，推送服務(wù)的心跳周期設(shè)置需要考慮移動(dòng)無(wú)線網(wǎng)絡(luò)的特點(diǎn)。
當(dāng)一臺(tái)智能手機(jī)連上移動(dòng)網(wǎng)絡(luò)時(shí)，其實(shí)并沒(méi)有真正連接上Internet，運(yùn)營(yíng)商分配給手機(jī)的IP其實(shí)是運(yùn)營(yíng)商的內(nèi)網(wǎng)IP，手機(jī)終端要連接上Internet還必須通過(guò)運(yùn)營(yíng)商的網(wǎng)關(guān)進(jìn)行IP地址的轉(zhuǎn)換，這個(gè)網(wǎng)關(guān)簡(jiǎn)稱(chēng)為NAT(NetWork Address Translation)，簡(jiǎn)單來(lái)說(shuō)就是手機(jī)終端連接Internet 其實(shí)就是移動(dòng)內(nèi)網(wǎng)IP，端口，外網(wǎng)IP之間相互映射。
GGSN(GateWay GPRS Support Note)模塊就實(shí)現(xiàn)了NAT功能，由于大部分的移動(dòng)無(wú)線網(wǎng)絡(luò)運(yùn)營(yíng)商為了減少網(wǎng)關(guān)NAT映射表的負(fù)荷，如果一個(gè)鏈路有一段時(shí)間沒(méi)有通信時(shí)就會(huì)刪除其對(duì)應(yīng)表，造成鏈路中斷，正是這種刻意縮短空閑連接的釋放超時(shí)，原本是想節(jié)省信道資源的作用，沒(méi)想到讓互聯(lián)網(wǎng)的應(yīng)用不得以遠(yuǎn)高于正常頻率發(fā)送心跳來(lái)維護(hù)推送的長(zhǎng)連接。以中移動(dòng)的2.5G網(wǎng)絡(luò)為例，大約5分鐘左右的基帶空閑，連接就會(huì)被釋放。
由于移動(dòng)無(wú)線網(wǎng)絡(luò)的特點(diǎn)，推送服務(wù)的心跳周期并不能設(shè)置的太長(zhǎng)，否則長(zhǎng)連接會(huì)被釋放，造成頻繁的客戶(hù)端重連，但是也不能設(shè)置太短，否則在當(dāng)前缺乏統(tǒng)一心跳框架的機(jī)制下很容易導(dǎo)致信令風(fēng)暴（例如微信心跳信令風(fēng)暴問(wèn)題）。具體的心跳周期并沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，180S也許是個(gè)不錯(cuò)的選擇，微信為300S。
在Netty中，可以通過(guò)在ChannelPipeline中增加IdleStateHandler的方式實(shí)現(xiàn)心跳檢測(cè)，在構(gòu)造函數(shù)中指定鏈路空閑時(shí)間，然后實(shí)現(xiàn)空閑回調(diào)接口，實(shí)現(xiàn)心跳的發(fā)送和檢測(cè)，代碼如下：
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. 合理設(shè)置接收和發(fā)送緩沖區(qū)容量
對(duì)于長(zhǎng)鏈接，每個(gè)鏈路都需要維護(hù)自己的消息接收和發(fā)送緩沖區(qū)，JDK原生的NIO類(lèi)庫(kù)使用的是java.nio.ByteBuffer,它實(shí)際是一個(gè)長(zhǎng)度固定的Byte數(shù)組，我們都知道數(shù)組無(wú)法動(dòng)態(tài)擴(kuò)容，ByteBuffer也有這個(gè)限制，相關(guān)代碼如下：
public abstract class ByteBuffer
extends Buffer
implements Comparable{
final byte[] hb; // Non-null only for heap buffers
final int offset;
boolean isReadOnly;
容量無(wú)法動(dòng)態(tài)擴(kuò)展會(huì)給用戶(hù)帶來(lái)一些麻煩，例如由于無(wú)法預(yù)測(cè)每條消息報(bào)文的長(zhǎng)度，可能需要預(yù)分配一個(gè)比較大的ByteBuffer，這通常也沒(méi)有問(wèn)題。但是在海量推送服務(wù)系統(tǒng)中，這會(huì)給服務(wù)端帶來(lái)沉重的內(nèi)存負(fù)擔(dān)。假設(shè)單條推送消息最大上限為10K，消息平均大小為5K，為了滿(mǎn)足10K消息的處理，ByteBuffer的容量被設(shè)置為10K，這樣每條鏈路實(shí)際上多消耗了5K內(nèi)存，如果長(zhǎng)鏈接鏈路數(shù)為100萬(wàn)，每個(gè)鏈路都獨(dú)立持有ByteBuffer接收緩沖區(qū)，則額外損耗的總內(nèi)存 Total(M) = 1000000 * 5K = 4882M。內(nèi)存消耗過(guò)大，不僅僅增加了硬件成本，而且大內(nèi)存容易導(dǎo)致長(zhǎng)時(shí)間的Full GC，對(duì)系統(tǒng)穩(wěn)定性會(huì)造成比較大的沖擊。
實(shí)際上，最靈活的處理方式就是能夠動(dòng)態(tài)調(diào)整內(nèi)存，即接收緩沖區(qū)可以根據(jù)以往接收的消息進(jìn)行計(jì)算，動(dòng)態(tài)調(diào)整內(nèi)存，利用CPU資源來(lái)?yè)Q內(nèi)存資源，具體的策略如下：
1,?ByteBuffer支持容量的擴(kuò)展和收縮，可以按需靈活調(diào)整，以節(jié)約內(nèi)存；
2,?接收消息的時(shí)候，可以按照指定的算法對(duì)之前接收的消息大小進(jìn)行分析，并預(yù)測(cè)未來(lái)的消息大小，按照預(yù)測(cè)值靈活調(diào)整緩沖區(qū)容量，以做到最小的資源損耗滿(mǎn)足程序正常功能。
幸運(yùn)的是，Netty提供的ByteBuf支持容量動(dòng)態(tài)調(diào)整，對(duì)于接收緩沖區(qū)的內(nèi)存分配器，Netty提供了兩種：
1,?FixedRecvByteBufAllocator：固定長(zhǎng)度的接收緩沖區(qū)分配器，由它分配的ByteBuf長(zhǎng)度都是固定大小的，并不會(huì)根據(jù)實(shí)際數(shù)據(jù)報(bào)的大小動(dòng)態(tài)收縮。但是，如果容量不足，支持動(dòng)態(tài)擴(kuò)展。動(dòng)態(tài)擴(kuò)展是Netty ByteBuf的一項(xiàng)基本功能，與ByteBuf分配器的實(shí)現(xiàn)沒(méi)有關(guān)系；
2,?AdaptiveRecvByteBufAllocator：容量動(dòng)態(tài)調(diào)整的接收緩沖區(qū)分配器，它會(huì)根據(jù)之前Channel接收到的數(shù)據(jù)報(bào)大小進(jìn)行計(jì)算，如果連續(xù)填充滿(mǎn)接收緩沖區(qū)的可寫(xiě)空間，則動(dòng)態(tài)擴(kuò)展容量。如果連續(xù)2次接收到的數(shù)據(jù)報(bào)都小于指定值，則收縮當(dāng)前的容量，以節(jié)約內(nèi)存。
相對(duì)于FixedRecvByteBufAllocator，使用AdaptiveRecvByteBufAllocator更為合理，可以在創(chuàng)建客戶(hù)端或者服務(wù)端的時(shí)候指定RecvByteBufAllocator，代碼如下：
Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)
如果默認(rèn)沒(méi)有設(shè)置，則使用AdaptiveRecvByteBufAllocator。
另外值得注意的是，無(wú)論是接收緩沖區(qū)還是發(fā)送緩沖區(qū)，緩沖區(qū)的大小建議設(shè)置為消息的平均大小，不要設(shè)置成最大消息的上限，這會(huì)導(dǎo)致額外的內(nèi)存浪費(fèi)。通過(guò)如下方式可以設(shè)置接收緩沖區(qū)的初始大小：
/**
* 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)
對(duì)于消息發(fā)送，通常需要用戶(hù)自己構(gòu)造ByteBuf并編碼，例如通過(guò)如下工具類(lèi)創(chuàng)建消息發(fā)送緩沖區(qū)：
圖3-2 構(gòu)造指定容量的緩沖區(qū)
3.5. 內(nèi)存池
推送服務(wù)器承載了海量的長(zhǎng)鏈接，每個(gè)長(zhǎng)鏈接實(shí)際就是一個(gè)會(huì)話(huà)。如果每個(gè)會(huì)話(huà)都持有心跳數(shù)據(jù)、接收緩沖區(qū)、指令集等數(shù)據(jù)結(jié)構(gòu)，而且這些實(shí)例隨著消息的處理朝生夕滅，這就會(huì)給服務(wù)器帶來(lái)沉重的GC壓力，同時(shí)消耗大量的內(nèi)存。
最有效的解決策略就是使用內(nèi)存池，每個(gè)NioEventLoop線程處理N個(gè)鏈路，在線程內(nèi)部，鏈路的處理時(shí)串行的。假如A鏈路首先被處理，它會(huì)創(chuàng)建接收緩沖區(qū)等對(duì)象，待解碼完成之后，構(gòu)造的POJO對(duì)象被封裝成Task后投遞到后臺(tái)的線程池中執(zhí)行，然后接收緩沖區(qū)會(huì)被釋放，每條消息的接收和處理都會(huì)重復(fù)接收緩沖區(qū)的創(chuàng)建和釋放。如果使用內(nèi)存池，則當(dāng)A鏈路接收到新的數(shù)據(jù)報(bào)之后，從NioEventLoop的內(nèi)存池中申請(qǐng)空閑的ByteBuf，解碼完成之后，調(diào)用release將ByteBuf釋放到內(nèi)存池中，供后續(xù)B鏈路繼續(xù)使用。
使用內(nèi)存池優(yōu)化之后，單個(gè)NioEventLoop的ByteBuf申請(qǐng)和GC次數(shù)從原來(lái)的N = 1000000/64 = 15625 次減少為最少0次（假設(shè)每次申請(qǐng)都有可用的內(nèi)存）。
下面我們以推特使用Netty4的PooledByteBufAllocator進(jìn)行GC優(yōu)化作為案例，對(duì)內(nèi)存池的效果進(jìn)行評(píng)估，結(jié)果如下：
垃圾生成速度是原來(lái)的1/5，而垃圾清理速度快了5倍。使用新的內(nèi)存池機(jī)制，幾乎可以把網(wǎng)絡(luò)帶寬壓滿(mǎn)。
Netty4之前的版本問(wèn)題如下：每當(dāng)收到新信息或者用戶(hù)發(fā)送信息到遠(yuǎn)程端，Netty 3均會(huì)創(chuàng)建一個(gè)新的堆緩沖區(qū)。這意味著，對(duì)應(yīng)每一個(gè)新的緩沖區(qū)，都會(huì)有一個(gè)new byte[capacity]。這些緩沖區(qū)會(huì)導(dǎo)致GC壓力，并消耗內(nèi)存帶寬。為了安全起見(jiàn)，新的字節(jié)數(shù)組分配時(shí)會(huì)用零填充，這會(huì)消耗內(nèi)存帶寬。然而，用零填充的數(shù)組很可能會(huì)再次用實(shí)際的數(shù)據(jù)填充，這又會(huì)消耗同樣的內(nèi)存帶寬。如果Java虛擬機(jī)（JVM）提供了創(chuàng)建新字節(jié)數(shù)組而又無(wú)需用零填充的方式，那么我們本來(lái)就可以將內(nèi)存帶寬消耗減少50%，但是目前沒(méi)有那樣一種方式。
在Netty 4中實(shí)現(xiàn)了一個(gè)新的ByteBuf內(nèi)存池，它是一個(gè)純Java版本的 jemalloc （Facebook也在用）。現(xiàn)在，Netty不會(huì)再因?yàn)橛昧闾畛渚彌_區(qū)而浪費(fèi)內(nèi)存帶寬了。不過(guò)，由于它不依賴(lài)于GC，開(kāi)發(fā)人員需要小心內(nèi)存泄漏。如果忘記在處理程序中釋放緩沖區(qū)，那么內(nèi)存使用率會(huì)無(wú)限地增長(zhǎng)。
Netty默認(rèn)不使用內(nèi)存池，需要在創(chuàng)建客戶(hù)端或者服務(wù)端的時(shí)候進(jìn)行指定,使用內(nèi)存池之后，內(nèi)存的申請(qǐng)和釋放必須成對(duì)出現(xiàn)，即retain()和release()要成對(duì)出現(xiàn)，否則會(huì)導(dǎo)致內(nèi)存泄露。
值得注意的是，如果使用內(nèi)存池，完成ByteBuf的解碼工作之后必須顯式的調(diào)用ReferenceCountUtil.release(msg)對(duì)接收緩沖區(qū)ByteBuf進(jìn)行內(nèi)存釋放，否則它會(huì)被認(rèn)為仍然在使用中，這樣會(huì)導(dǎo)致內(nèi)存泄露。
3.6. 當(dāng)心“日志隱形殺手”
通常情況下，大家都知道不能在Netty的I/O線程上做執(zhí)行時(shí)間不可控的操作，例如訪問(wèn)數(shù)據(jù)庫(kù)、發(fā)送Email等。但是有個(gè)常用但是非常危險(xiǎn)的操作卻容易被忽略，那便是記錄日志。
通常，在生產(chǎn)環(huán)境中，需要實(shí)時(shí)打印接口日志，其它日志處于ERROR級(jí)別，當(dāng)推送服務(wù)發(fā)生I/O異常之后，會(huì)記錄異常日志。如果當(dāng)前磁盤(pán)的WIO比較高，可能會(huì)發(fā)生寫(xiě)日志文件操作被同步阻塞，阻塞時(shí)間無(wú)法預(yù)測(cè)。這就會(huì)導(dǎo)致Netty的NioEventLoop線程被阻塞，Socket鏈路無(wú)法被及時(shí)關(guān)閉、其它的鏈路也無(wú)法進(jìn)行讀寫(xiě)操作等。
以最常用的log4j為例，盡管它支持異步寫(xiě)日志（AsyncAppender），但是當(dāng)日志隊(duì)列滿(mǎn)之后，它會(huì)同步阻塞業(yè)務(wù)線程，直到日志隊(duì)列有空閑位置可用，相關(guān)代碼如下：
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)) //判斷是業(yè)務(wù)線程
{
try
{
this.buffer.wait();//阻塞業(yè)務(wù)線程
discard = false;
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
}
類(lèi)似這類(lèi)BUG具有極強(qiáng)的隱蔽性，往往WIO高的時(shí)間持續(xù)非常短，或者是偶現(xiàn)的，在測(cè)試環(huán)境中很難模擬此類(lèi)故障，問(wèn)題定位難度非常大。這就要求讀者在平時(shí)寫(xiě)代碼的時(shí)候一定要當(dāng)心，注意那些隱性地雷。
3.7. TCP參數(shù)優(yōu)化
常用的TCP參數(shù)，例如TCP層面的接收和發(fā)送緩沖區(qū)大小設(shè)置，在Netty中分別對(duì)應(yīng)ChannelOption的SO_SNDBUF和SO_RCVBUF，需要根據(jù)推送消息的大小，合理設(shè)置，對(duì)于海量長(zhǎng)連接，通常32K是個(gè)不錯(cuò)的選擇。
另外一個(gè)比較常用的優(yōu)化手段就是軟中斷，如圖所示：如果所有的軟中斷都運(yùn)行在CPU0相應(yīng)網(wǎng)卡的硬件中斷上，那么始終都是cpu0在處理軟中斷，而此時(shí)其它CPU資源就被浪費(fèi)了，因?yàn)闊o(wú)法并行的執(zhí)行多個(gè)軟中斷。
圖3-3 中斷信息
大于等于2.6.35版本的Linux kernel內(nèi)核，開(kāi)啟RPS，網(wǎng)絡(luò)通信性能提升20%之上。RPS的基本原理：根據(jù)數(shù)據(jù)包的源地址，目的地址以及目的和源端口，計(jì)算出一個(gè)hash值，然后根據(jù)這個(gè)hash值來(lái)選擇軟中斷運(yùn)行的cpu。從上層來(lái)看，也就是說(shuō)將每個(gè)連接和cpu綁定，并通過(guò)這個(gè)hash值，來(lái)均衡軟中斷運(yùn)行在多個(gè)cpu上，從而提升通信性能。
3.8. JVM參數(shù)
最重要的參數(shù)調(diào)整有兩個(gè)：
-Xmx:JVM最大內(nèi)存需要根據(jù)內(nèi)存模型進(jìn)行計(jì)算并得出相對(duì)合理的值；
GC相關(guān)的參數(shù): 例如新生代和老生代、永久代的比例，GC的策略，新生代各區(qū)的比例等，需要根據(jù)具體的場(chǎng)景進(jìn)行設(shè)置和測(cè)試，并不斷的優(yōu)化，盡量將Full GC的頻率降到最低。
轉(zhuǎn)載于:https://blog.51cto.com/13902811/2307512
總結(jié)
以上是生活随笔為你收集整理的基于Netty的百万级推送服务设计要点的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Android dependency '
- 下一篇： VRRP网关冗余