专栏首页程序员升级之路直播评论系统分析设计

直播评论系统分析设计

直播评论系统是电商系统一个常用的功能,即在发布新品的时候,为了吸引用户参与和营造互动气氛,让参与的每个人都可以发消息,发完后每个人都可以即时看到新消息,原型和 http://live.oneplusbbs.com/ 差不多。

假如要求在线用户数是20W,你会如何设计系统呢?

任何系统设计都不能离开用例设计,脱离业务讲技术都是耍流氓,我们先分析功能需求:

1、发表消息

假设消息最长内容为1K,可以有图片。

2、接收消息

要求用户不低于2秒能收到最新消息。

这里最基本的功能,然后我们分析下一些非功能性需求:

1、发表消息

A、要能够限制一些广告或政治敏感内容,这块看公司的基础服务是否完善,如果有相应的功能,可以接入相关服务,不过要注意此服务也要扩容;没有的建议接入第三方相关服务;

B、要防刷屏,即防止某个用户单位时间发送太多的评论,所以要做下频率限制;

C、图片的保存,我们可以算一下带宽,如果一张图片大小是5K,同时在线20W人,则一条消息需要约1G的带宽,建议将图片放入CDN;

另外还要注意回源的问题,即一张图片第一次访问的时候会有大量的回源,最好是做预取的处理,即在发表评论的时候就主动推送到CDN上。

2、接收消息

20W人在线,假如1秒钟会发送1000条消息,每条消息平均长度是500字节,则需要100G的带宽,这估计也不是我等私有云机房所能承受的。

所以这块建议采用购买第三方服务来实现,如果实在是要自己实现,至少这块得放入公有云上,并且做好带宽的预估及限流手段,防止机房带宽被打爆。

3、存储的设计

首先要考虑的是要不要存本地,如果不用备份,可以直接发送给第三方就不用本地保存。

如果需要本地保存, 20W在线用户,如果有5%的人同时发消息,则有1W的TPS,所以写Mysql是不大现实的。可以考虑写入到Redis中,Redis List类型结构适合此类场景。

消息重复接收问题

消息推送系统很难保证消息不会重复,所以前端接收新消息时需要和已经接到的消息ID进行对比,如存在则过滤掉;推送给第三方时每条消息都要加上消息ID,消息ID可用UUID生成,简单实用。

乱序和延迟问题

对于乱序的情况,保证消息展示时按时间倒序排列的。

如果新收到一条消息,可能是5分钟前发送的,前端展示时需要判断是否小于当前屏幕的最早消息的发送时间,如果是就可以忽略这条消息了。

系统的可用性设计

一、如果第三方消息推送服务挂了,怎么办?

可以有几个方案:

1、多选一家消息推送服务商;

2、兜底方案,如果所有第三方服务都挂了,可以让前端使用轮询方案,但轮询的间隔需要后端接口给出,可以在后台配置,根据压力大小做调整。

二、如何保证消息不丢

要注意Redis的持久化设置,AOF模式下有1秒刷盘的策略,极端情况下,可能会丢失1秒的消息;当然了如果要做到完全不丢失消息则可以配置每次都刷盘,这需要结合业务情况去平衡。

总结

还有很多细节这里没有展示,如监控,怎样知道用户收到消息的延迟不超过2秒;降级,哪些是非核心功能,但可能会消耗很多资源的,像发送图片,如果回源压力比较大的情况也是可以关闭的。

本文分享自微信公众号 - 程序员升级之路(gh_1fab42db66cb),作者:刘江华

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 从RabbitMQ Channel设计看连接复用

    今天公司有同事在做RabbitMQ的分享的时候,讲到了Connection和Channel的设计,有同学有疑惑,为什么不用连接池实现,而要通过Channel的方...

    心平气和
  • RabbitMQ跨机房迁移数据零丢失

    公司以前大部分服务在私有云上,因使用有一段时间了,机器比较老化再加上运维成本高,计划将整个机房上云,因负责中间件一块,所以最近将RabbitMQ顺利地迁移到云上...

    心平气和
  • RabbitMQ网络框架代码分析

    RabbitMQ的启动步骤是一个有向无环图,具体细节后面另外章节再聊,其中网络一块的启动集中在文件rabbit_network.erl中

    心平气和
  • ActiveMQ介绍

    1、ActiveMQ服务器工作模型       通过ActiveMQ消息服务交换消息。消息生产者将消息发送至消息服务,消息消费者则从消息服务接收这些消息。这些消...

    小帅丶
  • 快速学习-RocketMQ设计理念

    消息存储是RocketMQ中最为复杂和最为重要的一部分,本节将分别从RocketMQ的消息存储整体架构、PageCache与Mmap内存映射以及RocketMQ...

    cwl_java
  • 消息队列| RocketMQ 核心原理

    a. fork下来,起一个demo,上一个测试环境,遇到问题再去社区提问或找些实践文章;

    heidsoft
  • Kafka消息规范

    Kafka作为一个消息队列,有其自己定义消息的格式。Kafka中的消息采用ByteBuf,之所以采用ByteBuf这种紧密的二进制存储格式是因为这样可以节省大量...

    shysh95
  • rtmp规范1.0

    本文为Adobe rtmp规范1.0的中文介绍,其中内容大部分都是翻译自rtmp官方文档rtmp_specification_1.0.pdf

    职场亮哥
  • 庖丁解牛 | 图解 RocketMQ 核心原理

    a. fork下来,起一个demo,上一个测试环境,遇到问题再去社区提问或找些实践文章;

    王知无
  • 如何把开源项目用好?图解 RocketMQ 核心原理

    本文来自 Apache RocketMQ 的资深用户丁威,他和 MyCat 的核心开发者周继锋合著了《RocketMQ技术内幕:架构设计与实现原理》一书,目的是...

    华章科技

扫码关注云+社区

领取腾讯云代金券