架构训练营 模块五

【作业要求】

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

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

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

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

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

1 微博评论计算性能评估

假设发一条微博，平均 20 个人评论，之前发微博的性能估算 TPS 是 10K/s,则发微博的 TPS 估算为 10*20=200K/s

2 微博评论高性能计算架构

负载均衡设计

微博评论也是典型的写操作，并且性能要求比发微博更高，所以同样要采用多级负载均衡，评论依赖登录状态发的微博 id，一般都交给分布式缓存维护，而且没有强一致性要求，实时性要求，也没必要指定到某个服务器根据微博 id 进行 hash 去提升并发冲突的问题。采用轮询或随机的策略就可以了。

业务服务器估算

由于评论微博实时性要求不高，可以采用漏铜算法变种（写缓冲）+批量读写方式提升单台服务器写性能，由于是写，缓存用不上，单台单条 500，加入每次处理 200 比单条记录时间要长 10 倍，500*200/10=5000,每秒处理 200K40 台差不多够了。

这里我认为没必要单独拆分一个服务，可以和发微博放到一个部署单元里面（都是处理写请求），采用缓冲后，和发评论对服务器资源相差不大。主要瓶颈在于网络带宽和缓冲区长度，数据库层面可以慢慢写。

负载均衡架构图和发微博一样，这里就不画了。

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

评论热点问题比较常见，特别是明星事件。只要缓冲区足够大（漏铜算法变种），应用处理不是瓶颈，主要防止热点耗光所有对网络带宽，可以考虑在接入层限流。限制同一用户请求频率。

这种场景不涉及到一致性问题，排队没必要使用，熔断主要用于查询。可以采用降级手段提升评论微博使用的网络带宽。