甄凱成，黃 河，宋良圖

1.中國(guó)科學(xué)院 合肥智能機(jī)械研究所，合肥230031

2.中國(guó)科學(xué)技術(shù)大學(xué)，合肥230026

1 引言

由于云計(jì)算和數(shù)據(jù)分析技術(shù)的高速發(fā)展，使得智慧城市[1]、精細(xì)農(nóng)業(yè)[2]、車(chē)聯(lián)網(wǎng)[3]、環(huán)境保護(hù)、工業(yè)監(jiān)測(cè)[4]等物聯(lián)網(wǎng)廣泛應(yīng)用領(lǐng)域的數(shù)據(jù)獲取變得愈發(fā)重要，進(jìn)而促使各種物聯(lián)網(wǎng)采集終端設(shè)備數(shù)量爆炸增長(zhǎng)。設(shè)備數(shù)量及其感知的數(shù)據(jù)量的快速增長(zhǎng)為用戶帶來(lái)了更精準(zhǔn)的趨勢(shì)預(yù)測(cè)和更便利的生活服務(wù)，但同時(shí)，也為服務(wù)端數(shù)據(jù)收集帶來(lái)挑戰(zhàn)。如何滿足大量終端接入并快速處理終端上傳的數(shù)據(jù)成為亟待解決的問(wèn)題。

物聯(lián)網(wǎng)數(shù)據(jù)上層網(wǎng)絡(luò)通信協(xié)議雖然在應(yīng)用層上有多種不同的體現(xiàn)，但其在傳輸層及下層網(wǎng)絡(luò)中基本上是遵從TCP/IP 網(wǎng)絡(luò)協(xié)議的[5]。因而用來(lái)接收物聯(lián)網(wǎng)數(shù)據(jù)的服務(wù)可以參考一般的網(wǎng)絡(luò)通信服務(wù)。

Netty 由于性能優(yōu)越、安全性高、使用簡(jiǎn)便、社區(qū)資源豐富等特點(diǎn)使得其從諸多網(wǎng)絡(luò)通信庫(kù)中脫穎而出，成為高性能的通信領(lǐng)域的首選框架。當(dāng)前，Netty 已成功應(yīng)用在諸多流行項(xiàng)目中，如Cassandra、Spark[6]、Hadoop[7]等大數(shù)據(jù)領(lǐng)域；Dubbo、gRPC 等分布式通信框架均有Netty 的身影。在物聯(lián)網(wǎng)相關(guān)領(lǐng)域，Duan 等人[8]基于Netty 專用協(xié)議棧研究的基礎(chǔ)上，結(jié)合責(zé)任鏈的網(wǎng)絡(luò)協(xié)議體系結(jié)構(gòu)，在遠(yuǎn)程醫(yī)療監(jiān)護(hù)系統(tǒng)上實(shí)現(xiàn)了醫(yī)療數(shù)據(jù)業(yè)務(wù)的快速傳輸。還有基于Netty實(shí)現(xiàn)的車(chē)輛遠(yuǎn)程監(jiān)控通信服務(wù)系統(tǒng)，該系統(tǒng)從網(wǎng)絡(luò)設(shè)計(jì)模式、協(xié)議解析模式、共享數(shù)據(jù)同步和線程池四個(gè)方面進(jìn)行優(yōu)化[9]。此外，在滑坡等地質(zhì)災(zāi)害監(jiān)測(cè)系統(tǒng)中，Netty 也被用來(lái)處理全球?qū)Ш叫l(wèi)星系統(tǒng)終端上傳的大量、高頻數(shù)據(jù)[10]。

但是，在高并發(fā)環(huán)境下，為處理終端上傳的數(shù)據(jù)，大量的同步耗時(shí)操作特別容易導(dǎo)致程序阻塞，從而帶來(lái)通信的響應(yīng)時(shí)間過(guò)長(zhǎng)、吞吐量低等情況。使用消息中間件的異步傳送方式將消息接收與寫(xiě)入數(shù)據(jù)庫(kù)這種耗時(shí)操作解耦[11]，可以避免上述情況的發(fā)生。Kafka 作為一款優(yōu)秀的消息系統(tǒng)也已被應(yīng)用于物聯(lián)網(wǎng)相關(guān)領(lǐng)域中。如在CO2監(jiān)測(cè)系統(tǒng)的數(shù)據(jù)使用Kafka流平臺(tái)分發(fā)到數(shù)據(jù)庫(kù)中[12]。俄勒岡老齡科技中心在臨床監(jiān)測(cè)系統(tǒng)中使用Kafka使得其數(shù)據(jù)處理能力實(shí)時(shí)性更高[13]。在電網(wǎng)設(shè)備數(shù)據(jù)接入系統(tǒng)中，也大量使用到Kafka消息隊(duì)列以保證其數(shù)據(jù)處理的實(shí)時(shí)性[14]。

基于上述討論，本文使用Netty 網(wǎng)絡(luò)通信框架和Kafka消息隊(duì)列搭建了可供物聯(lián)網(wǎng)采集終端使用的數(shù)據(jù)接入系統(tǒng)。本文還自行設(shè)計(jì)一個(gè)可供參考的終端設(shè)備與消息收集端的通信協(xié)議，在設(shè)計(jì)協(xié)議過(guò)程中充分考慮了當(dāng)前的實(shí)際應(yīng)用易用性以及未來(lái)升級(jí)的可能性等因素。此外，多線程、線程池、堆外內(nèi)存、垃圾回收機(jī)制等方面的優(yōu)化，使得系統(tǒng)的性能得到提升。

2 相關(guān)技術(shù)

2.1 Netty的Reactor線程模型

目前高性能網(wǎng)絡(luò)通信服務(wù)大多是基于epoll機(jī)制和多線程模型組合的實(shí)現(xiàn)。而Netty可依據(jù)用戶自定義的程序啟動(dòng)參數(shù)調(diào)整其運(yùn)行期間的線程模型。Netty官方推薦使用主從Reactor多線程模型。其主要特點(diǎn)是擁有多個(gè)線程池，其中主線程池是處理新的客戶端連接，處理完新連接后將新建的Socket 綁定到從線程池中的某個(gè)線程中；從線程池將負(fù)責(zé)后續(xù)對(duì)這個(gè)Socket 的讀寫(xiě)、編解碼、業(yè)務(wù)處理工作。設(shè)計(jì)主從Reactor 多線程模型的目的是將監(jiān)聽(tīng)端口服務(wù)與處理數(shù)據(jù)功能剝離開(kāi)來(lái)，從而提高處理數(shù)據(jù)的能力[15]。在實(shí)際應(yīng)用中，Netty 支持添加多個(gè)從線程池，可按照業(yè)務(wù)特性將不同的業(yè)務(wù)分配到不同的從線程池處理，或若干個(gè)特性相似的業(yè)務(wù)分配到同一個(gè)從線程池。如圖1所示，主線程池負(fù)責(zé)響應(yīng)新連接接入，從線程池1 負(fù)責(zé)編解碼業(yè)務(wù)，從線程池m 負(fù)責(zé)數(shù)據(jù)讀取業(yè)務(wù)，做到按特性分配，輔以合理的線程池參數(shù)，可令Netty的性能更出色。

2.2 Kafka流式消息處理系統(tǒng)

Kafka的commit log隊(duì)列是Kafka消息隊(duì)列概念的具體實(shí)現(xiàn)。生產(chǎn)者向commit log 隊(duì)列中發(fā)送流式消息，其他消費(fèi)者可以在毫秒級(jí)延時(shí)處理這些日志的最新信息。每個(gè)數(shù)據(jù)消費(fèi)者在commit log 中有一個(gè)自己的指針，并獨(dú)立移動(dòng)，從而促使消費(fèi)者們?cè)诜植际江h(huán)境下能可靠、順序地處理隊(duì)列中的消息。commit log可以被多個(gè)生產(chǎn)者和消費(fèi)者所共享，并覆蓋集群中的多臺(tái)機(jī)器，為集群中機(jī)器提供容錯(cuò)保障。Kafka 作為一個(gè)現(xiàn)代的分布式系統(tǒng)還可以便捷地水平擴(kuò)張和縮小。此外，Kafka 的消息代理（broker）能支持TB 級(jí)消息的持久化。上述特性使得Kafka 能夠?qū)⑵鋺?yīng)用范圍不僅局限于消息系統(tǒng)。

3 系統(tǒng)設(shè)計(jì)

3.1 系統(tǒng)架構(gòu)設(shè)計(jì)

系統(tǒng)的整體架構(gòu)設(shè)計(jì)如圖2 所示。采集終端一般由眾多可連接互聯(lián)網(wǎng)的嵌入式設(shè)備組成。消息收集端暴露IP地址和端口，供采集終端連接，當(dāng)有新的TCP連接或者新的消息發(fā)送時(shí)，都將觸發(fā)消息收集端的網(wǎng)絡(luò)通信處理程序。對(duì)于需要進(jìn)一步處理的消息將由消息收集端通過(guò)異步方式推送到Kafka集群中。之后，再由不同的Kafka consumer 進(jìn)程按照不同的業(yè)務(wù)需求來(lái)處理被推送到Kafka 集群中的消息。這些消息或被持久化到數(shù)據(jù)庫(kù)，或進(jìn)行其他實(shí)時(shí)計(jì)算。此外，Zookeeper用來(lái)監(jiān)測(cè)Kafka集群的運(yùn)行狀態(tài)，協(xié)調(diào)管理Kafka集群；同時(shí)Zookeeper還可預(yù)留作為協(xié)調(diào)管理收集端服務(wù)水平擴(kuò)展業(yè)務(wù)的服務(wù)軟件。

圖1 Netty多Reactor模型示意圖

引入Kafka 消息隊(duì)列來(lái)處理數(shù)據(jù)轉(zhuǎn)發(fā)業(yè)務(wù)有以下幾點(diǎn)原因：（1）若消息被收集端解析后，直接寫(xiě)入數(shù)據(jù)庫(kù)或者進(jìn)行數(shù)據(jù)分析等耗時(shí)操作，將會(huì)阻塞一條采集終端的連接，進(jìn)而降低系統(tǒng)的并發(fā)能力。（2）當(dāng)前數(shù)據(jù)的持久化操作一般會(huì)將熱點(diǎn)數(shù)據(jù)寫(xiě)入如Redis 的內(nèi)存數(shù)據(jù)庫(kù)，常規(guī)數(shù)據(jù)寫(xiě)入如MySQL的傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)。對(duì)于這種數(shù)據(jù)消費(fèi)多目的端的處理邏輯，利用多個(gè)Kafka 的consumer group 機(jī)制可以輕易地并發(fā)實(shí)現(xiàn)。（3）當(dāng)采集終端的數(shù)據(jù)上傳速率較消息處理速率快時(shí)，Kafka 內(nèi)部自帶數(shù)據(jù)持久化功能，能保證消息不丟失，且Kafka 集群還支持動(dòng)態(tài)擴(kuò)容能擴(kuò)展消息處理業(yè)務(wù)吞吐量。（4）當(dāng)單一的收集端服務(wù)不足以支撐大量采集終端的數(shù)據(jù)上傳時(shí)，也可利用Kafka 的多Producer 便捷地實(shí)現(xiàn)收集端服務(wù)的水平擴(kuò)展。（5）考慮到采集終端上傳的數(shù)據(jù)具有典型的流式數(shù)據(jù)特征，使用Kafka可以方便地拓展未來(lái)對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)分析處理業(yè)務(wù)。

3.2 通信協(xié)議設(shè)計(jì)

通信協(xié)議作為采集終端與收集端消息傳送的“模板”，在業(yè)務(wù)中有著十分重要的地位，是采集終端與收集端消息傳送的重要組成部分。雖然MQTT[16]等協(xié)議已被大量使用，但是其在點(diǎn)對(duì)點(diǎn)通信、群通信以及負(fù)載均衡等方面仍有缺陷。而定義私有協(xié)議可更具靈活性，可按照業(yè)務(wù)需求有針對(duì)性地優(yōu)化。故本文設(shè)計(jì)了一個(gè)協(xié)議以供參考。通信協(xié)議在設(shè)計(jì)過(guò)程中除了考慮常規(guī)的業(yè)務(wù)需求，也需考慮工程實(shí)現(xiàn)的難易程度、編解碼性能等，還需兼顧未來(lái)對(duì)業(yè)務(wù)擴(kuò)展與升級(jí)的影響。

本文通信協(xié)議的設(shè)計(jì)如圖3所示。協(xié)議由校驗(yàn)碼、版本號(hào)、指令號(hào)、數(shù)據(jù)長(zhǎng)度、數(shù)據(jù)五部分組成。

協(xié)議中各個(gè)組成部分的作用如下：

（1）校驗(yàn)碼

設(shè)計(jì)校驗(yàn)碼的主要意義是對(duì)采集終端進(jìn)行鑒權(quán)，即剔除非本應(yīng)用的采集終端連接，以防止惡意占用收集端資源。若校驗(yàn)不通過(guò)，收集端將直接關(guān)閉該條TCP 連接。本文校驗(yàn)碼設(shè)計(jì)成一個(gè)定值0x43218765。校驗(yàn)碼不使用定期更換策略，原因是簡(jiǎn)單的定值校驗(yàn)碼驗(yàn)證已經(jīng)能夠滿足大多情況下的校驗(yàn)；且定期更換策略需要收集端及時(shí)推送校驗(yàn)碼到各個(gè)采集終端，對(duì)收集端的性能是種損耗。

（2）版本號(hào)

協(xié)議版本號(hào)用來(lái)定義當(dāng)前通信協(xié)議的版本，是為將來(lái)對(duì)通信協(xié)議的升級(jí)預(yù)留位。此處借鑒常用的網(wǎng)絡(luò)通信協(xié)議的設(shè)計(jì)，如IP 數(shù)據(jù)報(bào)中前4 個(gè)比特為協(xié)議版本號(hào)。

（3）指令號(hào)

采集終端與收集端通信過(guò)程中有許多不同的消息類(lèi)型來(lái)應(yīng)對(duì)不同的業(yè)務(wù)邏輯。例如，采集終端消息發(fā)送間隔會(huì)因需求不同而不同，對(duì)于發(fā)送間隔較短的一些應(yīng)用使用長(zhǎng)連接的方式會(huì)顯著降低TCP 連接構(gòu)建過(guò)程中的網(wǎng)絡(luò)帶寬損耗；對(duì)于發(fā)送間隔較長(zhǎng)的應(yīng)用使用短連接的方式會(huì)降低收集端IO資源占用。因而需要針對(duì)不同的業(yè)務(wù)場(chǎng)景選擇合適的處理方式。指令號(hào)用來(lái)確定收集端的業(yè)務(wù)處理邏輯以及消息回傳的格式。

（4）數(shù)據(jù)長(zhǎng)度

圖2 系統(tǒng)架構(gòu)示意圖

圖3 通信協(xié)議結(jié)構(gòu)示意圖

本文設(shè)計(jì)的通信協(xié)議是基于TCP 傳輸。網(wǎng)絡(luò)本身的不穩(wěn)定性，可能會(huì)導(dǎo)致消息重傳；以及某些情況下因單條消息過(guò)大而導(dǎo)致的TCP 底層拆包等意外情況的出現(xiàn)。為防止消息編解碼錯(cuò)誤，本文使用在消息頭標(biāo)識(shí)該條消息傳輸數(shù)據(jù)長(zhǎng)度的方式來(lái)處理操作系統(tǒng)內(nèi)核對(duì)消息可能出現(xiàn)的拆包/粘包操作。相較于指定分隔符方式在二進(jìn)制編解碼過(guò)程中的大概率重復(fù)導(dǎo)致拆包/粘包失敗以及固定長(zhǎng)度方式的局限性，在消息頭標(biāo)識(shí)消息總長(zhǎng)度的方式是最佳選擇。此外Netty框架還對(duì)該種方式的工程實(shí)現(xiàn)提供了非常友好的支持。

（5）數(shù)據(jù)

數(shù)據(jù)即為消息實(shí)體實(shí)際所要傳輸?shù)膬?nèi)容。數(shù)據(jù)內(nèi)部的格式與指令號(hào)關(guān)聯(lián)性較強(qiáng)，不同的消息指令會(huì)有不同的數(shù)據(jù)格式。例如，心跳維護(hù)消息包中，數(shù)據(jù)這一部分為空，而在某些具體的業(yè)務(wù)消息中，數(shù)據(jù)就是采集終端實(shí)際所要傳輸?shù)母袷胶蛢?nèi)容。

3.3 消息收集端數(shù)據(jù)處理流程

本節(jié)主要介紹收集端大體的消息處理流程，對(duì)于采集終端的失敗重連機(jī)制，消息發(fā)送異常的多次重發(fā)機(jī)制等通信協(xié)議上處理流程不做過(guò)多介紹。

消息處理流程如圖4 所示。收集端服務(wù)在啟動(dòng)時(shí)將綁定并監(jiān)聽(tīng)一個(gè)網(wǎng)絡(luò)端口。當(dāng)有連接發(fā)送新消息時(shí)，收集端將完成以下步驟：（1）若連接發(fā)送消息完成，將觸發(fā)收集端的讀數(shù)據(jù)操作。（2）對(duì)消息頭的校驗(yàn)碼進(jìn)行驗(yàn)證，若驗(yàn)證不通過(guò)則關(guān)閉連接，若驗(yàn)證通過(guò)則繼續(xù)流程。（3）按照3.2節(jié)介紹的通信協(xié)議對(duì)讀取到二進(jìn)制的數(shù)據(jù)進(jìn)行解析，獲取到消息對(duì)象。（4）獲取消息指令，選擇與之對(duì)應(yīng)的Handler。（5）在Handler 內(nèi)部進(jìn)行業(yè)務(wù)處理。業(yè)務(wù)包含構(gòu)建應(yīng)答消息、日志記錄、按需將接收到的消息推送至Kafka等。

圖4 消息處理流程示意圖

3.4 性能優(yōu)化方式

為進(jìn)一步提升收集端服務(wù)性能，本文針對(duì)以下幾個(gè)方面做出優(yōu)化：（1）Netty會(huì)為每個(gè)連接構(gòu)建一個(gè)內(nèi)部節(jié)點(diǎn)為ChannelHandler類(lèi)型的雙向鏈表pipeline，默認(rèn)情況下數(shù)據(jù)會(huì)從鏈表頭節(jié)點(diǎn)依次傳輸?shù)芥湵砦补?jié)點(diǎn)，實(shí)際上多數(shù)業(yè)務(wù)不需要眾多中間節(jié)點(diǎn)處理，故使用ctx.write-AndFlush（）方法改變事件傳播源能有效壓縮事件傳播路徑，加速數(shù)據(jù)流轉(zhuǎn)。（2）將業(yè)務(wù)邏輯與網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)等耗費(fèi)資源相關(guān)的ChannelHandler 分配到獨(dú)立的線程池工作，避免長(zhǎng)時(shí)間程序阻塞。（3）調(diào)整部分Netty 與TCP網(wǎng)絡(luò)相關(guān)的啟動(dòng)參數(shù)如設(shè)置TCP_NODELAY 來(lái)禁用nagle[17]算法降低延遲，設(shè)置SO_RCVBUF、SO_SNDBUF來(lái)調(diào)整接收緩沖區(qū)和發(fā)送緩沖區(qū)的大小避免擁塞。（4）收集端服務(wù)程序由java實(shí)現(xiàn)，在程序運(yùn)行期間JVM的垃圾回收機(jī)制會(huì)導(dǎo)致程序短暫的假死，設(shè)置JVM 參數(shù)，合理分配堆、老年代、年輕代、堆外內(nèi)存大小避免頻繁Full GC。

4 實(shí)驗(yàn)驗(yàn)證與分析

4.1 實(shí)驗(yàn)環(huán)境

使用一臺(tái)Dell Optiplex 9020 搭建消息收集端服務(wù)；在一臺(tái)Dell R720 上使用Xen 虛擬機(jī)構(gòu)建集群環(huán)境并部署Kafka 和Zookeeper 應(yīng)用。此外，還使用多臺(tái)壓測(cè)機(jī)器來(lái)模擬大量TCP 連接，以對(duì)系統(tǒng)進(jìn)行性能測(cè)試。所有機(jī)器之間通過(guò)一個(gè)百兆交換機(jī)連接。消息收集端配置信息參數(shù)如表1所示。

表1 消息收集端機(jī)器配置信息

由Dell R720內(nèi)三個(gè)虛擬機(jī)組成的集群各節(jié)點(diǎn)環(huán)境參數(shù)如表2 所示。所有虛擬機(jī)節(jié)點(diǎn)的配置信息均一致。MySQL數(shù)據(jù)庫(kù)安裝在R720宿主機(jī)中。

表2 集群節(jié)點(diǎn)配置信息

4.2 消息收集端性能測(cè)試

消息收集端的并發(fā)處理能力與資源消耗情況將會(huì)極大限制整個(gè)系統(tǒng)的處理能力，因而需要測(cè)試在收集端性能以及當(dāng)前的網(wǎng)絡(luò)環(huán)境。

使用多臺(tái)壓測(cè)機(jī)器與消息收集端建立若干個(gè)TCP連接，每個(gè)連接以1 s 為間隔向消息收集端發(fā)送數(shù)據(jù)實(shí)體為當(dāng)前時(shí)間戳的數(shù)據(jù)包。收集端接收到數(shù)據(jù)包后將時(shí)間戳取出并返回至各自壓測(cè)機(jī)，壓測(cè)機(jī)接收到返回的數(shù)據(jù)包后取出原始的時(shí)間戳并與當(dāng)前的系統(tǒng)時(shí)間比較，從而計(jì)算平均響應(yīng)時(shí)間。以此來(lái)測(cè)試當(dāng)前的網(wǎng)絡(luò)環(huán)境以及消息收集端的處理性能。在實(shí)驗(yàn)時(shí)，需要修改操作系統(tǒng)的局部與全局文件句柄數(shù)限制，以防操作系統(tǒng)限制連接數(shù)量。

實(shí)驗(yàn)結(jié)果如表3所示，隨著連接數(shù)增大QPS有所升高，但其占連接數(shù)的比例沒(méi)有太大變化。平均響應(yīng)時(shí)間會(huì)隨著連接數(shù)的增加略有增大，需要注意的是響應(yīng)時(shí)間會(huì)因網(wǎng)絡(luò)狀況而有所波動(dòng)。內(nèi)存在不同的連接數(shù)下有所波動(dòng)，是由于JVM 的垃圾回收機(jī)制所導(dǎo)致的。CPU資源的消耗隨著連接數(shù)的增大而升高。在實(shí)驗(yàn)過(guò)程中發(fā)現(xiàn)當(dāng)一臺(tái)壓測(cè)機(jī)連接數(shù)超過(guò)5 000 時(shí)，發(fā)現(xiàn)其響應(yīng)時(shí)間大幅增加，其原因是壓測(cè)機(jī)的硬件資源消耗過(guò)多導(dǎo)致系統(tǒng)卡頓。在使用多臺(tái)壓測(cè)機(jī)并將連接分散到不同機(jī)器上后，響應(yīng)時(shí)間恢復(fù)為正常狀態(tài)，這也是6 000個(gè)TCP連接下響應(yīng)時(shí)間略好于4 000個(gè)TCP連接的原因。

表3 消息收集端性能測(cè)試

4.3 系統(tǒng)整體性能測(cè)試

實(shí)驗(yàn)與4.2 節(jié)類(lèi)似，使用多臺(tái)壓測(cè)機(jī)與消息收集端建立連接，并模擬發(fā)送真實(shí)的數(shù)據(jù)包，每個(gè)連接發(fā)送時(shí)間間隔為5s。收集端在接收到數(shù)據(jù)后將其推送到Kafka集群中，再由多個(gè)Kafka consumer將集群中數(shù)據(jù)消費(fèi)到MySQL 數(shù)據(jù)庫(kù)中。平均響應(yīng)時(shí)間獲取方式與4.2 節(jié)相同。以此驗(yàn)證系統(tǒng)在局域網(wǎng)環(huán)境下不同連接數(shù)的性能。

圖5 響應(yīng)時(shí)間對(duì)比圖

實(shí)驗(yàn)結(jié)果如圖5 所示。平均響應(yīng)時(shí)間保持在5 ms以下，說(shuō)明在百兆局域網(wǎng)環(huán)境下系統(tǒng)具有良好的性能。與4.2 節(jié)對(duì)比發(fā)現(xiàn)其響應(yīng)時(shí)間未明顯增加，其原因是使用異步方式將數(shù)據(jù)推送至Kafka 集群不會(huì)對(duì)線程運(yùn)行造成過(guò)大影響。此外，又對(duì)不使用Kafka消息隊(duì)列的情況進(jìn)行實(shí)驗(yàn)，即消息收集端接收到數(shù)據(jù)后直接寫(xiě)入數(shù)據(jù)庫(kù)。發(fā)現(xiàn)在不使用Kafka且連接數(shù)低于8 000的情況下系統(tǒng)性能正常，但當(dāng)連接數(shù)為10 000 時(shí)，響應(yīng)時(shí)間明顯上升，連接數(shù)在12 000 時(shí)響應(yīng)時(shí)間更是超過(guò)1 000 ms，遠(yuǎn)超出了實(shí)際應(yīng)用的要求。

通過(guò)監(jiān)測(cè)收集端服務(wù)進(jìn)程，發(fā)現(xiàn)連接數(shù)為12 000時(shí)，在不使用Kafka 的情況下，盡管使用了數(shù)據(jù)庫(kù)連接池技術(shù)，仍有大量線程阻塞，如圖6所示，每個(gè)線程阻塞時(shí)間占總運(yùn)行時(shí)間35%左右。在線程阻塞的同時(shí)，還有大量數(shù)據(jù)不斷涌入，又進(jìn)一步加劇了線程阻塞，進(jìn)而導(dǎo)致響應(yīng)時(shí)間急劇增加。

圖6 連接數(shù)為12 000不使用Kafka情況下線程阻塞情況

5 結(jié)語(yǔ)

本文基于Netty 和Kafka 實(shí)現(xiàn)了一個(gè)面向物聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)接入系統(tǒng)。簡(jiǎn)潔的通信協(xié)議與諸多性能優(yōu)化措施使得系統(tǒng)在百兆局域網(wǎng)環(huán)境的測(cè)試下，可穩(wěn)定保持萬(wàn)級(jí)別長(zhǎng)連接和毫秒級(jí)別的響應(yīng)速度，在物聯(lián)網(wǎng)數(shù)據(jù)接入服務(wù)與應(yīng)用領(lǐng)域有一定的現(xiàn)實(shí)意義。但目前的工作僅是使用一個(gè)收集端服務(wù)，系統(tǒng)的整體性能會(huì)受限于此。下一步可搭建收集端服務(wù)集群，并利用負(fù)載均衡策略將采集終端的連接分散到集群的不同機(jī)器上去，以減少單臺(tái)機(jī)器硬件資源的限制對(duì)系統(tǒng)性能造成影響，從而滿足未來(lái)更大規(guī)模的應(yīng)用。