[架构实战营] 模块五
微博写微博架构设计
背景
考虑到微博是一个看得多发的少的业务,假设平均每天每人发 1 条微博(只考虑文字微博),则微博每天的发送量约为 2.5 亿条。
大部分的人发微博集中在早上 8:00~9:00 点,中午 12:00~13:00,晚上 20:00~22:00,假设这几个时间段发微博总量占比为 60%,则这 4 个小时的平均发微博的 TPS 计算如下:
2.5 亿 * 60% / (4 * 3600) ≈ 10 K/s。
假设 每天 2.5 亿条微博,每条微博有 10 个人评价,基于热点的 4 个小时发微博的 TPS,计算如下
2.5 亿乘以 60%乘以 10/(4 * 3600 ) ≈ 100K
业务特性分析
评论微博 是一个写操作,可以用负载均衡
评论的微博可以丢失,或者延时查看
架构分析
用户量过亿,5 级负载均衡架构 DNS>F5>LVS>Nginx>网关
架构设计
负载均衡算法选择
评论微博针对的是某一条微博,采用 Hash 一致复杂均衡算法
数据高可用
可以先存储在 Redis,再同步到 Mysql
业务服务数量估算
评论微博 依赖:内容审核(200ms)、Redis(100ms),完成 100K/s 的 TPS 需要 100 台服务器。
微服务拆分
非热点事件时,不需要与发微博服务分开
热点事件时,需要与发微博服务分开
因此需要拆分微服务
热点事件处理
针对大 V,做多个数据缓存分片
每个数据缓存分片数据可能不一致,通过 Mysql 实现最终一致性
负载均衡架构图
版权声明: 本文为 InfoQ 作者【Vincent】的原创文章。
原文链接:【http://xie.infoq.cn/article/d52377db17e7703a7b9f72832】。未经作者许可,禁止转载。
评论