这是一个创建于 87 天前的主题，其中的信息可能已经有所发展或是发生改变。
需要查询设备是否在线，上次在线时间。
我初步的想法是单独维护一个在线服务，不依赖 redis ，设备离线才写数据库。
想请问大家有没有经验介绍。
19 条回复 • 2024-09-22 21:36:39 +08:00
 |
1
lasuar 87 天前
千万级并发？简单的模型是主动推送状态到服务器，入库前先写队列，然后在对数据库做统计查询 。相信楼下还有更好的想法
|
|
2
lasuar 87 天前
在写入队列前肯定还要二次对流量调整的，千万并发 mq 估计也来不起。可以设计一个扇入模型，部署多个无状态边缘服务来均衡流量，并同时在边缘处做请求合并，然后再将合并包上报到核心服务入 mq 入库。
|
 |
3
GeekGao 87 天前
自己实现？ 为此要设计 端的离线检测、多级缓存、集群分片和状态一致性的设计。
如果并发写太大，又不想用 Redis ，Cassandra 集群倒是一个不错的选择 |
 |
4
aw2350 87 天前
对数据特征做分片，例如 ID 尾号三位，不同分片的维护一个布隆过滤器 服务，上下线状态用布隆过滤器来维护
|
 |
5
echoZero 87 天前
如果 1 分钟一次心跳 也是 0.16M 的 QPS ，消息队列接着，状态存储分片
|
 |
6
Ipsum 87 天前
不然试试大数据的 Kappa 架构？
|
 |
7
gam2046 87 天前
如果还有其他业务信息需要传送，那么可以考虑 MQTT ，下线时间可以通过遗嘱消息实现。单纯只为了一个在线状态，那就没必要用这个了。
|
 |
8
ytmsdy 87 天前 via iPhone
influxDB 这一类时序数据库，然后正常写心跳包就可以了。
|
 |
9
aliipay 87 天前
好奇什么业务有这么大的设备量， 我所知道的开水团单车也就是这个量级
|
 |
10
RicardoY 87 天前
维护个靠谱的 KV 集群的就可以了，Redis ，Tair ，KeyDB 都随便...时序数据库也可以
这个量级没有多大，不要把解决方案搞复杂了 |
|
11
RicardoY 87 天前
#5 已经帮你做了估计了，160k 的 QPS 不是很多，可能需要注意下端上不要同一时刻上报心跳
|
 |
12
RangerWolf 87 天前
歪个楼，这个级别的客户端数量，一定要想好怎么降低流量费。。。
|
 |
13
flmn 87 天前
看看 MQTT
|
 |
14
inshua 86 天前  1
"需要查询设备是否在线，上次在线时间。"
1. 这些设备是连你还是你只负责查？ 1.1. 如果你只负责查，这个规模是很小的，当然还是要搞清楚设备是否经常掉线，查询量大不大，是 pull 还是 push 等等 2. 如果你要负责处理 1M 连接，好好研究一下网络服务器，做的好单机能支撑 |
 |
16
dyexlzc 85 天前 1
在线服务维护
———————— 有考虑过你的服务升级\重启、所在机器重启\断线的 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 集群基本的原理 。 |
|
18
dyexlzc 85 天前
@zhouhuab 从容灾的角度考虑，推荐 10 个 2 core 服务器，如果机器挂了起码只影响部分用户的在线状态需要重新 set 。没那么多机器的话就只能一台服务器了，也不是不能用 :-p
性能上考虑的话，两种方案理论上是一样的，如果能压测的话可以压测一下，因为 QPS 还和网络延迟、带宽有关。10 个 2core 服务器的网络条件可能会影响最终压测数据（有可能性能低于 20core * 1 ） |
|
19
inshua 61 天前
@zhouhuab Achieving 5M persistent connections with Project Loom virtual threads | Hacker News : https://news.ycombinator.com/item?id=31214253 支持百万连接不难, 但能否处理过来要视负载视情况而定, 游戏服务器和物联网终端肯定是不同的.
|
Select Language