数据采集器的大数据量算法求教

[竹君子]

项目中需要有200万个以上的数据采集器，这些数据采集器每8分钟会把采集到的数据提交出来，单次数据的量不大，大概在200个字节。但是因为并发数很大。不知道这样的要求，需要采用哪种技术或者架构来实现？

[竹君子]

没有 人给建议吗

[小小二子]

今天刚好咨询一个有经验的前辈，他针对我的系统，建议我做缓存来处理这种大的并发数据，先将数据存在缓存里，然后单独开一个线程专门来处理缓存。 希望对你有帮助。

[MiceRice]

200万个数据采集器，8分钟一次提交，也即每分钟大约要处理 25万次请求；每秒 TPS 为：4166 这个量级很高，恐怕要多服务器来处理。 如果网络比较有保障的话，可以考虑 UDP 协议（非可靠传输），但是会面临数据包丢失的风险。 采集服务器可以将所接获数据包直接写到本地磁盘文件中，这样效率高又减少宕机导致数据大量丢失风险；然后再由专门服务器负责将各磁盘文件的批量导入到数据库中。

[吃兔子的萝卜_110]

关注.也有相同的问题

[竹君子]

MiceRice ：那这样的话，数据的实时性可能获取不了了。 至少保证1个小时内，能更新一下数据

[MiceRice]

引用 5 楼 superch0054 的回复:

MiceRice ：那这样的话，数据的实时性可能获取不了了。 至少保证1个小时内，能更新一下数据

不会，你如果要求分钟级的，恐怕还真有点难度，小时级别绝对没有问题。 另外，为了优化读写分离，采集服务器按时间来切分写入的流水文件，比如5分钟写一个新文件。 文件命名可以按时间来命名，便于负责汇总导入的服务器来查找。 负责导入的汇总服务器，先将各采集服务器的日志目录mount到该汇总服务器上，然后程序只需要周期性检索日志文件（比如1分钟扫一遍各目录有没有新的文件出来），然后批量导入数据库即可。 另外还可以增加对于历史流水文件的处理，比如对于已经导入数据库的流水文件，可以将其移动到某个备份目录，也可以爽快的删除。

[竹君子]

200万个数据采集器，8分钟一次提交，也即每分钟大约要处理 25万次请求；每秒 TPS 为：4166 ---- 为什么是每分钟大约要处理 25万次请求。 每个集线器隔八分钟发送一次数据。如果真不凑巧的话， 有可能是在同一个时间段内同时就有200个请求啊。 这个量级很高，恐怕要多服务器来处理。 如果网络比较有保障的话，可以考虑 UDP 协议（非可靠传输），但是会面临数据包丢失的风险。 ---- 数据最好能不丢。当然如果能保证每个集线器每10次只丢一次包的话，应该也能接受。如果这样能使得性能有保证的话

[MiceRice]

引用 7 楼 superch0054 的回复:

---- 为什么是每分钟大约要处理 25万次请求。 每个集线器隔八分钟发送一次数据。如果真不凑巧的话， 有可能是在同一个时间段内同时就有200个请求啊。

看理解有没有偏差： 你这200万个数据采集器，每个采集器每隔8分钟提交一次数据，对么？ 那么我是这么算的： 200万个 ÷ 8分钟 = 25万/分钟 ÷ 60秒/分钟 = 4166.666666/秒 另外实际上还要估算峰值，根据80/20原则，峰值可能在： 4166.66666 × 80% ÷ 20% = 16666.6666/秒 那么平均每秒需要处理约4,167个请求，峰值情况下每秒需处理16,667个请求。

引用 7 楼 superch0054 的回复:

---- 数据最好能不丢。当然如果能保证每个集线器每10次只丢一次包的话，应该也能接受。如果这样能使得性能有保证的话。

网络质量良好的情况下，UDP的丢包率还是比较低的。但它的问题是不保证，所以如果碰到突然质量不良好了（无线信号弱等原因），极端情况下丢包超过99%也是可能的。不过我觉得你的场景里面应该可以暂无视这种情况，毕竟这种情况下，即便用TCP连接，你也毛都收不到，包虽然不丢，但是全阻塞在发送端发不出去。