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

一、计算性能预估

1.1 发评论

已知假设平均每天每人发 1 条微博，则微博每天的发送量约为 2.5 亿，平均每人看一条微博的人数为 100 次，则估算 100 人次中 1%的用户会发起评论，已知看微博的 QPS 约等于 1000K/S，发评论的 TPS 计算如下：

1000K/S（看微博的 QPS） * 1% = 10K/S

1.2 看评论

由于用户比较关注大 V 和明星的评论，及时自己没有发评论也会看别人的评论，已知每人看一条微博的人次为 100 次，假设 10%用户再看微博的同时会看微博评论，看评论的 QPS 计算如下：

1000K/S （看微博的 QPS） * 10% = 100K/S

二、高性能计算机构

2.1 发评论

2.1.1 业务特性分析

发评论是一个典型的写操作，因此不能用缓存，可以用负载均衡。

2.1.2 架构分析

由于用户量过亿，采用多级负载均衡架构，覆盖 DMS->F5->Nginx->网关的多级负载均衡。

2.1.3 架构设计

2.1.3.1 负载均衡算法选择

发评论的时候依赖微博信息，如果是微博数据是分片存储，可需要通过 Sharding-Jdbc 解决问题，这里可采用“轮询”或者“随机”算法。

2.1.3.2 业务服务器数量估算

发评论涉及几个关键的处理：内容审核（依赖审核系统）、数据写入存储（依赖存储系统）、数据写入缓存（依赖缓存系统），由于应用服务器采用微服务架构，目前基本都是基于 TomcatWeb 容器，Linux 的 Tomcat 允许每个进程可支持 1000 个线程数，因此按照一个服务每秒处理 500 来估算，要完成 10K/S 的 TPS，需要 20 台服务器，加上一定预留量，25 台服务器差不多。

注意：由于看微博评论的时效性没有看微博高，可以采用写缓冲，有效较低服务器数量

2.1.4 多级负载均衡架构

3.1 看评论

3.1.1 业务特性分析

看评论是一个典型的读操作，请求量较大，且评论发表出去删除概率较低，负载均衡架构和缓存架构都需要。

2.1.2 架构分析

1、由于用户量过亿，采用多级负载均衡架构，覆盖 DNS->F5->Nginx->网关的多级负载均衡。

2、由于看评论请求量非常大，需采用多级缓存架构，但是用户可以对评论进行删除，需考虑缓存主动刷新缓存，鉴于用户删除评论的情况较低，可采用 5 级缓存架构。

2.1.3 架构设计

2.1.3.1 负载均衡算法选择

所有用户都可以直接看评论，因此将请求发送给任意服务器都可以，这里选择“轮询”或者“随机”算法。

2.1.3.2 业务服务器数量估算

存在评论删除情况，CDN 缓存能偶承担 70%的用户流量，剩余的 30%流量进入服务器，则请求 QPS 为 100K/S * 30% = 30K/S,由于看评论的处理逻辑比较简单，主要是读缓存系统，因此假设单台业务服务器处理能力是 800/s，则机器数量为 35 台，按照 20%的预留量，最终机器数量为 45 台

2.1.4 多级负载均衡架构

三、热点事件高可用架构

待添加