架构实战训练营模块五作业

设计微博系统中”微博评论“的高性能高可用计算架构。

【作业要求】

基于模块 5 第 6 课的微博实战案例，分析“微博评论”这个核心场景的业务特性，然后设计其高性能高可用

计算架构，包括但不限于如下内容：

1.计算性能预估（不需要考虑存储性能）；

2.非热点事件时的高性能计算架构，需要考虑是否要拆分独立的服务；

3.热点事件时的高可用计算架构。

微博用户行为建模和性能估算

【用户量】

1. 2020.9 月月活 5.11 亿，日活 2.24 亿。

【评论微博】

假设平均每人每天写 1 条评论，那么每天的评论数量大概是 2.5 亿条。大部分人的评论时间是早上 8：00 ~ 9：00 、中午 12：00 ~ 13：00、晚上 20：00 ~ 22：00，假设这段时间的评论数量占到微博总评论数量的 60% 那么，这 4 个小时平均发微博评论的 TPS 计算如下：

25 亿 * 60% / （ 4 / 3600） ≈ 10 K / s

微博发评论高性能架构设计

【业务特性分析】

如果是热点事件的微博评论，那有可能自己写的评论一下子就被别人的顶过去了。发表评论的服务应该独立部署，因为平时刷微博读取的数据和写微博发布的数据与发表评论不相关，只有在刷微博的时候需要获取微博的评论总数，点赞总数，转发总数。因此，微博列表对于这些总数的实时性要求并不高，可以采用异步更新的方式。

【架构分析】

1. 负载均衡算法选择

写服务使用简单的负载均衡算法优先，使用轮询或者随机算法即可。

读服务使用按评论的微博 id 做 hash 负载均衡算法。这样可以启用服务器本地缓存的同时，

避免出现本地缓存不一致的情况。

1. 业务服务器数量估算

发送微博评论设计几个关键处理：写入消息队列, 内容审核（依赖审核系统）、数据定时批量写入 Hbase（依赖 Hbase）、数据写入 redis（依赖 redis）（缓存只需要缓存近 3 天的微博的评论，每条微博缓存前 50 条评论即可）。读取微博评论，如果是总数就是读取缓存，如果是 3 天前的或者 50 条以后的就读数据库。由于写评论的压力相对于读评论有缓存支撑的压力更大。建议读写服务分离，需要时候可以即时扩容写服务。

平日保持写服务 40 台服务器,读服务 10 台服务器即可。假设写服务单台性能为 250tps，读服务 1000qps

【非热点事件高性能计算架构】

【热点事件高性能计算架构】