ZETA技術通過數蛙科技百億級物流標籤軌跡時序數據壓測

壓測背景：

LPWAN是當前物聯網行業中最重要的技術之一，以年複合增長率90%的驚人速度增長。NB-IOT、LoRa、ZETA以及Sigfox是當前市場上主流的幾種LPWAN通信技術。

ZETA LPWAN協議以超窄帶、低功耗雙向通信和多跳組網的特點，徹底改善了傳統的LPWAN協議不足之處，大大增加了LPWAN技術在物聯網應用的空間。

ZETag雲標籤是縱行科技基於ZETA技術開發的傳感柔性標籤，具有公裡級超廣覆蓋，低功耗特性等優勢，與同類技術相比，成本可降低至1/3-1/10，並能支持大容量並發，使用壽命最長可達5年。與此同時，ZETag雲標籤通過減小尺寸和功耗並改善性能來消除常規有源標籤的閒置，除卻物流倉儲和貨物追蹤，還可作為一次性標籤廣泛應用在資產定位和危化、危廢管理的萬億級市場。

目前，ZETag雲標籤已在京東物流、中國郵政、日郵物流、上海睿池、上海派鏈等上下遊物流企業物流載具及貴重包裹上實現應用，也是全球首例在速遞郵件上實現實時軌跡跟蹤的服務的物聯網雲標籤。

數蛙科技是工業物聯網千萬級設備接入與管理的專業平臺提供商，目前業務場景已覆蓋電力、交通、物流、工業製造等多領域的商業應用。

濤思時序資料庫TDengine是目前針對時序資料庫的性能最優的開源資料庫平臺，廣泛運用於工業、電力、車聯網、大數據領域。

數蛙科技結合縱行科技的ZETag雲標籤與濤思數據的高容量時序資料庫，為物流領域未來高增長、高並發的物流標籤場景，進行了1000萬接入、百億級時序數據的運營級全業務模擬壓力測試。

ZETag物流標籤組網如下：

壓測目的：

本次壓力測試通過模擬1萬ZETAAP、千萬ZETATAG標籤的在線運行，精準高效完成ZETA AP、ZETA TAG的在線協議解析、解析數據實時入庫、海量數據在線查詢與展示等流程。同時，對真實物流業務場景進行抽象，實現批次ZETA TAG在不同線路上發生軌跡改變，移動過程中利用不同的ZETA AP實現定位。ZETA TAG在線運行過程中，每隔15分鐘發送心跳包，被臨近的單個或者多個ZETA AP報送至服務端。服務端會按照策略選擇信號最好的上報數進行存庫，並利用上報信號最好的AP對ZETA TAG進行定位。

通過壓力測試，判斷當前應用環境情況下系統的負載能力，為今後應用範圍擴大，用戶量上升後，伺服器擴容、升級等提供必要的技術支撐，及伺服器規劃等。

本次測試目的是為了驗證基於數蛙連接與設備管理平臺的ZETA物流跟蹤管理能夠實現千萬級ZETATAG標籤同時在線穩定運行、數據及時回傳、正常入庫、高效查庫。

本次測試場景的壓力與複雜度遠高於真實場景，在保障ZETA物流跟蹤當前業務可以正常開展的同時，也可以有效支撐ZETA相關業務應用的拓展與深化應用。

壓測環境：

由於壓力測試是對系統負載能力的測試，無法通過真實的環境來進行獲取相關指標，因此通過測試機與測試服務，模擬1萬AP、千萬ZETA TAG與伺服器高頻數據交互，利用算法虛擬真實業務場景下實際的操作來進行測試。

測試機部署虛擬雲設備服務，及進行壓力測試的客戶端機器，一般採用高配置的機器來進行測試。在壓力測試過程中，一般忽略測試機對壓力測試結果的影響。

壓測場景：

ZETA設備運行模擬：

ZETA AP：每10s主動連接服務端，連續30min未連上等待2min再次連接;連接狀態下1min一次心跳交互;連續三次未收到ACK，發起重連。

ZETA TAG：每15分鐘上報一次心跳包;心跳報文被不同AP接收上報後，服務端會比較後保留首次 收到TAG心跳後3s內RSSI最強上報的AP位置信息作為TAG的當前位置。

客戶端場景模擬描述：

運輸、配送線路：本次場景模擬線路總計200條，線路可以配置。

運輸車輛：本次場景模擬運輸車輛50000部，貨車會模擬真實物流場景在既定線路上進行移動，車上ZETAG標籤隨之移動。

ZETA AP：本次模擬10000臺，每條線路上分布500臺ZETA AP

ZETA TAG數量：本次模擬在運ZETAG1000萬個，ZETAG隨運輸車輛移動，每隔15分鐘的心跳報文被相鄰的2-3個ZETA AP接收。

服務端業務描述：

每15分鐘內完成千萬在運ZETAG標籤心跳數據包解析(加上冗餘報文，每15分鐘內解析心跳報文數量2000多萬條);

完成ZETA TAG心跳數據比較與冗餘數據過濾;

完成解析出的海量TAG位置信息實時分類入庫;

4、支持ZETA TAG最新位置更新與軌跡查詢;

5、每分鐘完成1萬ZETA AP的心跳報文解析、存儲;

6、完成ZETA AP運行狀態信息的接收與存儲;

7、支持ZETA AP運行狀態信息查詢。

根據測試系統中消息的業務場景情況，選取以下指標作為場景壓力測試情況判斷依據：

A、ZETA AP在線情況統計

B、ZETA AP在線率

C、在線ZETAG標籤數量

D、ZETA標籤解析包數量

E、1/5/15分鐘CPU平均負載

F、內存使用量

壓測技術：

系統監控

服務端與客戶端系統監控和業務數據監控採用Prometheus&Grafana做統計與展示

時序數據監控--- Grafana&TDengine監控插件(監控TDengine數據總量、丟包數以及增長速率)

系統指標監控--- Grafana&&Prometheus監控插件，用node_exporter採集數據(監控CPU，內存，網絡、存儲四大指標)

業務消息監控 --- Grafana&Prometheus監控插件，業務層通過Prometheus client實時統計各個消息路由節點上發包數、收包數以及丟包數等指標，業務層主要指標如下：

時序數據

ZETag物流標籤的地址域是4個字節，最高的一個字節是保留字節，本次壓測的ZETag物流標籤的實際地址域是3個字節，所以ZETag地址為FF XX XX XX，總計16,777,215個標籤的地址，如果按照一個標籤設備一個子表的方式設計，需要1600多萬個子表。根據實測結果，Tdengine 1.6.3單機版本子表數量超過49萬就極不穩定，很容易崩潰，但子表數量在10萬以下具有良好的性能。所以子表設計採用了一種虛擬分組設計，將最低兩個字節(總計65,535個子表)作為子表空間，每個子表存儲一個字節(總計255個標籤)的標籤時序數據。

時序數據模型設計：

240億數據存儲空間佔用230G磁碟空間

數據存儲目錄

時序數據入庫示例：

時序數據入庫策略：

本次模擬了1300多萬的物流標籤15分鐘一個心跳，平均1.4萬多的QPS，峰值QPS很容易超過Tdengine的入庫QPS閥值，導致Tdengine崩潰。在消息路由層設計了一個基於令牌桶算法的消息緩存層進行削峰處理，在保證時序數據的順序性的同時，也能讓時序數據以比較平穩的速率批量入庫。由於Tdengine沒有提供erlang的連接池程序，最開始用默認的http客戶端來入庫，長時間運行不穩定，最後我們把Tdengine原生的c語言的連接池程序進行了改造，添加了mqtt訂閱功能，通過mqtt協議來轉發批量存庫時序數據。

時序數據出庫策略：

由於對子表進行虛擬分組設計，查找任何一個物流標籤數據的物流軌跡數據都有非常便捷的尋址算法，快速查找到用戶層期望的時序數據，在百億級數據規模的情況下，查詢速度也可以到毫秒級。

ZetaEtag即時數據查詢接口：/zeta/etag/{tag}

超時時間為5秒

隨機讀tag，資料庫內數據58169933條

tag 生成方式：FF開頭後六位隨機生成

* 返回status code為200(找到目標tag)或404(找不到目標tag)兩者都視為調用成功

ZetaEtag歷史數據接口：zeta/etag/history/{tag}

超時時間為5秒

對所有tag隨機讀，limit值為100，日期範圍在合理範圍內隨機產生，資料庫內數據58169933條

tag生成方式：FF開頭後六位隨機生成

日期生成方式：1569558137——1569579737間隨機數

2019年10月份做壓測報告時，沒有記錄240億時的API統計，把去年的壓測鏡像恢復回來，240億標籤數據時的查詢速度如下

消息路由

ZETag物流標籤數據從數據產生到數據落庫，1300多萬ZETag標籤 =》5萬卡車進程=》1萬AP基站客戶端連接進程=》1萬AP的服務端連接進程=》65535虛擬分組進程=》消息緩存調度進程 =》Tdengine的mqtt客戶端=》Tdengine連接池存儲進程，消息需要經過7次轉發，每一跳都需要小心處理內存釋放和消息堵塞問題。每15分鐘有將近3000萬-4500萬消息的生產和消費，需要有非常好的GC處理機制。其中1萬AP的服務端連接進程--》65535虛擬分組進程，這一跳消息轉發速率沒有固定的對應關係，兩點之間QPS波動非常大，用開源的mqtt消息轉發和消費組策略也非常容易導致消息堵塞和內存持續上漲。這裡也還是得益於之前的虛擬分組設計，通過虛擬分組比較好的解決了這一跳的高效消息路由，同時也把這兩點之間的消息轉發的QPS峰值削的比較平。

影子設備

本次測試模擬的是類似雙11這樣的物流標籤軌跡最繁忙的場景，模擬了5萬臺卡車裝滿(200多件貼上ZETag標籤的快遞件)快遞件，在200多條線路上飛奔，在行駛過程中不停切換AP基站，上報ZETag標籤軌跡數據，滿懷期望的用戶時不時登錄快遞網站查看一下自己購買的貨物到了何處。我們在系統中設計了5萬個卡車影子設備，1萬的AP基站影子設備和65535虛擬分組影子設備來處理這一較為複雜的業務場景。卡車影子設備承載了ZETA標籤信息，線路位置信息和線路沿途的AP基站信息的交互，AP基站影子設備承載了ZEtag通信協議處理，虛擬分組影子設備承擔了1300萬ZETag標籤的邊緣計算和時序數據存儲處理。

任務調度

每15分鐘有將近3000萬-4500萬ZETag標籤消息的生產和消費除了需要良好的GC機制，同時也需要一個良好的任務調度機制。治大國如烹小鮮，每一個影子設備上面的任務調度處理細節非常關鍵，每一個小的偏差都會被乘以一個3000-45000萬的係數放大，對任務調度質量要求是零缺陷。合理的分組策略(也即合理的影子設備設計)非常關鍵，可以從宏觀上對系統資源進行削峰，在單個影子設備上進行完美的微操作，讓每一個影子設備的任務調度策略達到零缺陷。

壓測結果：

免責聲明：市場有風險，選擇需謹慎!此文僅供參考，不作買賣依據。

責任編輯：