关于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 公布