微博评论高性能高可用计算架构
设计思路
调查微博最新报告，找到与微博评论相关的数据；
调查微博评论使用习惯，根据经验值对微博评论的性能指标进行估算；
根据得到的性能指标，按照热点、非热点事件进行高性能高可用设计。
结合模块五多级缓存架构，进行裁剪，同时复用微博现有架构
热点事件，结合模块五接口高可用方案中的限流、排队进行写评论高可用设计
1 微博评论计算性能评估
1.1 用户量与评论量估计
1.1.1 用户量估计
2021 年，日活跃用户数达 2.48 亿。
1.1.2 评论量估计
上班路上：8:00 ~ 10:00
午休：11:30 ~ 12:30
晚饭前：16:30 ~ 18:00
睡前：21:30 ~ 23:00
评论发生时间每天 6 小时。
午时（12:00）和亥时（22:00）是不容错过的黄金冲浪时段， 90、00 后互动量最高。
1.2 用户行为建模
1.2.1 看微博评论
看微博与看微博评论的场景类似，但看评论的计算性能要小于看微博。
一些人不会看评论，仅看微博正文
通常只看点赞数最多的评论，不会从头看到尾
一些评论不会显示，会被折叠或屏蔽
1.2.2 发微博评论
发微博评论按照非热点事件和热点事件来进行区分讨论。
按照 2/8 定律估算，20%的人发评论，假设平均每人每周发 5 条评论。
1.3 性能需求计算
1.3.1 非热点事件
看评论性能分析
与看微博性能分析类似，CDN 承载后，约 100K/s。
写评论性能分析
日活用户 2.48 亿，假设 20% 用户每周发 5 条评论。
平均到每天的 6 小时。
非热门话题微博评论 QPS 约 1600/s。
1.3.2 热点事件
以2022年2月热点事件为例，
单个热搜话题，日讨论数量为 53 万条。
按照 80 万/天，假设每天有 50 个热搜话题。
热门话题微博评论 QPS 2K/s。
热点+粉丝打榜
考虑到有粉丝团打榜的情况。粗暴的算法，要在热门话题基础上乘以 20。
热门话题微博评论（粉丝打榜） QPS 2K/s * 20 = 40K/s。
2 微博评论架构设计
任务分配：复用看微博架构的双机房、三机房。
任务分解：看微博评论与写微博评论拆分到不同的服务。
2.1 看微博评论架构设计
查看微博评论架构可复用看微博多级缓存架构。
2.2 写微博评论架构
2.2.1 非热点事件高性能设计
设计问题
非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务？
答：根据估算的非热门话题微博评论 QPS 1600/s 不需要特别的高性能设计，似乎可以不用拆分。
不拆分的理由：不增加额外的复杂性。
拆分的理由：由于热门话题的预测性难以评估，拆分后可以不影响微博评论的整体可用性。
思路：日常情况下不做拆分，当（预测/检测）出现热门话题后，将该话题作为独立（热门话题）服务进行管理。例如，“调度模块”采用令牌桶，监控写评论流量。当符合热门话题条件时，启动独立的写评论服务。这里可手动或自动。
2.2.2 热点事件高可用设计
热门话题微博评论（粉丝打榜） QPS 40K/s。
设计问题
热点事件时的高可用计算架构。
答：热点事件写微博评论高可用分析，支持正常用户写入，对恶意打榜（水军）进行检测与限流。
正常用户写入，通过队列缓冲提供写评论高可用。
调度模块通过 令牌桶+滑动窗口 监测实时的写评论流量检测。
对监测到的恶意打榜流量，采用接服务器接口限流方式保证高可用。
令牌桶的设计，还考虑到了对下游系统的压力控制。例如评论审核等。
当流量超过缓冲大小时，可采取自动或手动扩容方式实现高可用。
即增加服务器：独立服务+队列（缓冲）扩容。
例如，某明星结婚，微博程序员现场扩容机器支持热门话题。
版权声明: 本文为 InfoQ 作者【唐尤华】的原创文章。
原文链接:【http://xie.infoq.cn/article/693cdc15d4c4ee63f679b4d67】。文章转载请联系作者。
还未添加个人签名 2018.03.27 加入
还未添加个人简介
评论