Netty 系列之 Netty 百萬(wàn)級(jí)推送服務(wù)設(shè)計(jì)要點(diǎn)

• 李林鋒

1. 背景

1.1. 話題來(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)行分析，如下所示：

image

我們發(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ù)逗载，示例如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">[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ù)輸出省略</pre>

當(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)是否生效。

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">* soft　　nofile　　1000000

• hard　　nofile　　1000000</pre>

需要指出的是冻辩，盡管我們可以將單個(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)遷移圖如下所示：

image

圖 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 處理線程 NioEventLoop 支持兩種自定義 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è)脖旱，代碼如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">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}} {
// 心跳處理
}
}
}</pre>

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)代碼如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">public abstract class ByteBuffer
extends Buffer
implements Comparable <bytebuffer>{
final byte[] hb; // Non-null only for heap buffers
final int offset;
boolean isReadOnly;</bytebuffer></pre>

容量無(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衔瓮，代碼如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;"> Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.RCVBUF_ALLOCATOR, AdaptiveRecvByteBufAllocator.DEFAULT)</pre>

如果默認(rèn)沒(méi)有設(shè)置浊猾，則使用 AdaptiveRecvByteBufAllocator。

另外值得注意的是热鞍，無(wú)論是接收緩沖區(qū)還是發(fā)送緩沖區(qū)葫慎，緩沖區(qū)的大小建議設(shè)置為消息的平均大小，不要設(shè)置成最大消息的上限薇宠，這會(huì)導(dǎo)致額外的內(nèi)存浪費(fèi)偷办。通過(guò)如下方式可以設(shè)置接收緩沖區(qū)的初始大小：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">/**
* 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) </pre>

對(duì)于消息發(fā)送澄港，通常需要用戶(hù)自己構(gòu)造 ByteBuf 并編碼椒涯，例如通過(guò)如下工具類(lèi)創(chuàng)建消息發(fā)送緩沖區(qū)：

image

圖 3-2 構(gòu)造指定容量的緩沖區(qū)

3.5. 內(nèi)存池

推送服務(wù)器承載了海量的長(zhǎng)鏈接，每個(gè)長(zhǎng)鏈接實(shí)際就是一個(gè)會(huì)話慢睡。如果每個(gè)會(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)行指定，代碼如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;">Bootstrap b = new Bootstrap();
b.group(group)
.channel(NioSocketChannel.class)
.option(ChannelOption.TCP_NODELAY, true)
.option(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)</pre>

使用內(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)代碼如下：

<pre style="margin: 0px 0px 1.5rem; padding: 0px; font-family: Courier, "Courier New", monospace; display: block; font-weight: 400; background: rgb(249, 250, 252); border-radius: 5px; overflow: hidden;"> 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();
}

    }</pre>

類(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è)軟中斷。

image

圖 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 的頻率降到最低菩收。

4. 作者簡(jiǎn)介

李林鋒，2007 年畢業(yè)于東北大學(xué)鲸睛，2008 年進(jìn)入華為公司從事高性能通信軟件的設(shè)計(jì)和開(kāi)發(fā)工作娜饵，有 6 年 NIO 設(shè)計(jì)和開(kāi)發(fā)經(jīng)驗(yàn)，精通 Netty官辈、Mina 等 NIO 框架箱舞。Netty 中國(guó)社區(qū)創(chuàng)始人遍坟，《Netty 權(quán)威指南》作者。

聯(lián)系方式：新浪微博 Nettying 微信：Nettying