背景
在工业设备的一些场景中，一般会有设备运行状态监控这种功能要求，面对成千上万台单点设备，如何在PC上监控所有设备的运行状态？
解决方案探讨
先做两个假定：
1、首先，假定系统需要上报的单点设备有10W台（一般的工业系统有如此规模，应该是已经做得很强很大了，因此百万级别的，这里先不考虑），并且设备的mac地址是随机均匀分配的，需要每分钟上报一次(也可以每5分钟上报一次)，上报的频率越少，对服务器的压力就越小。
2、其次，假定通过HTTP请求的方式，服务器端提供统一的接口，每个单点设备调用接口上报自己的运行状态，Socket上报的方式也暂不考虑。
可能会面临的问题
很容易想到一种简单的方式，即在设备上启动一个定时任务，每分钟调用一次接口，然后上报运行状态，很显然这种方式有一个很大的问题，稍微有经验的程序员都能够想到，所有的设备上报状态都发生在每个整数分钟，服务器端的接口如果不做处理，是不能承载很大的并发量的，面对这种情况，我提出了如下解决方案，共大家参考。
解决方案
整体的解决方案，主要分为三部分：
分散各个单点设备调用接口的时间，尽量做到不是所有设备都在整分钟的时候上报状态，而是划分为60个区间，争取做到每秒上报的设备数量是大致相同的。
具体实现策略：每一台设备都有一个物理mac地址，一般都是一个16进制的字符串组成的，比如某几种平板的mac地址是6A:4A:E9:7A:A7:16，94:BE:46:7F:22:8D，将mac地址的最后两位 转换为十进制，然后在用60（一分钟共60秒）对其取余，返回的值范围一定是在0~59，即将这些设备划分到60个不同的时间区间内，然后设备上启用一个定时任务，每秒执行一次，如果前面取余的值等于当前时间的秒数，则可以调用上报接口，否则不上报。
这个策略成功的将10万台设备，分到60个不同时间区间，每个区间有1666台设备，大幅度降低并发量。当然这个是假定所有的设备mac地址均是随机的，均分到60个时间区间也是大概率事件。
一般的系统，做到这一步，应该就能够满足生产需求了，系统结构简单，并且易于实现。
服务器端做削峰处理。
现在服务器端做削峰处理的方式很多，比如常见的引入消息机制。将所有的请求先放入消息队列，然后服务器端逐个进行落库处理，针对前面10万级别的，每秒1700个请求，太大材小用了。对于消息机制能够处理的并发量能力，相信大多数程序员都经历过各种电商节，这里就不在赘述了。
多服务器部署。
当单服务不能满足业务量的情况下，通常的解决方式就是扩展服务器，增加服务端水平处理问题的能力了。
再回来说一下如果有100W台设备的情况，经过第一步的处理，每秒就已经降级到1.6万次请求，第二步时，请求进入消息队列，然后服务器端比如增加到10台，分配给每台机器的是1600个请求，比如落库时使用的数据库不是特别糟糕，基本上都没问题，在如果上升到1000万台设备，此时，我想应该直接落库到高速缓存中了吧，比如redis，在定期将缓存中的数据批量更新到数据库。
总结
前然后本文是基于每分钟上报一次，实际情况也有可能是每五分钟，或者10分钟,比如5分钟的，可以均等为5分钟，或者更细的300秒，看实际设备数量大小，实际情况可以参考本文的思路。
面的步骤一和二，没有什么依赖，完全看个人选择，但是直接上步骤三，被玩死，是大概率事件！
