直播评论系统分析设计

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

直播评论系统分析设计_第1张图片

假如要求在线用户数是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秒;降级,哪些是非核心功能,但可能会消耗很多资源的,像发送图片,如果回源压力比较大的情况也是可以关闭的。

一次线上Mysql死锁分析

灰度发布

你可能感兴趣的