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

计算性能评估

发评论

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

看评论

用户查看微博的同时也会分页加载评论列表，而且大部分人只会看首页评论，所以查看评论和查看微博的人数是接近的。假设平均一条微博的查看人数为100次，则平均一个微博评论的观看人数也为100次，有10%的人会下拉加载评论，看微博QPS为 1000K/s,则查看评论的次数为:

对应的QPS为

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

发评论

业务特性分析

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

架构分析

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

架构设计

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

按照每台服务器每秒处理500请求，需要200台服务器，按照20%预留量，需要250台服务器

看评论

业务特性分析

微博评论是分页加载的，用户查看微博内容时就会同步加载评论列表，而且评论发表后只能删除不能编辑，可以使用缓存架构，同时请求量过大，需要考虑负载均衡

用户查看评论时，大部分只会看首页评论，只有少部分人会下拉查看评论，评论用列表进行缓存，只需要缓存前几页评论数据就可以满足大部分用户的查看需求

架构分析

用户数据量过亿，使用多级负载均衡架构

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

架构设计

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

CDN承载90%的用户流量，剩余10%的读请求进入系统，则QPS为 1100K/s*10% = 110K/s, 评论数据主要是通过读缓存系统，没有复杂的业务操作，单台服务器每秒1000请求，需要110台服务器，按照20%预留量，需要130台服务器

是否需要拆分为独立服务，需要拆分为独立服务，由于看评论的数量远大于发评论,而且用户发布评论时不希望看到发布失败的，为避免看评论业务影响到发评论，所以看评论和发评论需要拆分为独立服务

热点事件时的高可用架构

对于热点事件发评论，可以采用消息队列异步处理发布的评论，保证用户的评论不丢失

对于热点事件看评论，热点数据一般是由明星大V导致，在原有缓存架构的基础上可以对明星大V的微博评论采用数据多副本