1、消息风暴:1V1时,每10秒发一个消息,那么每秒消息量是0.1。500人群每10秒一个消息,推送消息量是5001/10500=25000。10万人群直播间每10秒一个消息,推送量是1000001/10100000=1000000000=10亿。无论服务器和客户端都无法承载,服务端会限流和选择性丢弃,客户端上限也就是每秒几十条。

2、链路优化:用户发消息后,业务层服务器需要查询接收方的在线状态(链接在哪台服务器上),高并发场景下,这个在线状态服务将会成为瓶颈。 改为:业务层消息入队,接入层的每台网关都订阅这个队列,然后由网关决定给哪个链接推消息。

3、微服务拆分:把打赏、弹幕、点赞、送礼等核心业务 和 直播回放、第三方同步等非核心业务拆分;把容易成为瓶颈的和不容易成为瓶颈的拆分。

4、扩容缩容:指定监控指标,如机器侧的负载、CPU等,和业务侧的同时在线人数、弹幕数、延迟等指标,自动扩容和缩容。

5、负载均衡:扩容后,如果负载均衡策略不变,新链接可能还是均匀的分布给新老机器,导致老机器先到达瓶颈,因为负载均衡器本身也需要扩容,不同的机器可能采用不同了算法,达不到预期。 因此,可以在入口层建立一个调度器,先通过调度器查询可以链接到哪台机器。

标签: 架构, 即时消息

添加新评论