面向物聯(lián)網設備的通用云平臺接入服務研究及實現

摘要：為了解決隨物聯(lián)網快速發(fā)展而來的海量設備接入難題，在集群模式的架構下，如何最大化的提高單臺服務器的接入能力，成為研究的重要方向之一。本文分析了目前主流編程語言的執(zhí)行效率、IO復用模型、線程池模型、內存數據庫存取模型等相關技術，提出了一種適合物聯(lián)網設備接入的通用服務結構設計，并以實際應用案例進行驗證，達到了預期的效果。

關鍵詞：物聯(lián)網;云平臺;設備接入;高并發(fā)

中圖分類號：TP311.1? ? 文獻標識碼：A? ? 文章編號：1007-9416（2020）04-0000-00

0 引言

隨著物聯(lián)網技術及市場的發(fā)展，海量異構設備需要接入云平臺進行統(tǒng)一管理。目前云平臺架構中的分布式處理、集群化等技術對于設備的并發(fā)連接和數量規(guī)模有了大幅提升，但仍然存在接入服務處理效率低、延時較大等問題。而物聯(lián)網提出的物物相互聯(lián)接，相互通信感知，甚至相互操作的特點，不僅大大增加了通信量，還大幅提高了對于通信低延時的需求。基于這個現狀，需要有針對性地討論并設計基于物物聯(lián)接的通用性云平臺接入服務。

本文從單臺服務器系統(tǒng)入手，重點分析了不同語言技術的執(zhí)行效率，Linux系統(tǒng)IO復用、線程池技術和內存數據庫存取等模型，闡述如何較大幅度提升物聯(lián)網設備TCP連接管理及數據處理效率，并通過實際數據進行測試驗證。

1 語言選擇

JAVA語言擁有跨平臺性、安全性高、網絡移動性等眾多的優(yōu)點。C語言具有代碼簡潔，執(zhí)行速度快，功能豐富、表達力強等優(yōu)點。在選用語言的時候，應該將項目的需求與語言的特點結合起來，充分發(fā)揮語言的優(yōu)點[1]。對于服務于物聯(lián)網設備的通用云平臺接入應用，執(zhí)行效率是最優(yōu)先評判的指標，在這一方面C語言優(yōu)勢明顯。

從資源及框架選擇方面，雖然C的資源庫沒有JAVA的資源庫豐富，但是在針對本文項目所用到的I/O多路復用等相關技術方面，也有比較成熟穩(wěn)定的工具庫，例如LibEvent等。并且C語言在操作指針方面的天然特性，可大大提升程序開發(fā)中的靈活性。

實際項目應用方面，使用C為基礎語言編寫的Linux內核、Redis內存數據庫等眾多著名項目，穩(wěn)定可靠，性能極致，被廣泛使用。故本文選取C語言作為物聯(lián)網云平臺接入服務的基礎開發(fā)語言。

2 I/O多路復用

在Linux系統(tǒng)中，使用VFS機制，將所有磁盤文件和各類I/O設備統(tǒng)一抽象為文件，并通過文件描述符進行操作。多路復用就是同時監(jiān)視多個I/O文件描述符，根據文件描述符的設定狀態(tài)進入執(zhí)行或休眠。

Linux內核中實現I/O多路復用主要有三種機制模型：select、poll和epoll。select機制主要邏輯是：當有相應的數據可以操作時，則進行讀寫操作;若沒有，則強制sleep。雖然select實現了I/O多路復用，但其效率相對較低，每次都需要遍歷整個文件描述表，直到找到目標。并且每次返回都會修改fd_set，需要額外的存儲和拷貝，才能重復利用。

poll機制改良了select的一些缺點，可以不需要備份fd_set，但依然需要遍歷整個文件描述符表，查詢效率沒有提升。

epoll機制改進了遍歷整個文件描述符表的缺點，不僅效率大幅提升，而且還實現了更為健壯的接口，并新加觸發(fā)功能，提升了使用方面的靈活性。

I/O多路復用最大的特點就是大幅減少了多線程并發(fā)的系統(tǒng)開銷，但是由于其并沒有實現真正的多任務，所以當并發(fā)壓力大時，響應會變慢。所以選擇線程池技術模型有望實現多任務的I/O多路復用，最大化地提升整個系統(tǒng)對于I/O的并發(fā)處理能力。

使用I/O多路復用技術的主要設計思路是盡可能保證系統(tǒng)對于I/O處理的開銷不隨TCP連接數或設備數量的增加而過快增長。

3 線程池

為了避免多線程服務收到請求后創(chuàng)建新線程的系統(tǒng)開銷，在應用程序啟動后，馬上創(chuàng)建一定數量的線程，當有任務需要處理時，預先分配或臨時分配目標線程，待任務處理完成后，線程并不退出，繼續(xù)等待后續(xù)任務。使用負載均衡算法和內部線程間通信，動態(tài)地調整線程的負載，實現靜態(tài)代碼功能與動態(tài)實例的有效分離。

使用線程池的主要設計思路是盡可能保證線程的數量不隨TCP連接數或設備數量的增加而過快增長，將系統(tǒng)的線程開銷限制在可控范圍內。

4 內存數據庫存取模型

數據庫操作是云平臺系統(tǒng)不可或缺的一環(huán)，特別是內存數據庫在提升系統(tǒng)處理能力方面發(fā)揮著重大的作用。大量研究集中于此，例如Tingli Li等提出基于NoSQL的物聯(lián)網數據處理框架IOTMDB[2];Suna Yin等提出基于NoSQL的分布式物聯(lián)網數據處理框架STNoSQL[3];田野等提出基于NoSQL、REST的物聯(lián)網數據存儲與共享策略[4]。研究數據庫存取模型的主要思路是從系統(tǒng)角度，找到效率較低的處理環(huán)節(jié)，并提出優(yōu)化方案。

在內存數據庫中，Redis、Mongo使用量較大，特別是Redis數據庫在key-value存取模型中速度遠遠勝出，適用于數據變化快且數據庫大小可預見的應用程序中。

根據上述特點，本文使用Redis數據庫保存熱數據，例如socket fd與網關mac的對應關系等。由于云平臺接入服務需要同時處理盡可能多的設備連接或設備數據幀，而且處理的數量會隨設備連接數量的增加而不可避免地增加，所以對于這部分邏輯的每一點優(yōu)化進步，都會對最終的處理效率產生較大影響。

本文深入研究Redis數據庫部分實現邏輯，發(fā)現其對數據的增刪改查操作主要通過對數據key字符串進行hash操作，生成的結果作為數組下標對表進行尋址。遇到沖突的表項則將兩數據鏈接，作為鏈表進行保存。當沖突項大于一定數量后，擴容表空間，進行重hash操作。同時當統(tǒng)計占用量小于一定百分比時，縮減表空間，并進行重hash操作，以減少對資源的占用。

5 設備接入服務模型

本文在綜合上述要點分析后，提出一種基于I/O多路復用和線程池技術的設備接入服務模型。網絡處理部分主要業(yè)務邏輯如圖1所示。首先在初始化時，由主線程一次性創(chuàng)建多個子線程。每個子線程中使用管道建立一對讀寫接口，并對這對接口進行讀事件監(jiān)控。同時在子線程中建立客戶端連接描述符管理隊列，用于管理已經建立TCP連接的設備。

主線程負責監(jiān)聽TCP端口，當有連接請求時，獲取相應的客戶端連接描述符，通過負載均衡算法，將其發(fā)送至選擇的工作線程。負載均衡算法主要解決多個工作線程的負載均衡問題，簡單實現可按照每個線程的實際client fd個數，保證每個線程都有相同數量的連接數。但由于每個網關設備下面連接的子設備數量不同，所以改進算法可在每個工作線程統(tǒng)計實際的連接設備數量，以平均分配每個工作線程所處理的設備數量。還可以各自統(tǒng)計工作線程的實際執(zhí)行時間，將新的連接分配給執(zhí)行時間最少的工作線程。目前本文實現的是以實際子設備數量進行平均。

當工作線程監(jiān)控到管道的讀事件后，將收到的客戶端連接描述符取出，構造連接結構體，并完成socket的后續(xù)連接動作后，將其加入連接隊列中，監(jiān)控其事件。連接結構體與實際的業(yè)務相關，本文的連接結構體定義如圖2所示。其中主要屬性有連接描述符sfd，用于記錄client的連接;互斥mutex信號量lock，用于對共用數據加鎖，以保證多線程操作結果的一致性;libevent的連接事件管理和數據緩沖區(qū)，用于監(jiān)控連接的讀事件和錯誤事件，并觸發(fā)相應的回調進行處理;本連接狀態(tài)機狀態(tài)指示state;雙向鏈表的前后指針，用于在某些輪詢邏輯中進行遍歷;所屬的線程描述結構體指針，用于標識與線程本身的關系等。其它屬性是具體業(yè)務需要暫時保存的屬性變量，例如realTimeCmdQueue也是個隊列，記錄了當前連接需要串行發(fā)送的命令列表;gatewayType記錄了當前連接的網關的設備類型等等。

經過上述處理后，實際上每個線程的實例與一定數量的設備客戶端TCP連接實例進行了綁定，每當設備需要有數據交互時，相應的工作線程可直接觸發(fā)進行處理，大大降低了創(chuàng)建、銷毀線程帶來的系統(tǒng)開銷，較大程度的提升了系統(tǒng)TCP連接處理能力。

6 緩存處理模型

經過對Redis數據庫模型的深入分析，發(fā)現其在數據增刪改查操作時的復雜度主要集中于Hash算法部分邏輯，其時間復雜度基本為常數。遠遠小于關系型數據庫的投影等算法的時間復雜度。本文在追求極致高效的設備TCP連接處理能力的驅動下，將Redis主要數據結構，例如集合、列表等的增刪改查操作主要邏輯移植到自主設計的設備接入模型中，并根據實際情況進行了修改調整，同時使用單獨線程進行調度處理。編寫了測試程序，與直接使用Redis數據庫服務本身的相同操作進行對比測試，力求尋找緩存操作本身與socket通信對于系統(tǒng)CPU時間占用的相對比較數據。

測試程序主要邏輯是先打印系統(tǒng)時間，精確到us。使用新設備接入模型的緩存操作接口進行普通key-value數據、集合、列表等相關操作39項。打印系統(tǒng)時間。再直接使用Redis數據庫操作接口hiredis進行相同的39項操作。打印系統(tǒng)時間。最后得到的時間如表1所示。

經過計算，使用設備接入模型的單項操作時間平均值約為22.36us，使用hiredis模型的單項操作時間平均值約為194.9us。經過多次測試基本維持上述數據。同時為了避免不同負載下可能對于hash沖突的解決時間產生影響，本文測試時，已經將Redis數據庫本身的數據內容全部清除，基本可保證兩個模型測試環(huán)境相同。

根據上述驗證結果，基本可斷定兩次socket通信本身所花費的CPU時間遠大于緩存數據操作的時間，約為緩存數據操作時間的8倍。緩存數據操作在設備接入處理服務中屬于規(guī)模較大的操作邏輯，所有的設備信息都需要通過這個模型進行實時的存取，此處的大幅優(yōu)化，對整個服務的處理能力的明顯提升做于重大貢獻。

7 結語

為了解決隨物聯(lián)網快速發(fā)展而來的海量設備接入問題，本文從群集化部署和單機接入性能提升兩個方面進行了研究改進，提出了基于I/O多路復用和線程池的接入服務模型。同時根據實際測試結果，將緩存操作原理移植入接入服務模型，可使得接入服務處理能力得到了很大提升。

通過在實際項目中的長期運行，及與相似云平臺系統(tǒng)對比，使用本文研究結果實施的物聯(lián)網云平臺系統(tǒng)在接入處理方面能力明顯占優(yōu)勢。下一步將繼續(xù)研究優(yōu)化，尋找CPU占用環(huán)節(jié)，為得到更極致的接入處理能力而努力。

參考文獻

[1]盧曉苗，李從龍，張建明.一例Java語言與C語言代碼運行效率的比較[J].現代計算機，2010，01：116-118.

[2] Tingli Li，Yang Liu，Ye Tian，Shuo Shen，Wei Mao.A Storage Solution for Massive IoT Data Based on NoSQL[M].Proceedings of the IEEE International Conference on Internet of Things， 2012：50-57.

[3] Suna Yin，Dehua Chen，Jiajin Le.STNoSQL：Creating NoSQL database on the Sensible Things platform[C].IEEE Ieee/acis International Conference on Software Engineering，Artificial Intelligence，Networking and Parallel/Distributed Computing，2016：669-674.

[4]田野，袁博，李廷力.物聯(lián)網海量異構數據存儲與共享策略研究[J].電子學報，2016，44（2）：247-257.

收稿日期：2020-02-12

作者簡介：閆佼（1985—），男，河北邢臺人，研究生，工程師，研究方向：物聯(lián)網系統(tǒng)設計及應用。

Research and Implementation of General Accessing Cloud Services for IOT Devices

YAN Jiao

（Shanghai Shuncom Smart Technology Co.， Ltd，Shanghai? 201203）

Abstract： For solving the problem of huge intelligent equipment connecting with the rapid development of the IOT. Based on the cluster architecture， elevating single server ability of device accessing is an important manner. This paper studies the execution efficiency of the mainly used programming languages， I/O multiplexing model， thread pool model， main memory database （MMDB） accessing model and presents a general service for IOT device accessing. The expected service effect is proved when checking with the real application cases.

Key words： internet of things;cloud platform;device accessing;giant concurrent