• 压测布景**：**

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() -> #{ <<"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()
}
).

** 时序数据入库战略**：

时序数据出库战略：

因为对子表进行虚拟分组规划，查找任何一个物流标签数据的物流轨道数据都有十分快捷的寻址算法，快速查找到用户层希望的时序数据，在百亿级数据规划的状况下，查询速度也能够到毫秒级。

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亿标签数据时的查询速度如下

• 音讯路由

• 影子设备

本次测验模仿的是相似双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/

欢迎我们底部留言，一同讨论物联网科技的魅力地点。