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

一、计算性能评估

发评论

微博评论属于看多写少业务，假设每条微博评论 10 条，则微博每天的评论数为 25 亿条大多数发布评论和发布微博集中在相同时段，假设这个时段评论微博总量占比 60%，则这 4 小时的平均 TPS 为：25亿*60%/(4*3600)=100K/s

看评论

用户查看微博的同时也会分页加载评论列表，而且大部分人只会看首页评论，所以查看评论和查看微博的人数是接近的。假设平均一条微博的查看人数为 100 次，则平均一个微博评论的观看人数也为 100 次，有 10%的人会下拉加载评论，看微博 QPS 为 1000K/s,则查看评论的次数为:2.5 亿**100+100*10%）=275 亿对应的 QPS 为275亿*60%/(4*3600)=1100K/s

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

发评论

业务特性分析

发评论属于写操作，不能使用缓存架构，可以使用负载均衡。

架构分析

用户量过亿，应该使用多级负载均衡架构，覆盖 DNS->FS->Nginx-.网关的多级负载均衡架构

架构设计

1. 负载均衡算法选择发评论可以发送给任意服务器处理，所以负载均衡采用轮询或者随机

2. 业务服务器数量估算按照每台服务器每秒处理 500 请求，需要 200 台服务器，按照 20%预留量，需要 250 台服务器

看评论

业务特性分析

微博评论是分页加载的，用户查看微博内容时就会同步加载评论列表，而且评论发表后只能删除不能编辑，可以使用缓存架构，同时请求量过大，需要考虑负载均衡用户查看评论时，大部分只会看首页评论，只有少部分人会下拉查看评论，评论用列表进行缓存，只需要缓存前几页评论数据就可以满足大部分用户的查看需求

架构分析

用户数据量过亿，使用多级负载均衡架构请求量 275 亿，使用多级缓存架构，使用 CDN 缓存时，CDN 只缓存 评论的前 10 页数据(单页 20 条)，

架构设计

1. 负载均衡算法选择看评论可以发送给任意服务器处理，所以负载均衡采用轮询或者随机

2. 业务服务器数量估算 CDN 承载 90%的用户流量，剩余 10%的读请求进入系统，则 QPS 为 1100K/s*10% = 110K/s, 评论数据主要是通过读缓存系统，没有复杂的业务操作，单台服务器每秒 1000 请求，需要 110 台服务器，按照 20%预留量，需要 130 台服务器是否需要拆分为独立服务，需要拆分为独立服务，由于看评论的数量远大于发评论,而且用户发布评论时不希望看到发布失败的，为避免看评论业务影响到发评论，所以看评论和发评论需要拆分为独立服务

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

对于热点事件发评论，可以采用消息队列异步处理发布的评论，保证用户的评论不丢失对于热点事件看评论，热点数据一般是由明星大 V 导致，在原有缓存架构的基础上可以对明星大 V 的微博评论采用数据多副本