压测背景：LPWAN是当前物联网行业最重要的技术之一，以90%年复合增长率的惊人速度增长。NB-IOT、LoRa、ZETA和Sigfox是目前市场上主流的LPWAN通信技术。ZETALPWAN协议凭借超窄带、低功耗双向通信和多跳组网等特点，彻底改善了传统LPWAN协议的不足，大大增加了LPWAN技术在物联网中的应用空间。ZETag云标签是纵兴科技基于ZETA技术研发的一款传感器柔性标签。具有千米级超广覆盖、低功耗等优势。与同类技术相比，成本可以降低到1/3-1/10，并且可以支持大容量并发，使用寿命长达5年。同时，ZETag云标签通过减小尺寸和功耗以及提高性能消除了传统有源标签的闲置。除了物流仓储和货物跟踪，ZETag云标签还可以广泛应用于资产定位、危化品、危废等领域的一次性标签。管理万亿级市场。目前，ZETag云标签已经应用于京东物流、中国邮政、日本邮政物流、上海睿驰、上海派链等上下游物流企业的物流车辆和贵重包裹，用于跟踪服务的物联网云标签。树娃科技是工业物联网千万级设备接入和管理的专业平台提供商。目前的业务场景已经覆盖了电力、交通、物流、工业制造等多个领域的商业应用。淘思时序数据库TDengine是目前物联网时序数据库性能最好的开源数据库平台。广泛应用于工业、电力、车联网、大数据等领域。核心性能普遍比其他数据库快10倍以上，拥有强大的全栈配套工具，如MQ、缓存、流计算等成熟工具链。纵兴科技是国内物联网通信ZETA技术的发起者，合作伙伴超过500家，业务覆盖20+国家。其中，ZETag标签在物流领域极具竞争力，具有同类技术1/10的低成本优势。目前已被国内多家物流巨头落??地，产生了巨大的商业价值。数娃科技结合纵行科技ZETag云标签和淘思数据大容量时序数据库，为未来高增长、高并发的物流标签场景提供千万级访问量、百亿级时序数据。物流领域。全业务模拟压力测试。ZETag物流标签网络如下：压测目的：本次压测模拟10000个ZETAAP和数千万个ZETATAG标签的在线运行，准确高效的完成ZETAAP和ZETATAG的在线协议解析，真实-分析数据的时间存储。海量数据的在线查询、展示等过程。同时，抽象出真实的物流业务场景，实现ZETATAG批次在不同线路上的轨迹变化，在移动过程中使用不同的ZETAAP实现定位。ZETATAG在线运行过程中，每15分钟发送一次心跳包，由附近的单个或多个ZETAAP上报给服务器。服务器会根据策略选择上报信号最好的号码进行存储，并使用上报信号最好的AP定位ZETATAG。通过压力测试，可以判断系统在当前应用环境下的负载能力，为未来应用范围的扩大和用户数量的增加提供必要的技术支持和服务器规划，服务器扩容升级等。本次测试的目的是验证基于舒娃连接和设备管理平台的ZETA物流跟踪管理，能够实现千万级ZETATAG标签同时在线稳定运行，数据及时回传，正常存储，高效的图书馆搜索。这个测试场景的压力和复杂度远高于真实场景。在保证ZETA物流跟踪当前业务正常开展的同时，也可以有效支持ZETA相关业务应用的拓展和深化。压力测试环境由于压力测试是对系统负载能力的测试，不可能通过真实环境获取相关指标。因此，通过测试机和测试服务，模拟10000个AP、数千万个ZETATAG以及与服务器的高频数据交互。算法通过虚拟现实业务场景中的实际操作进行测试。测试机部署虚拟云设备服务，压力测试的客户端机器一般采用高配置的机器进行测试。压力测试时，一般忽略测试机器对压力测试结果的影响。服务器：
硬件配置
服务器类型
腾讯云服务器
处理器
12核CPU2.0GHz
内存
48G
硬盘
500G
……
操作系统
LINUXcentos7.364位
数据库系统
Tdengine1.6.3应用软件
span>span>连接平台+应用服务器+数据库服务器测试机：硬件配置
p>服务器类型span>腾讯云服务器</span>
处理器
4核CPU2.0GHz
内存
8G
硬盘
200G
……
操作系统
LINUXcentos7.364位
应用软件
虚拟基站+虚拟卡车+虚拟Zeta标签+压力测试场景ZETA设备运行模拟：ZETAAP：每隔10s主动连接一次服务器，30分钟未连接等待2分钟再次连接；连接状态下，每1分钟有一次心跳交互；连续3次没有收到ACK，发起重连ZETATAG：每15分钟上报一次心跳不同AP收到并上报心跳报文后，服务器会比对保留AP上报的AP位置信息第一次收到TAG心跳后3秒内最强的RSSI作为TAG的当前位置。客户端场景模拟说明：输配电线路：本场景共模拟200条线路，线路可配置。运输车辆：该场??景模拟50000辆运输车辆，卡车将模拟真实的物流场景按照既定路线行驶，车辆上的ZETAG标签会随之移动。ZETAAP：本次模拟有10000个ZETAAP，每条线上分布500个ZETAAP。ZETATAG数量：1000万个ZETAG在该模拟中运行。ZETAG与运输车辆一起移动，每15分钟心跳消息被相邻的2-3个ZETAAP接收。服务端业务说明：1、完成每15分钟千万级ZETAG标签心跳包解析（加上冗余消息，每15分钟解析超过2000万个心跳包）；2、完成ZETATAGHeartbeat数据比对和冗余数据过滤；3.完成分析的海量TAG位置信息的实时分类存储；4.支持最新的ZETATAG位置更新和轨迹查询；5.每分钟完成10000条ZETAAP心跳报文分析、存储；6、完成ZETAAP运行状态信息的接收和存储；7.支持ZETAAP运行状态信息查询。根据消息在测试系统中的业务场景，选取以下指标作为场景压测的判断依据：A.ZETAAP在线统计B.ZETAAP在线率C.在线ZETAG标签数D.ZETA标签分析包数E、1/5/15分钟CPU平均负载F、内存占用+压测技术+系统监控服务器和客户端系统监控及业务数据监控使用Prometheus&Grafana进行统计展示时序数据监控---Grafana&TDengine监控插件（监控TDengine数据总量、丢包数、增长率）系统指标监控---Grafana&&Prometheus监控插件，使用node\_exporter采集数据（监控CPU、内存、网络、存储四大指标)业务消息监控---Grafana&Prometheus监控插件，业务层使用Prometheus客户端实时统计各消息路由节点上发送、接收、丢包数等指标。业务层的主要指标如下：{"name":"ap","help":"numberofaps","type":"counter","labels":["from"]},{"name":"tag","help":"tag包数","type":"counter","labels":["from"]},{"name":"zetag","help":"zetaginfo","type":"gauge","labels":["status"]}][{"name":"shuwa\_group\_metrics","help":"数蛙任务调度和messageaggregationmessagestatistics","type":"counter","labels":["di","tid","rid","cid","type"]}]+定时数据ZETag的地址字段物流标签为4字节，最高字节为保留字节。本次压测ZETag物流标签实际地址字段为3字节，所以ZETag地址为FFXXXXXX，一共16777215个标签地址，如果按照一个标签设备一张分表的方式设计，需要1600万个以上的分表根据实测结果，Tdengine1.6.3单机版分表数超过4910000极不稳定，容易死机，但在分表数小于100000时性能良好。因此分表设计采用虚拟分组设计，以最低两个字节（共65535个分表）作为分表空间，每个分表存储一个字节（共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(),<<"状态"\>>=>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)。-作者（“舒娃”）。-export([rand\_tag/0,t/0]).rand\_tag()->integer\_to\_binary(4278190080+round(rand:uniform()*16777215),16)。t()->显示a\_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分钟，平均QPS超过14000。峰值QPS很容易超过Tdengine的入站QPS阈值，导致Tdengine崩溃。在消息路由层，设计了一个基于令牌桶算法的消息缓冲层，用于调峰处理。在保证时序数据顺序的同时，还可以让时序数据以相对稳定的速率分批存储。由于Tdengine没有提供erlang连接池程序，所以一开始使用默认的http客户端存放在库中，长期运行不稳定。最后，我们修改了Tdengine原生的c语言连接池程序，增加了mqtt订阅功能。批量仓库的时序数据通过mqtt协议进行转发。时序数据出库策略：由于分表的虚拟分组设计，有非常方便的寻址算法，可以找到任意物流标签数据的物流轨迹数据，快速找到用户层期望的时序数据，在百亿数据规模的情况下，查询速度也可以达到毫秒级别。ZetaEtag实时数据查询接口：/zeta/etag/{tag}超时5秒随机读取标签，数据库中数据为58169933标签生成方式：FF开头的后六位随机生成请求次数/次数
200000
测试总时间/秒
269.583
返回200个数
120116/200000
返回404数
79884/200000
返回其他状态code
0/200000
返回成功率/%
100
100
/每秒请求/seconds
741.88
*返回200（找到目标标签）或404（未找到目标标签）的状态码，均视为调用ZetaEtag历史数据接口成功：zeta/etag/history/{tag}timeoutis5秒全部标签随机读取，限制值为100，日期范围在合理范围内随机生成，数据库中有58169933条数据标签生成方式：开头后六位随机生成FF日期生成方式：1569558137~1569579737之间的随机数请求次数/次
200000
总测试时间/秒
298.123
返回200个数
200000/200000
返回其他状态码
0/200000
返回成功率<秒pan>/%
100
每秒请求/次/seconds
670.86
2019年10月做压测报告时，有没有记录240亿小时的API统计，还原去年的压测图，240亿标签数据查询速度如下+消息路由ZETag物流标签数据从数据生成到数据存储，1300多万个ZETagtags="50000Truckprocess="10000APbasestationclientconnectionprocess="10000APserverconnectionprocess="65535virtualgroupingprocess="messagecacheschedulingprocess="tdenginemqttclient="tdengineconnectionpoolstorageprocess,message需要要转发7次，每一跳都需要小心处理内存释放和消息拥塞问题，每15分钟有近3000万到4500万条消息产生和消费，这需要非常好的GC处理机制。其中，10000个AP的服务器连接过程——》65535虚拟分组过程，这一跳的报文转发率没有固定的对应关系，两点之间的QPS波动非常大，开源的mqtt消息转发和消费组策略也很容易造成消息拥堵，内存不断攀升，这也得益于之前的虚拟分组设计，通过虚拟分组更好的解决了这一跳的高效消息路由，也将这两点消息转发的QPS峰值降低到一个比较平坦的水平+影子设备本次测试模拟了双十一这样最繁忙的物流标签轨道场景，模拟了50000辆装满快递物品的货车（200多件快递物品）带有ZETag标签）在200多条路线上，在疾驰中，AP基站在行驶过程中不断切换，上报ZETag标签轨迹数据。准用户不定期登陆快递网站查询自己购买的商品到达了哪里。我们在系统中设计了50000个卡车影子设备、10000个AP基站影子设备和65535个虚拟包影子设备来应对这种相对复杂的业务场景。卡车影子设备携带ZETA标签信息、线路位置信息和沿线交互的AP基站信息。AP基站影子设备承载ZEtag通信协议处理，虚拟包影子设备承担1300万个ZETag标签的边缘计算和定时数据存储。处理。+任务调度每15分钟产生和消费近30-45百万条ZETag消息，不仅需要良好的GC机制，还需要良好的任务调度机制。治大国如烹小鲜。每个影子设备上的任务调度细节非常关键。每一个微小的偏差都会乘以30-4.5亿倍放大。任务调度的质量要求是零缺陷。合理的分组策略（即合理的影子设备设计）非常关键。能够从宏观上削减系统资源的峰值，对单个影子设备进行完善的微观操作，使每个影子设备的任务调度策略达到零缺陷。.+压力测试结果参考网站：舒娃科技：http://www.iotn2n.com/纵行科技：https://www.zifisense.com/道思数据：https://www.taosdata.com/>DG-IoT开源物联网DG-IoT发布