OpenHarmony啃論文成長計劃---Flatbuffers應用于MQTT協(xié)議
大家好! 我是深圳技術大學FSR實驗室的同學，在OpenHarmony成長計劃啃論文俱樂部，學習研究JSON相關的技術，并且我是第二組的成員。
場景匯總
Flatbuffers：Flatbuffers作為MQTT協(xié)議數(shù)據(jù)傳輸格式的性能分析。
JSON作為MQTT協(xié)議數(shù)據(jù)交換格式有很多缺點，比如處理的時間長等，而Google最近引入了一種名為Flatbuffers的新數(shù)據(jù)格式,與其他數(shù)據(jù)格式相比，F(xiàn)latbuffers具有更好的數(shù)據(jù)格傳輸性能。
本文將引用文獻討論通過 MQTT 發(fā)布/訂閱通信模型測試 Flatbuffers 與其他數(shù)據(jù)格式之間的性能差異。
技術發(fā)展時間及應用
https://github.com/google/flatbuffers。
我們今天要講的開源技術Flatbuffers，是在2014年，Google 員工 Wouter van Oortmerssen 為了解決游戲中性能的問題，于是開發(fā)出了這個序列化類庫。
Flatbuffers概述
FlatBuffers 是一個開源的、跨平臺的、高效的、提供了多種語言接口的序列化類庫。目前該類庫提供C++, C#, C, Go, Java, JavaScript, PHP, and Python語言接口。
特點：
- 無需解碼, FlatBuffers的不同之處在于，它在一個平面二進制緩沖區(qū)中表示分層數(shù)據(jù)，這樣就可以直接訪問它，而不需要解碼。
- 擴展性、靈活性較高，類庫中支持的可選字段可以具有很好的前向/后向兼容能力。
- 跨平臺，支持C++11、Java，而不需要任何依賴庫;在最新的gcc、clang、vs2010等編譯器上工作良好。
MQTT協(xié)議
MQTT協(xié)議是一個基于客戶端-服務器的消息發(fā)布/訂閱傳輸協(xié)議，工作在TCP/IP協(xié)議上。
它是一個輕量，簡單，開放且易于實現(xiàn)的一個協(xié)議，通常應用于機器與機器(M2M)之間通信和物聯(lián)網(wǎng)(IoT)設備。
并且不需要很多帶寬，而且開源，所以很多庫都支持使用這種協(xié)議，MQTT比HTTP 1.1協(xié)議輕，當用于實時發(fā)送數(shù)據(jù)時是個不錯的選擇。
在發(fā)布/訂閱者通信中,MQTT模型充當代理，如圖。
MQTT具有以下特點：
- 簡易高效，MQTT一般用于處理資源較少的設備通信。
- 不需要管理員，它可以自動響應一些數(shù)據(jù)，或者本身不需要的數(shù)據(jù)。
- 最大限度地減少了數(shù)據(jù)地發(fā)送，保持較小的帶寬頻率。
- 比較靈活，可以處理所有類型數(shù)據(jù)。
場景介紹
- 在一個具有許多傳感器數(shù)據(jù)的物聯(lián)網(wǎng)設備中，使用MQTT協(xié)議發(fā)送傳感器數(shù)據(jù)到其他終端。
在使用MQTT發(fā)送數(shù)據(jù)之前，需要先進行預處理和數(shù)據(jù)轉換，即將JSON數(shù)據(jù)的IoT傳感器數(shù)據(jù)轉換為其他幾種數(shù)據(jù)格式，通過Flatbuffer類庫處理過后存入緩沖區(qū)，然后將緩沖區(qū)保存到包含BIN數(shù)據(jù)的文件中，除了具有BIN格式的數(shù)據(jù)外，還有其他數(shù)據(jù)格式，例如Json，CSV和XML。
處理過后的文件大小如下：
性能比較
有效負載(Payload)
CSV 數(shù)據(jù)格式擁有最小有效負載，其值為 0.9955 個字符/字節(jié)。而XML有效負載值最大，值為 0.9985。有效負載越大，文件大小就越大，所以有效負載值會影響文件的大小。
計算公式：
等待時間(Latency)
首先是發(fā)送數(shù)據(jù)的等待時間(Delivery Latency),可以看到Json是發(fā)送時間最快的，接著是XML，而 CSV 和Flatbuffer需要比其他數(shù)據(jù)格式花費更長的時間。也表明了Flatbuffer序列化過程對傳遞時的性能相對其他格式較差。如上圖：
然后是接收數(shù)據(jù)的等待時間(Processing Latency)。通過上圖可以看到，在接收數(shù)據(jù)的時候出現(xiàn)了相反的結果，F(xiàn)latbuffer 顯示出了最佳性能。其原因也是Flatbuffer 的一個很重要的特點，就是訂閱者接收信息時不需要反序列化(即不需要解碼)。
吞吐量(Throughput)
發(fā)送數(shù)據(jù)的吞吐量(Delivery Throughput)比較如下圖：
接收數(shù)據(jù)的吞吐量(Processing Throughput)比較如下圖：
可以看到XML不過是發(fā)送還是接收數(shù)據(jù)都具備很高的吞吐量，原因就是他的文件大小較小且低延遲。而Flatbuffer處于中規(guī)中矩的位置。
總結
通過以上各項測量指標對比我們可以發(fā)現(xiàn)，F(xiàn)latbuffers 的有效負載值(Payload)非常小，因此效率很高。測量等待時間(Latency)時，接收數(shù)據(jù)的時候所需要的等待解析時間是非常短的，但是在發(fā)送數(shù)據(jù)序列化的等待時間較長。測量吞吐量(Throughput)`時其表現(xiàn)也是中規(guī)中矩。
從結論上來看，F(xiàn)latbuffers 序列化類庫在MQTT協(xié)議中用在數(shù)據(jù)存儲上會非常優(yōu)秀，但是用在數(shù)據(jù)發(fā)送上，相比于其他數(shù)據(jù)格式性能還是不太優(yōu)秀。
參考文獻
①.Flatbuffers Implementation on MQTT Publish/Subscribe Communication as Data Delivery Format。
②.A Survey of JSON-compatible Binary Serialization Specifications。
