??想了解更多內(nèi)容，請?jiān)L問：??

??51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)??

??https://ost.51cto.com??

大家好! 我是深圳技術(shù)大學(xué)FSR實(shí)驗(yàn)室的同學(xué)，在OpenHarmony成長計(jì)劃啃論文俱樂部，學(xué)習(xí)研究JSON相關(guān)的技術(shù)，并且我是第二組的成員。

場景匯總

Flatbuffers：Flatbuffers作為MQTT協(xié)議數(shù)據(jù)傳輸格式的性能分析。

JSON作為MQTT協(xié)議數(shù)據(jù)交換格式有很多缺點(diǎn)，比如處理的時(shí)間長等，而Google最近引入了一種名為Flatbuffers的新數(shù)據(jù)格式,與其他數(shù)據(jù)格式相比，F(xiàn)latbuffers具有更好的數(shù)據(jù)格傳輸性能。

本文將引用文獻(xiàn)討論通過 MQTT 發(fā)布/訂閱通信模型測試 Flatbuffers 與其他數(shù)據(jù)格式之間的性能差異。

技術(shù)發(fā)展時(shí)間及應(yīng)用

https://github.com/google/flatbuffers。

我們今天要講的開源技術(shù)Flatbuffers，是在2014年，Google 員工 Wouter van Oortmerssen 為了解決游戲中性能的問題，于是開發(fā)出了這個(gè)序列化類庫。

Flatbuffers概述

FlatBuffers 是一個(gè)開源的、跨平臺(tái)的、高效的、提供了多種語言接口的序列化類庫。目前該類庫提供C++, C#, C, Go, Java, JavaScript, PHP, and Python語言接口。

特點(diǎn)：

• 無需解碼, FlatBuffers的不同之處在于，它在一個(gè)平面二進(jìn)制緩沖區(qū)中表示分層數(shù)據(jù)，這樣就可以直接訪問它，而不需要解碼。
• 擴(kuò)展性、靈活性較高，類庫中支持的可選字段可以具有很好的前向/后向兼容能力。
• 跨平臺(tái)，支持C++11、Java，而不需要任何依賴庫;在最新的gcc、clang、vs2010等編譯器上工作良好。

MQTT協(xié)議

MQTT協(xié)議是一個(gè)基于客戶端-服務(wù)器的消息發(fā)布/訂閱傳輸協(xié)議，工作在TCP/IP協(xié)議上。

它是一個(gè)輕量，簡單，開放且易于實(shí)現(xiàn)的一個(gè)協(xié)議，通常應(yīng)用于機(jī)器與機(jī)器(M2M)之間通信和物聯(lián)網(wǎng)(IoT)設(shè)備。

并且不需要很多帶寬，而且開源，所以很多庫都支持使用這種協(xié)議，MQTT比HTTP 1.1協(xié)議輕，當(dāng)用于實(shí)時(shí)發(fā)送數(shù)據(jù)時(shí)是個(gè)不錯(cuò)的選擇。

在發(fā)布/訂閱者通信中,MQTT模型充當(dāng)代理，如圖。

MQTT具有以下特點(diǎn)：

• 簡易高效，MQTT一般用于處理資源較少的設(shè)備通信。
• 不需要管理員，它可以自動(dòng)響應(yīng)一些數(shù)據(jù)，或者本身不需要的數(shù)據(jù)。
• 最大限度地減少了數(shù)據(jù)地發(fā)送，保持較小的帶寬頻率。
• 比較靈活，可以處理所有類型數(shù)據(jù)。

場景介紹

• 在一個(gè)具有許多傳感器數(shù)據(jù)的物聯(lián)網(wǎng)設(shè)備中，使用MQTT協(xié)議發(fā)送傳感器數(shù)據(jù)到其他終端。

在使用MQTT發(fā)送數(shù)據(jù)之前，需要先進(jìn)行預(yù)處理和數(shù)據(jù)轉(zhuǎn)換，即將JSON數(shù)據(jù)的IoT傳感器數(shù)據(jù)轉(zhuǎn)換為其他幾種數(shù)據(jù)格式，通過Flatbuffer類庫處理過后存入緩沖區(qū)，然后將緩沖區(qū)保存到包含BIN數(shù)據(jù)的文件中，除了具有BIN格式的數(shù)據(jù)外，還有其他數(shù)據(jù)格式，例如Json，CSV和XML。

處理過后的文件大小如下：

性能比較

有效負(fù)載(Payload)

CSV 數(shù)據(jù)格式擁有最小有效負(fù)載，其值為 0.9955 個(gè)字符/字節(jié)。而XML有效負(fù)載值最大，值為 0.9985。有效負(fù)載越大，文件大小就越大，所以有效負(fù)載值會(huì)影響文件的大小。

計(jì)算公式：

等待時(shí)間(Latency)

首先是發(fā)送數(shù)據(jù)的等待時(shí)間(Delivery Latency),可以看到Json是發(fā)送時(shí)間最快的，接著是XML，而 CSV 和Flatbuffer需要比其他數(shù)據(jù)格式花費(fèi)更長的時(shí)間。也表明了Flatbuffer序列化過程對傳遞時(shí)的性能相對其他格式較差。如上圖：

然后是接收數(shù)據(jù)的等待時(shí)間(Processing Latency)。通過上圖可以看到，在接收數(shù)據(jù)的時(shí)候出現(xiàn)了相反的結(jié)果，F(xiàn)latbuffer 顯示出了最佳性能。其原因也是Flatbuffer 的一個(gè)很重要的特點(diǎn)，就是訂閱者接收信息時(shí)不需要反序列化(即不需要解碼)。

吞吐量(Throughput)

發(fā)送數(shù)據(jù)的吞吐量(Delivery Throughput)比較如下圖：

接收數(shù)據(jù)的吞吐量(Processing Throughput)比較如下圖：

可以看到XML不過是發(fā)送還是接收數(shù)據(jù)都具備很高的吞吐量，原因就是他的文件大小較小且低延遲。而Flatbuffer處于中規(guī)中矩的位置。

總結(jié)

通過以上各項(xiàng)測量指標(biāo)對比我們可以發(fā)現(xiàn)，F(xiàn)latbuffers 的有效負(fù)載值(Payload)非常小，因此效率很高。測量等待時(shí)間(Latency)時(shí)，接收數(shù)據(jù)的時(shí)候所需要的等待解析時(shí)間是非常短的，但是在發(fā)送數(shù)據(jù)序列化的等待時(shí)間較長。測量吞吐量(Throughput)`時(shí)其表現(xiàn)也是中規(guī)中矩。

從結(jié)論上來看，F(xiàn)latbuffers 序列化類庫在MQTT協(xié)議中用在數(shù)據(jù)存儲(chǔ)上會(huì)非常優(yōu)秀，但是用在數(shù)據(jù)發(fā)送上，相比于其他數(shù)據(jù)格式性能還是不太優(yōu)秀。

參考文獻(xiàn)

①.Flatbuffers Implementation on MQTT Publish/Subscribe Communication as Data Delivery Format。

②.A Survey of JSON-compatible Binary Serialization Specifications。

??想了解更多內(nèi)容，請?jiān)L問：??

??51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)??

??https://ost.51cto.com??