请教 10M 级别设备在线状态的最佳设计

[zhouhuab]

需要查询设备是否在线，上次在线时间。

我初步的想法是单独维护一个在线服务，不依赖 redis ，设备离线才写数据库。

想请问大家有没有经验介绍。

[lasuar]

千万级并发？简单的模型是主动推送状态到服务器，入库前先写队列，然后在对数据库做统计查询 。相信楼下还有更好的想法

[lasuar]

在写入队列前肯定还要二次对流量调整的，千万并发 mq 估计也来不起。可以设计一个扇入模型，部署多个无状态边缘服务来均衡流量，并同时在边缘处做请求合并，然后再将合并包上报到核心服务入 mq 入库。

[GeekGao]

自己实现？ 为此要设计 端的离线检测、多级缓存、集群分片和状态一致性的设计。
如果并发写太大，又不想用 Redis ，Cassandra 集群倒是一个不错的选择

[aw2350]

对数据特征做分片，例如 ID 尾号三位，不同分片的维护一个布隆过滤器 服务，上下线状态用布隆过滤器来维护

[echoZero]

如果 1 分钟一次心跳 也是 0.16M 的 QPS ，消息队列接着，状态存储分片

[Ipsum]

不然试试大数据的 Kappa 架构？

[gam2046]

如果还有其他业务信息需要传送，那么可以考虑 MQTT ，下线时间可以通过遗嘱消息实现。单纯只为了一个在线状态，那就没必要用这个了。

[ytmsdy]

influxDB 这一类时序数据库，然后正常写心跳包就可以了。

[aliipay]

好奇什么业务有这么大的设备量， 我所知道的开水团单车也就是这个量级

[RicardoY]

维护个靠谱的 KV 集群的就可以了，Redis ，Tair ，KeyDB 都随便...时序数据库也可以
这个量级没有多大，不要把解决方案搞复杂了

[RicardoY]

#5 已经帮你做了估计了，160k 的 QPS 不是很多，可能需要注意下端上不要同一时刻上报心跳

[RangerWolf]

歪个楼，这个级别的客户端数量，一定要想好怎么降低流量费。。。

[flmn]

看看 MQTT

[inshua]

"需要查询设备是否在线，上次在线时间。"
1. 这些设备是连你还是你只负责查？
1.1. 如果你只负责查，这个规模是很小的，当然还是要搞清楚设备是否经常掉线，查询量大不大，是 pull 还是 push 等等
2. 如果你要负责处理 1M 连接，好好研究一下网络服务器，做的好单机能支撑

[zhouhuab]

@inshua 谢谢，单机 1M ，有没有啥好的建议和文档？

[dyexlzc]

在线服务维护
————————
有考虑过你的服务升级\重启、所在机器重启\断线的 case 不。

简单点就 redis 加 key+ttl ，设备定时 ping 更新续期，设备下线主动删除 key ，ping 丢失\下线通知丢失依赖 redis 的 ttl 过期。
这样你的服务重启、升级、机器维护，也不影响。

redis 单进程 qps 就算 10w ，你的 10M 量级 10 * 1kk / 1kk = 10s 也能全部操作完成了。
如果一定要 1s 内全部操作完，那就起 10 个 redis ，简单点按照某个客户端 id % 10 取余分发到某个 redis ，1 秒就能操作完 10M 的量级，实际上这个方案就是各个大厂 redis 集群基本的原理 。

[zhouhuab]

@dyexlzc 10 redis 在一台多核服务器（比方说 20 cores ），还是 10 个 2core 服务器？哪个更优？

[dyexlzc]

@zhouhuab 从容灾的角度考虑，推荐 10 个 2 core 服务器，如果机器挂了起码只影响部分用户的在线状态需要重新 set 。没那么多机器的话就只能一台服务器了，也不是不能用 :-p

性能上考虑的话，两种方案理论上是一样的，如果能压测的话可以压测一下，因为 QPS 还和网络延迟、带宽有关。10 个 2core 服务器的网络条件可能会影响最终压测数据（有可能性能低于 20core * 1 ）