直播评论系统分析设计
直播评论系统是电商系统一个常用的功能，即在发布新品的时候，为了吸引用户参与和营造互动气氛，让参与的每个人都可以发消息，发完后每个人都可以即时看到新消息，原型和 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秒；降级，哪些是非核心功能，但可能会消耗很多资源的，像发送图片，如果回源压力比较大的情况也是可以关闭的。