关于微博评论功能的设计与思考

 前几天的上线功能bug，由于评论数量过多，未异步加载，导致数据丢失，原因是新老功能迁移时未做异步加载，就此功能找一下微博类评论等功能的架构设计思考，还有其他产品，社区，论坛，博客等。

    微博曾流传可支撑8位明星同时出轨，但大事件屡屡挂掉，周杰伦出新歌，充值点播渠道挂掉，2019年财报微博日平均活跃用户2.16亿，面对亿级平台该如何设计架构？

关于微博评论功能的设计与思考：

微博作为一种社交媒体平台，具有广泛的影响力和用户群体。评论功能是微博平台的核心功能之一，它不仅提供了用户交流和互动的机会，还可以增加内容的可读性、吸引用户参与和提升用户体验。因此，设计和思考微博评论功能的合理性和有效性至关重要。

首先，在设计微博评论功能时，应该考虑到用户交流的需求和场景。用户在评论时，通常希望能够直观地表达自己的观点和情感，因此应该提供一个简洁明了的评论框，方便用户输入文字，并且支持不同的文本格式，如加粗、斜体等。同时，应该提供一个友好的界面，方便用户查看和回复他人的评论。

其次，为了提高评论的质量和可信度，应该采取一些措施来限制恶意评论和垃圾信息。例如，可以设置评论长度的限制，以防止用户发布过长的评论。另外，可以引入人工智能技术，对评论内容进行自动过滤和审核，识别并删除不符合规范的评论，如辱骂、广告等。这样可以有效地维护平台的秩序和用户的体验。

同时，微博评论功能也需要提供一些附加功能，以增加其灵活性和多样性。例如，可以支持评论点赞功能，让用户能够表达对他人评论的认同和赞赏。另外，可以支持评论排序功能，根据热度、时间等因素对评论进行排序，让用户更方便地浏览和参与热门话题。

另外，为了促进用户交流和互动，可以考虑引入@功能，让用户能够在评论中@其他用户，从而直接与其进行对话。这样可以增强用户之间的联系和互动，提升用户粘性和参与度。另外，可以提供评论回复通知的功能，向用户发送通知，提醒他们有人回复了自己的评论，增加用户的参与感和归属感。

此外，还可以考虑通过数据分析和挖掘技术，对评论进行统计和分析，为用户提供更多有价值的信息。例如，可以统计评论数量、点赞数量等指标，展示热门评论和热门话题，帮助用户发现和了解热点事件。另外，可以通过情感分析等技术，对评论进行情感极性和倾向性的分析，揭示用户的意见和情感倾向，为决策者提供参考。

难点一：大V发布微博，大事件下同时可达百万，千万用户接受到订阅消息，微博需要对此条信息进行计数，评论，点赞进行过滤，转到用户的各个平台。

难点二：数万用户同时访问，系统单点故障导致的雪崩问题，访问速度变慢，甚至单节点挂掉，导致惊群效应。

难点三：评论的套娃现象，以及实时回复展示问题，一条热评下会有数量回复，以及层级下的回复，且能实时回复并展示。

以上是个人觉得难点所在，平时的业务也可能出现类似现象，但用户量是个问题，达不到峰值访问，就测不出很多隐藏问题。

没有实战经验的高并发都是纸上谈兵！

当看过新浪架构师开发者大会实记后会有所感悟，文章就不大篇幅复制了，贴下链接。

https://blog.csdn.net/guodongbuding0423/article/details/83765669?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.channel_param

第一：数据拆分，异步推送

第二：静态内容CDN加速，允许单点失败，服务分解

第三：安全监控，Master/Slave

1、读扩散还是写扩散？

inbox: 收件箱，你收到的消息，即你所关注的人发布的消息。
outbox: 发件箱，你发布的消息。

写扩散(Push)

该方式为每个用户维护一个订阅列表，记录该用户订阅的消息索引（一般为消息ID、类型、发表时间等一些元数据）。每当用户发布消息时，都会去更新其follower的订阅列表。
优点：读很轻。初始化时仅需要读取自己的inbox即可。
缺点：写很重。每发布一个消息，会导致大量的写操作。
注：一般来说，用户发布消息，并不会更新所有followers的订阅列表，仅更新在线followers即可。

读扩散(Pull)

该方式为每个用户维护一个发送列表，记录该用户所有发表过的消息索引。
优点：写很轻，节省空间。用户每发布一条消息，仅需更新自己的outbox。
缺点：读操作很重，计算量大。假设你收听了1k用户，则初始化时，需要从1k个用户的outbox拉取消息，然后计算获得最新的n条消息。

混合模式(Push+Pull)

该方式既为读写扩散的结合，根据用户followers的数量来决定是读扩散还是写扩散。例如followers大于1k的，则使用读扩散，否则使用写扩散。

从目前现在网上的一些资料来看，Twitter是写扩散，腾讯微薄是读扩散，新浪微薄则是二者结合。

2、关于Cache

对于一个千万级甚至亿级用户的大型网站来说，合理使用Cache至关重要。

一个用户的核心数据由如下几个部分组成：inbox，outbox，关系链，消息内容。

• inbox：主要缓存消息索引，仅为在线用户缓存，从Timyang的PPT来看，新浪微博估计是使用redis的list或set实现。

• outbox：缓存一定数量（例如200）条最近发表的消息。

• 关系链：following相对于followers来说，缓存容易些，follower加载开销比较大，例如刘翔在腾讯微博的听众超过1600万。

• 消息内容：按内容年龄缓存；一般需要多份支持容灾；需要缓存xml，json，rss，atom等多种格式的缓存以供API使用。

以Twitter为例，其将Cache分为四类：Vector Cache，Row Cache，Page Cache，Fragment Cache，均使用memcached实现。其中：

• Vector Cache主要缓存用户的inbox以及outbox索引，其命中率高达99%；

• Row Cache主要缓存用户关系链数据，以及Tweets内容，命中率为95%；

• Fragment Cache缓存Tweet的xml，json，rss，atom四种格式数据，以供API使用，命中率为95%；

• Page Cache主要原来缓存那些高人气用户的个人主页，命中率仅为40%。

下图为TwitterCache架构图：

Twitter为啥要为API通道设置Fragment Cache和Page Cahce呢？其原因是Twitter的80%流量来自API。

下面以新浪微博介绍一下Cache流程：

消息发布流程：

1. 更新自己的outbox

2. 加载followers列表

3. 更新followers inbox

获取首页流程：

1. 检查inbox cache是否可用

2. 获取关注列表

3. 聚合内容，获得消息索引

4. 根据索引，返回最终聚合的消息内容

3、关于存储

目前Twitter和新浪的落地存储，都是使用MySQL。而腾讯微博则使用采用SSD+大文件存储（每次写操作都是append操作，写操作可以先用内存缓存，达到适当大小合并，尽量减少随机写）。其他细节因不清楚或不方便透露，不做细述。

4、关于洪峰处理。

一般用异步队列处理方式。消息队列产品有：Kestrel（twitter使用Scala实现），RabbitMQ（使用Erlang实现），MemcacheQ。

Twitter 09年时，用户的平均followers数量为126个。按照每秒400消息发布数算，那每秒就需要推送126*400=50400条消息出去。为了削峰，Twitter自己用Scala实现了一个分布式消息队列Kestrel，其代码仅为1200行，运行在3台机器上，其使用memcached协议，其Server之间无共享状态，且全内存。新浪使用的是MemcacheQ

转自：http://pananq.com/index.php/2011/05/21/%E5%BE%AE%E8%96%84%E5%90%8E%E5%8F%B0%E6%9E%B6%E6%9E%84%E6%B5%85%E6%9E%90/

目前只能搜索与个平台发布会以及内容分析，暂时未找到先关技术贴，通过架构分析了解下解决方案。

综上所述，设计和思考微博评论功能需要考虑用户需求、信息安全、功能附加性和数据分析等方面，从而提供一个具有良好用户体验和实用价值的评论功能。只有在综合考虑这些因素的基础上，才能设计出互联网用户满意的评论功能，提升平台的用户活跃度和竞争力。