大数据量物联网平台开发笔记（持续更新）

今年我们公司在母公司的支持下要开发一套物联网平台，以后卖出去的设备自动连接到这个平台上，再推送到第三方。预计目标是中期十万设备，长期百万设备的级别。TPS预计是设备数量除以10，1万/s。开发之前觉得没什么难度，后面倒是遇到很多问题。特别是压测以后。

1.作为平台要考虑到第三方接入时可能不稳定的问题，如果使用mqtt或者http通信，要考虑到失败的问题，首先一直等待或者重试肯定是不合理的。比较合理的策略是只发送一次，失败后设置一种策略重试一定次数。或者推送到某种mq里面让第三方自己去取。

2.大流量的情况下每多一个节点都要增加很多的服务器支持，特别是我们系统使用rocketmq转发分流，效率没有想象中高，即使什么逻辑都没有单单转发一个服务也只能达到上千的TPS，所以尽量减少中转的节点

3.首次尝试使用了springcloud的微服务架构来调用基础服务，发现通过微服务的调用有线程数的限制，多个服务同时调用相同服务时会互相影响。通过优化配置项等能提高一些，但是还是要加服务器。不如直接在各个服务里面依赖组件调用。

4.单条数据写入db效率很低，批量导入insert()values(),(),(),()在上千条数据规模的前提下能快几十倍。暂时使用redis保存临时数据后批量写入了，后续考虑使用flink之类的流处理框架实现

5.批量写入sql后另一个瓶颈是rocketmq消息的发送，后续也考虑批量发送的方式，具体的效率需要测试。

6.合理设置项目启动内存能大大加快服务处理消息的速度。

7.阿里云iot发送消息的效率不高，而且会占用上下行TPS的指标，以前我们自己规定协议实现了应答的模式不得不取消了，至少在心跳和生产数据上取消了，这两种数据占了90%以上的总数据。

8.数据协议制定的时候尽量使用简写，仔细斟酌字段是否需要，数据量大的时候成本很可观

9.所有的数据尽量分片，特别是redis，不要使用固定键名导致大量数据保存到同一个库

10.一定要考虑报错出问题的情况，就算逻辑没有错误，也可能因为某个服务出问题导致报错，如果不做任何处理数据就会丢失，而数据丢失对物联网来说比短暂的失联还要致命。可以在接收消息的第一时间打印出来，便于后期恢复数据

11.rocketmq的消费者数量和队列数量相关，原理是把每一个队列分配给某一个固定消费者，这就导致如果某一个消费者的消费能力不足，分配给它的队列消息就可能堆积，同时就算某一个消费者的消费能力很高，但是也只会消费分配给它的队列，导致过剩的性能被浪费。所以rocketmq的消费者不是越多越好，不能有明显的短板，消费能力尽量平均。如果队列没有平均分配，那么分配队列更多的消费者应该有更高的性能