More Related Content Similar to Feed服务架构-新浪微博新员工培训议题
Similar to Feed服务架构-新浪微博新员工培训议题 (20) Feed服务架构-新浪微博新员工培训议题6. 课前准备
• 参考资料:
• Brewer's CAP Theorem
•思考Feed架构中权衡点是什么?
• Jeff Dean:Numbers Everyone Should Know
•思考所设计的Feed架构需要多少服务器资源?
• memcached全面剖析
7. 课前准备
• 参考资料:相关系统设计方案
• Facebook :Facebook news-feed(QCon 2012)
• Twitter:Timelines-Twitter(Qcon 2012)
• Sina Weibo:《构建可扩展的微博架构》、《新浪微
博cache设计谈》
• Tencent Weibo:《腾讯微博架构介绍》
• RenRen:《人人网Feed系统结构浅析》
8. 课前准备
• 参考资料:服务器机型
• 前端机型:2 * intel E5-2620 6核、12G内存、1 *
300G SAS
• 缓存机型:2 * Intel E5- 2620 6核、128G内存、4 *
300G SAS
• 数据库机型(SAS):2 * Intel E5- 2603 4核、64G
内存、12 * 300G SAS
• 数据库机型(SSD):2 * Intel E5- 2609 4核、64G
内存、2 * 300G SSD
13. Feed服务架构
• 推拉模式探讨 – 推模式
• 写入消息
insert into feeds(user_id, author_id, feed_id)
select $user_id, follwer_id, $feed_id from followers
• 获取消息
select * from feeds where user_id = $user_id
user_id author_id feed_id
10001 20001 1111111111
10002 20001 1111111111
10003 20001 1111111111
14. Feed服务架构
• 推拉模式探讨 – 推模式
• 空间换时间:存储容量瓶颈?
• 粉丝越多推送量越大:姚晨5000万粉丝怎么推送?
• 延迟推送?延迟是否可接受?
• 变更通知成本高:加关注、取消关注、删除Feed?
• 系统复杂度变高?
15. Feed服务架构
• 推拉模式探讨 – 拉模式
• 写入消息
insert into feeds(user_id, feed_id)
values($user_id, $feed_id)
• 获取消息
select * from feeds where user_id in
(select following_id from following)
user_id feed_id
10001 1111111111
10002 222222222
17. Feed服务架构
• 推拉模式对比
推 拉
获取Feed 简单、高效 实时计算量大,与好友数量
相关
发表Feed 推送给所有粉丝 不推送
变更通知 加关注、取消关注、删除
Feed等都需要变更
不需要
好友多、粉丝少 适合 不适合
好友少、粉丝多 不适合 适合
好友多、粉丝多 ? ?
18. Feed服务架构
• 请求量统计
• 拉模式:
• Read:请求量(1w)* 好友数(100) = 100w
• Write:写入量(1000)
• 推模式:
• Read:请求量(1w)
• Write:写入量(1000) * 粉丝数(100?)= 10w
需要多少服务器资源?
22. Feed服务架构
• Memcached
Free & open source, high-performance, distributed
memory object caching system, generic in nature, but
intended for use in speeding up dynamic web
applications by alleviating database load.
29. • Scale Up
– 硬件升级(Cpu、磁盘和内存等)
– 同时开始准备扩展mysql及其做sql优化
微博数据库发展历程
31. • 数据库Scalability
– Scale Up(集中式)
• 简单快速实现,不需要改造程序
• 较低运维成本,节省机架和能耗成本
• 高端服务器
• 将会碰到瓶颈点
– Scale Out(分布式-Sharding)
• 需要程序和数据库设计层面支持
• 较高运维成本,占用更多机架和耗费更多能耗
• 普通服务器
• 可持续性的水平扩展方式
– Scale Up & Scale Out
微博数据库发展历程
32. • 扩展前准备工作
– select t.id, c.content from timeline t
left join content c where t.uid=?
– 这样的sql语句假定content和timeline在同一
数据库中,并且是单表结构。
• 如果content和timeline拆分到不同数据库?
• 如果content和timeline要分库和分表?
微博数据库发展历程
33. • 数据库只是存储
– 在数据库层面没有业务逻辑
– 业务逻辑在应用端处理
– sql语句应该是
• select id from timeline where uid =?
• select id,content from content where id in (?)
微博数据库发展历程
44. • 一些注意事项
– 拆分为足够多的逻辑库(如32)
• 方便后续扩容为物理库
– 避免更改字段
• 百亿级数据量的库表更改字段会是怎么样?
– 节省存储空间
• 选择合适的数据类型,能选tinyint就不选int…
• 合理的压缩存储,如pb替换json等
微博数据库发展历程
47. • 一级索引按月拆分
– 通过二级索引获取对应月份
– 通过一级索引获取具体数据
timeline_si
uid stat_date count
100001 2013-08-01 2
100001 2013-07-01 2
100001 2013-06-01 1
…… …… ……
timeline_1308
uid id
100001 555555
100001 444444
…… ……
timeline_1307
uid id
100001 333333
100001 222222
…… ……
timeline_1306
uid id
100001 111111
…… ……
微博数据库发展历程
48. • Sharding小结
– 垂直拆分
• 实现简单
• 扩展能力有限,并且强关联的业务不容易再细拆
– 读写分离
• 主要缓解读压力,读节点可扩展
• 存在主从同步问题,最终体现在一致性问题上
– 水平拆分
• 扩展性强,但是需要预先规划好分库分表策略
• 实现相对比较复杂
微博数据库发展历程
51. • 数据库发展历程小结
– 扩展性:Scale Up -> Scale Out -> Scale Up
– 系统设计:简单 -> 复杂 -> 简单
– 水平扩展:垂直拆分 -> 读写分离 ->
水平拆分 ->冷热分离
– 权衡出最合适的方案
微博数据库发展历程
65. 课前准备
• 课后作业 – 功能说明
• 发布Feed
• 查看关注的好友Feed列表
• 实现上需要包括数据库和缓存相关的,关系列表可以
是程序内部硬编码
• 相关业务数字:
每秒万级的调用量,每秒新增千级数据,现有百亿级数
据,每个用户平均关注好友数为100,要求平均响应时间
控制在30ms以内
66. 课前准备
• 课后作业 – 必须实现
• 推拉实现(至少选其一)
• 缓存数据结构设计及其容量预估
• 数据库结构设计
• 性能相关评估(内存占用、QPS等)
• 多线程、异步编程模型
67. 课前准备
• 课后作业 – 加分项
• 数据库分库分表
• 分布式缓存
• 缓存高可用设计
• 压缩存储(Protocol Buffer、ByteBuffer等)
• 比较JVM参数在默认情况下与参考资料情况下差异
Editor's Notes 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 65 66 67