模块五作业

微博评论的高性能高可用计算架构

一、计算性能预估

假设微博每天的发送量为 2.5 亿条，每条微博有 100 人浏览，则每天总共有：

$2.5亿\ast 100=250亿$

大部分人看微博集中在早上 8 到 9 点，中午 12 到 13 点，晚上 20 到 22 点，假设这几个时间段发微博总量占比为 60%，则这 4 个小时的平均看微博的 TPS 计算如下:

$250亿\ast 0.6/(4\ast 3600s)=1000K/s$

假设看微博的人当中有 10%的人发布评论，TPS 为

$1000K/s\ast 0.1=100K/s$

假设 1 次微博评论查询返回 10 条评论，假设查询评论的 QPS 近似浏览微博的 QPS，为$1000K/s$

二、非热点事件时的高性能计算架构

发布微博评论

发布微博评论是写操作，可以用漏桶做写缓冲，慢慢异步处理，因为评论不必立刻看到。选择 4 级负载均衡，评论微博需要登录状态，同发微博一致保持在分布式缓存中，可以将请求发送到任意评论微博服务，选择轮询或随机算法。

按照每台服务器每秒处理 500 笔来估算，完成 100K/s 需要 200 台服务器，假设写缓冲可以缓冲 50%请求，则需要 100 台服务器，加上 20%预留量，最终需要 120 台服务器。

查看微博评论

查看微博评论是一个典型的读场景，由于评论发了后不能修改，因此非常适合用缓存架构。同时由于请求量很大，使用 4 级负载均衡。假设 CDN 能够承载 90%的用户流量，那么剩下 10%的查看评论的请求进入系统，则请求 QPS 为

$1000K/s\ast 0.1=100K/s$

由于查看评论的处理逻辑比较简单，按每台服务器每秒 1000 估算，完成 1000K/s 的 TPS，需要 100 台服务器，加上 20%预留量，最终需要 120 台服务器。

是否要拆分独立的服务

评论功能单独出一个服务，非主要的功能拆出来避免影响主要业务发展，如性能、查问题、维护等影响。

三、热点事件时的高可用计算架构

发布微博评论

热点事件的微博评论量很难预估，只能预防。可以用漏桶算法做限流，先把微博评论放进消息队列，把消息队列长度设置成很大，后台异步处理。如果微博评论请求实在太多了，可以自动熔断微博评论，以保住核心业务高可用。

查看微博评论

热点事件发生后，绝大部分请求都会落在导致热点事件发生的那一条微博上的评论，可以使用多副本缓存。