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