如何设计业务高性能高可用计算架构 - 作业

作业要求

性能评估

• 用户量

DAU 2.24亿， MAU 5.11亿

• 写评论

写评论的数量基于发微博的数据量（平均每人每天发1条微博），写评论的时间也与发微博的时间基本重叠（高峰时段8：00-9:00， 12:00-13:00， 20:00-22:00），

假设每条微博有20条评论

TPS: 2.5亿 * 60% / (4*3600秒) *20 = 200k/s

• 看评论

假设每十条微博会被点开来看评论

25亿*

10条*

60% / (4*3600秒) = 100k/s

高性能计算架构设计

• 业务特性分析

写评论 

典型写操作，不能用缓存，需要用负载均衡

看评论 

典型读操作，评论发完不能修改，只能删除，请求量很大，需要多级缓存和多级负载均衡

• 架构分析

写评论 

应用多级负载均衡架构， DNS-> F5 -> Nignx->网管多级负载均衡

看评论 

应用多级负载均衡架构，

100k/s可以不使用CDN，

使用APP缓存 -> WEB容器缓存 -> 进程内缓存 -> 分布式缓存 多级缓存

• 架构设计

负载均衡 

评论微服务应设计成无服务的，请求给任意服务器都是等效的，使用

轮询

算法。

业务服务器估算

假设每台服务器处理500TPS写评论请求，需要写评论服务器200k/500=400台

假设每台服务器处理1000QPS看评论请求，需要写评论服务器100k/1000=100台

负载均衡架构图

缓存架构图

高可用计算架构设计

热点事件评论性能估算

业务特性分析

造成热点事件的微博自己只有1~2条，但是用户围观后会有很多转发，假设有10%的围观用户会在事件发生后60分钟内转发。

针对每条热点微博，在发布一个小时之内，会有1k ~ 100k 的评论数，写的评论可以容忍不是立即被看到

架构设计分析

写评论 

评论要保证尽量不丢失，同时做好系统限流，考虑用

漏桶算法

看评论 

热点微博1k ~ 100K 评论，采用Redis list来存储评论， 并在多个slave上保存副本

计算高可用架构图