本文的NewLife.IoT平台为商用产品,这里选择数据接收与存储部分,分享一下海量数据下的架构设计。

结果数据

早些天企业版客户对NewLife.IoT平台进行性能测试,积累了一些经验,这里分享一下。

该客户单项目大概有4万设备共10万点位,要求一分钟内每点位至少上报两次数据,也就是20万tpm。

先来看结果,星尘监控得知,每5分钟峰值1000万点位数据,折算200万tpm

应用服务器配置:16核32G

数据库服务器配置:16核64G,装MySql 8.0、Redis 6.2

刚开始的时候,应用服务器是8C16G,数据库是4C32G,每5分钟大概处理200万点位数据。

基础知识

物联网平台服务端(以下简称IoTServer)共设计了属性上报和数据上报两个接口。

  • 属性上报 PostProperty

客户端维护一个属性字典(点位表),记录每个属性的最新值,每60秒上报一次(周期可调)。

上报之前,不管采集多少次,都只更新本地属性字典。

因此,属性上报接口的吞吐要求,就是每分钟处理系统的设备点位总数。

  • 数据上报 PostData

每次采集之后,判断属性点的数值是否发生改变,如有改变则放入上传队列,批量上传IoTServer。

采集间隔一般是1s~5s,实际上报数据量还取决于点位数据变化率。

IoT平台的这一项设计,既保证了点位数据发生改变后的及时上传,又把定时上报属性数据作为兜底方案,确保数据新鲜性和完整性

例如烟雾传感器,没有触发报警时它的采集值永远是0,该类设备几乎只有定时上报数据,而没有上报数据。一旦触发报警,在1秒内可上报通知IoT平台,并触发规则事件通知各个业务系统。

架构设计

每5分钟1000万点位数据,意味着接口吞吐是1000w/5/60=33333tps,需要注明这里是单机而不是集群。

聚合上传

普通的WebApi接口也比较难达到这个吞吐。

因此我们首先需要改造接口,聚合一些数据,做成批量上传。批大小在10时,接口吞吐只要求3333tps,批大小在100时候,接口吞吐要求333tps,还是比较容易能够达到的。

存储架构

IoT平台在数据存储上分为三部分:

  1. 属性表。记录每个点位最新数值,PostProperty/PostData 两个接口都要Update这里的数据;
  2. 数据表。时序数据表,点位的每次上报都插入一行,PostProperty/PostData 两个接口都要Insert。使用MySql等关系型数据库时按天分表,使用TDengine时不用分表。XCode支持自动分表以及支持多种数据库;
  3. 数据队列。点位数据的消息队列,用于驱动下游各种业务逻辑,包括策略引擎、数据推送、数据分析统计等等。可选择Redis队列等消息队列中间件,如NewLife.Redis。

异步落库

一般的MySql数据库根本达不到这个吞吐,并且系统按照一比三放大了存储。

属性表和数据表可以使用XCode的SaveAsync异步保存,进入实体队列后批量落库。

数据队列可以借助延迟队列 DeferredQueue 凑批,然后批量写Redis队列。


对于NewLife.XCode用户来说,保存点位数据本来是 data.Save(),只需要改为 data.SaveAsync,吞吐立马就上去了。


作者:大石头 发布:2022-06-11 10:53:58 浏览:550)