关于java:数蛙科技百亿级物流标签轨迹时序数据压测

• 压测背景：

LPWAN是以后物联网行业中最重要的技术之一，以年复合增长率90%的惊人速度增长。NB-IOT、LoRa、ZETA以及Sigfox是以后市场上支流的几种LPWAN通信技术。

ZETA LPWAN协定以超窄带、低功耗双向通信和多跳组网的特点，彻底改善了传统的LPWAN协定不足之处，大大增加了LPWAN技术在物联网利用的空间。

ZETag云标签是纵行科技基于ZETA技术开发的传感柔性标签，具备公里级超广覆盖，低功耗个性等劣势，与同类技术相比，老本可升高至1/3-1/10，并能反对大容量并发，使用寿命最长可达5年。与此同时，ZETag云标签通过减小尺寸和功耗并改善性能来打消惯例有源标签的闲置，除却物流仓储和货物追踪，还可作为一次性标签广泛应用在资产定位和危化、危废治理的万亿级市场。

目前，ZETag云标签已在京东物流、中国邮政、日邮物流、上海睿池、上海派链等上下游物流企业物流载具及贵重包裹上实现利用，也是寰球首例在速递邮件上实现实时轨迹跟踪的服务的物联网云标签。

数蛙科技是工业物联网千万级设施接入与治理的业余平台提供商，目前业务场景已笼罩电力、交通、物流、工业制作等多畛域的商业利用。

涛思时序数据库TDengine是目前针对物联网时序数据库，性能最优的开源数据库平台，宽泛使用于工业、电力、车联网、大数据畛域。外围性能较其余数据库广泛快10倍以上，且领有弱小的全栈配套工具，如MQ、缓存、流式计算等成熟工具链。

纵行科技是国内物联网通信ZETA技术的发起者，合作伙伴超500家，业务笼罩20+国家。其中ZETag标签在物流畛域具备极强的竞争力，领有同类技术的1/10的低成本劣势，目前已在国内泛滥物流巨头客户落地，产生了微小的商业价值。

数蛙科技联合纵行科技的ZETag云标签与涛思数据的高容量时序数据库，为物流畛域将来高增长、高并发的物流标签场景，进行了1000万接入、百亿级时序数据的经营级全业务模仿压力测试。

ZETag物流标签组网如下：

• 压测目标：

本次压力测试通过模仿1万ZETA AP、千万ZETA TAG标签的在线运行，精准高效实现ZETA AP、ZETA TAG的在线协定解析、解析数据实时入库、海量数据在线查问与展现等流程。同时，对实在物流业务场景进行形象，实现批次ZETA TAG在不同线路上产生轨迹扭转，挪动过程中利用不同的ZETA AP实现定位。ZETA TAG在线运行过程中，每隔15分钟发送心跳包，被邻近的单个或者多个ZETA AP报送至服务端。服务端会依照策略抉择信号最好的上报数进行存库，并利用上报信号最好的AP对ZETA TAG进行定位。

通过压力测试，判断以后应用环境状况下零碎的负载能力，为今后利用范畴扩充，用户量回升后，服务器扩容、降级等提供必要的技术撑持，及服务器布局等。

本次测试目标是为了验证基于数蛙连贯与设施治理平台的ZETA物流跟踪治理可能实现千万级ZETA TAG标签同时在线稳固运行、数据及时回传、失常入库、高效查库。

本次测试场景的压力与复杂度远高于实在场景，在保障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接管。

服务端业务形容：

1、每15分钟内实现千万在运ZETAG标签心跳数据包解析（加上冗余报文，每15分钟内解析心跳报文数量2000多万条）；

2、实现ZETA TAG心跳数据比拟与冗余数据过滤；

3、实现解析出的海量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实时统计各个音讯路由节点上发包数、收包数以及丢包数等指标，业务层次要指标如下：

{ “name”: “ap”,
“help”: “ap数量”,
“type”: “counter”,
“labels”: [“from”]
},
{ “name”: “tag”,
“help”: “tag的包数量”,
“type”: “counter”,
“labels”: [“from”]
},
{ “name”: “zetag”,
“help”: “zetag info”,
“type”: “gauge”,
“labels”: [ “status” ]
}
]

[
{ “name”: “shuwa\_group\_metrics”,
“help”: “数蛙任务调度与音讯汇聚音讯统计”,
“type”: “counter”,
“labels”: [ “di”,”tid”,”rid”,”cid”,”type” ]
}
]

+ 时序数据

  ZETag物流标签的地址域是4个字节，最高的一个字节是保留字节，本次压测的ZETag物流标签的理论地址域是3个字节，所以ZETag地址为FF XX XX XX，总计16,777,215个标签的地址，如果依照一个标签设施一个子表的形式设计，须要1600多万个子表。依据实测后果，Tdengine 1.6.3单机版本子表数量超过49万就极不稳固，很容易解体，但子表数量在10万以下具备良好的性能。所以子表设计采纳了一种虚构分组设计，将最低两个字节（总计65,535个子表）作为子表空间，每个子表存储一个字节（总计255个标签）的标签时序数据。

时序数据模型设计：

zetag() ->
#{ <<“stable”\>> => #{ <<“\_\_database\_\_”\>> => <<“t”\>>,
<<“\_\_stable\_\_”\>> => <<“t”\>>,
<<“tags”\>> => #{ <<“zetag”\>> => shuwa\_tdengine\_bridge\_dialect:binary(2)
},
<<“value”\>> => #{ <<“ts”\>> => shuwa\_tdengine\_bridge\_dialect:timestamp(),
<<“zetagid”\>> => shuwa\_tdengine\_bridge\_dialect:binary(4),
<<“timetolive”\>> => shuwa\_tdengine\_bridge\_dialect:int(),
<<“lat”\>> => shuwa\_tdengine\_bridge\_dialect:float(),
<<“long”\>> => shuwa\_tdengine\_bridge\_dialect:float(),
<<“version”\>> => shuwa\_tdengine\_bridge\_dialect:tinyint(),
<<“status”\>> => shuwa\_tdengine\_bridge\_dialect:tinyint(),
<<“rssi”\>> => shuwa\_tdengine\_bridge\_dialect:float()
}
},
<<“table”\>> => #{ <<“type”\>> => <<“function”\>>,
<<“mod”\>> => <<“shuwa\_zeta\_model”\>>,
<<“function”\>> => <<“zeta\_tag\_subtable”\>>,
<<“args”\>> => #{ <<“\_\_database\_\_”\>> => <<“t”\>>,
<<“\_\_stable\_\_”\>> => <<“t”\>>,
<<“tags”\>> => [<<“FF”\>>]
}
}

}.

240亿数据存储空间占用230G磁盘空间

数据存储目录

时序数据入库示例：

-module(shuwa\_td\_test).
-author(“shuwa”).
-export([rand\_tag/0, t/0]).
rand\_tag() ->
integer\_to\_binary(4278190080 + round(rand:uniform() * 16777215), 16).
t() ->
shuwa\_tdengine\_format:insert\_zeta( #{ <<“zetagID”\>> => rand\_tag(),
<<“times”\>> => 1,
<<“lat”\>> => 2,
<<“long”\>> => 3,
<<“version”\>> => 4,
<<“status”\>> => 5,
<<“rssi”\>> => 6,
<<“ts”\>> => shuwa\_utils:now\_ms()
}
).

     时序数据入库策略：

本次模仿了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万的系数放大，对任务调度品质要求是零缺点。正当的分组策略（也即正当的影子设备设计）十分要害，能够从宏观上对系统资源进行削峰，在单个影子设施上进行完满的微操作，让每一个影子设施的任务调度策略达到零缺点。

+ 压测后果

参考网站：

数蛙科技：http://www.iotn2n.com/

纵行科技：https://www.zifisense.com/

涛思数据：https://www.taosdata.com/
> DG-IoT开源物联网 DG-IoT 公布