- 🏃♂️ 微信公众号: 朕在debugger
- © 版权: 本文由【朕在debugger】原创、需要转载请联系博主
- 📕 如果文章对您有所帮助，欢迎关注、点赞、转发和订阅专栏！
前言
前段时间协助帮忙进行 IOT 系统设计与分析，记录一下大致的过程吧。感觉还是挺有意思的一件事。
IOT系统：
Tips：起源于传媒领域，是信息科技产业的第三次革命。物联网是指通过信息传感设备，按约定的协议，将任何物体与网络相连接，物体通过信息传播媒介进行信息交换和通信，以实现智能化识别、定位、跟踪、监管等功能。
一、整体需求
需要一个通用的设备监测系统，可以由第三方主动推送数据，系统需要可以灵活配置接口，系统需要根据设备的监测状态等判断是否需要推送告警数据以及发送第三方通知【短信、邮箱等】，剩余的就是设备监测的信息化管理和可视化展示。 其中对方最看重的是监测数据如何合理规划进行存储，查询时不会产生慢查询情况。
二、需求拆分：第三方推送数据的接口
肯定需要当前系统进行制定，完善后写清楚接口文档，给到第三方设备，让他们的传感器按照这种数据格式进行数据的推送，我们只负责接收，接收后分步骤进行设备消息表、设备告警表等业务逻辑操作。
至于灵活配置接口，可以理解为系统配置多种协议的接口，例如 MQTT、HTTP、CoAP等，可以使用策略模式对此接口进行设计，符合开闭原则，如果后续需要接入更多的协议，那代码写起来就舒服了。
▲图 / 策略模式图解
三、需求拆分：第三方消息推送
需要当前系统进行制定，只是这一块对于客户来说，就不存在什么个性化需求，系统可以就只设计支持那几种消息通知，估计这块代码变动量应该很小，故此块代码不考虑引入设计模式。
初步支持短信、邮箱俩种通知方式。
四、需求拆分：监测数据如何合理规划进行存储
老板说要支撑亿级数据访问😂，预计是每日消息表会新增 5k 到 10k 数据，表字段其实还算较少，我提供了俩种思路。
鉴于未来目标数据量会超过单机 MySQL 数据库的处理能力，所以需使用分库分表或分布式数据库来支撑海量数据。
当然，也可以用 MongoDB ，因为该场景涉及的 ACID 很少，可能用 MongoDB 更为合适。 我本人是更熟悉 MySQL 的，所以下面的方案是基于 MySQL ，如果要采用 MongoDB ，可以自行查找内容。
目前分布式数据库普及率较低（小公司），分库分表技术仍是大多数公司的选择，所以下面的解决方案会以分库分表技术来说明。
设计都是按照系统未来 3-5 年数据量进行分析设计的。此系统更需要高 QPS，TPS 很小。
以设备消息表为例： 算是每日 1w 数据，一年算 400w 数据，五年内数据量大概在 2000w 左右，且单行数据内容不大的情况下，有以下两种方案进行选择：
1、引入 Sharding Sphere 进行分库分表处理
好处：
各个表的压力相对均匀一点。只要确定好分片键，中间件会自动进行分库分表，省去人工干预。 弊端：
引入新的中间件，需要开发人员掌握此项技术。以及如果后续需要人工排查数据的话，数据跨表会比较麻烦。需要写SQL去查。
2、使用业务代码按每月进行分表处理，每个月提前创建好下个月的表，然后存储时根据判断存入相应的表中
好处：
不需要引入中间件，人工介入排查问题也好排查些。 弊端：
只有近期月份的表的压力会大一些。就是分表业务逻辑需要自己写，以及对应的查询逻辑，涉及到跨月份的需要另外的逻辑处理。
五、总结
第一次接触 IOT 相关的系统，还是挺有意思的，多学习还是一件好事，多长点见识。
finally
如果大家觉得本文写得不错，别忘了给个赞哦！同时，如果您有任何疑问或建议，欢迎在评论区留言，让我们一起交流、探讨！