Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

新浪微博Feed服务架构

7.021 Aufrufe

Veröffentlicht am

在厦门爱特咖啡分享的新浪微博Feed服务架构

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

新浪微博Feed服务架构

  1. 1. 新浪微博 洪小军  @XiaoJunHong   厦门爱特咖啡  新浪微博Feed服务架构 
  2. 2. 新浪微博Feed服务架构 •  个人简介 •  洪小军 @XiaoJunHong •  2009年初加入飞信,互联网业务架构 •  2011年初加入新浪微博,平台架构
  3. 3. 新浪微博Feed服务架构 •  讨论范围 •  业务层面: •  内容、关系、 •  用户、计数... •  设计层面: •  缓存、数据库、 •  消息系统...
  4. 4. 新浪微博Feed服务架构 •  讨论大纲 •  设计原则 •  设计模式 •  缓存设计 •  数据库设计
  5. 5. 新浪微博Feed服务架构 •  讨论大纲 Ø 设计原则 •  设计模式 •  缓存设计 •  数据库设计
  6. 6. 新浪微博Feed服务架构 •  CAP原则
  7. 7. 新浪微博Feed服务架构 •  Feed设计原则 •  选择可扩展性和高可用性 •  可扩展性:支撑业务的快速增长 •  高可用性:保证系统处于稳定状态 •  妥协一致性 •  最终一致性:消息最终一致
  8. 8. 新浪微博Feed服务架构 •  演化方向 – 前期 •  快速搭建并推进上线 Mysql Web
  9. 9. 新浪微博Feed服务架构 •  演化方向 – 中期 •  可扩展性 •  Scale Up:硬件升级、性能优化 •  Scale Out:分布式 •  路线图 •  Scale Up -> Scale Out -> Scale Up
  10. 10. 新浪微博Feed服务架构 •  演化方向 – 中后期 •  高可用性 •  Failover:避免单点故障 •  快速失败策略:避免系统hang住 •  降级策略:保证核心功能可用 •  隔离性:避免依赖影响
  11. 11. 新浪微博Feed服务架构 •  讨论大纲 •  设计原则 Ø 设计模式 •  缓存设计 •  数据库设计
  12. 12. 新浪微博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  
  13. 13. 新浪微博Feed服务架构 •  推拉模式 – 推模式 •  空间换时间:存储容量瓶颈? •  粉丝越多推送量越大:姚晨5000万粉丝怎么推送 •  延迟推送?延迟是否可接受? •  变更通知成本高:加关注、取消关注、删除 Feed? •  系统复杂度变高?
  14. 14. 新浪微博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  
  15. 15. 新浪微博Feed服务架构 •  推拉模式 – 拉模式 •  时间换空间 •  动态聚合怎么保证响应时间? •  拉取量太大,带宽容易成为瓶颈 •  并行获取?存储靠近计算?
  16. 16. 新浪微博Feed服务架构 •  推拉模式对比 推 拉 获取Feed 简单、高效 实时计算量大,与好友数量 相关 发表Feed 推送给所有粉丝 不推送 变更通知 加关注、取消关注、删除 Feed等都需要变更 不需要 好友多、粉丝少 适合 不适合 好友少、粉丝多 不适合 适合 好友多、粉丝多 ? ?
  17. 17. 新浪微博Feed服务架构 •  推拉结合? •  边界设置 •  在线状态? •  粉丝数? •  ……
  18. 18. 新浪微博Feed服务架构 •  微博的实践 – 推拉结合 •  主体采用拉模式 •  存储靠近计算 •  按时间归档热数据 •  网络部署结构优化 •  并行获取 •  高效聚合算法 •  …… •  部分高级功能采用推模式
  19. 19. 新浪微博Feed服务架构 •  讨论大纲 •  设计原则 •  设计模式 Ø 缓存设计 •  数据库设计
  20. 20. 新浪微博Feed服务架构 •  支撑高并发读取 •  每秒对资源百万级的请求 •  需要保证较低的响应时间 •  假设在内存基础上的架构 •  memory cache •  memory storage
  21. 21. 新浪微博Feed服务架构
  22. 22. 新浪微博Feed服务架构
  23. 23. 新浪微博Feed服务架构 •  集中式缓存 Mysql Web Memcached
  24. 24. 新浪微博Feed服务架构 •  问题出现 •  Mysql出现性能瓶颈,读取压力过大 •  缓存命中率较低,大量穿透到后端 •  缓存容量成为瓶颈 •  Memcached出现慢查询情况 •  单机吞吐量有限,读压力超过可支撑最大限度 •  CPU和网络带宽成为瓶颈
  25. 25. 新浪微博Feed服务架构 •  压缩存储 •  一定程度减缓容量瓶颈问题 o Protocol Buffer o Byte Buffer o QuickLz
  26. 26. 新浪微博Feed服务架构 •  分布式缓存 Mysql Web MemcachedMemcached ......
  27. 27. 新浪微博Feed服务架构 •  问题出现 •  数据库压力持续过大 •  某台缓存机器硬件或网络故障 •  故障期间缓存命中率持续保持在低位水平不见涨 •  单点故障
  28. 28. 新浪微博Feed服务架构 •  一致性hash
  29. 29. 新浪微博Feed服务架构 •  一致性hash – 加节点
  30. 30. 新浪微博Feed服务架构 •  一致性hash – 减节点
  31. 31. 新浪微博Feed服务架构 •  一致性hash – 虚拟节点
  32. 32. 新浪微博Feed服务架构 •  问题出现 •  数据库瞬间访问量暴增,出现雪崩现象 •  某台缓存机器硬件或网络故障 •  节点故障瞬间穿透到数据库的请求超过可支撑最大负荷 •  单点故障
  33. 33. 新浪微博Feed服务架构 •  Master / Slave 策略 Mysql Web Memcached Master Cluster Memcached Slave Cluster
  34. 34. 新浪微博Feed服务架构 •  Master/Slave可用性和成本的权衡 •  同城IDC互为Master/Slave •  独立IDC Slave使用成本更低的SSD存储
  35. 35. 新浪微博Feed服务架构 •  问题出现 •  出现大量的Memcached慢查询 •  缓存服务器带宽成为瓶颈 •  读取量随着业务的发展在快速增长 •  期望有线性扩容的方案
  36. 36. 新浪微博Feed服务架构 •  Line Cache     Slave   node1   node2   node3       Master   node1   node2   node3       Line  cache   node1   node2   node3   Client   (get)  
  37. 37. 新浪微博Feed服务架构 •  问题出现 •  出现大量的Memcached慢查询 •  缓存服务器hang住 •  所有请求延迟N秒
  38. 38. 新浪微博Feed服务架构 •  快速失败策略 •  规划资源的SLA值 •  设置合适的超时时间和合理的重试次数 •  满足不了SLA要求自动摘除以达到快速失败目的
  39. 39. 新浪微博Feed服务架构 •  打造高可用缓存 – 容量规划 •  请求量 •  命中率 •  预热、防止雪崩 •  带宽 •  网卡、交换机 •  存储容量 •  预估存储大小 •  过期策略、剔除率 •  连接数
  40. 40. 新浪微博Feed服务架构 •  打造高可用缓存 – 容量规划 •  每季度至少一次例行性评估 •  重大活动前容量评估 •  系统变更时评估容量 •  监控系统黄色预警 •  日常30%以上冗余
  41. 41. 新浪微博Feed服务架构 •  缓存设计小结 •  扩展性 •  集中式 •  分布式 •  Line Cache •  可用性 •  Failover:一致性hash、master/slave •  快速失败策略 •  容量规划 •  设计上核心功能只要缓存可用系统就基本可用
  42. 42. 新浪微博Feed服务架构 •  缓存设计小结 •  核心业务缓存命中率达到99.9%以上 •  核心系统可在一段时间内仅运行于缓存之上 •  容量规划尤其关键
  43. 43. 新浪微博Feed服务架构 •  讨论大纲 •  设计原则 •  设计模式 •  缓存设计 Ø 数据库设计
  44. 44. 新浪微博Feed服务架构 •  第一版本Feed快速搭建完成并上线 Mysql Web content   id   long   content   varchar   0meline   uid   long   id   long  
  45. 45. 新浪微博Feed服务架构 •  问题出现 •  读请求很慢,大量mysql慢查询和超时情况 •  前端和缓存层面也都做了扩容,但是问题依旧
  46. 46. 新浪微博Feed服务架构 •  优化sql语句 •  使用最简单的sql语句 •  避免join、子查询、游标等复杂操作 •  只返回需要的数据 •  合理的使用索引 •  减少随机读,提高性能 •  避免分布式事务 •  BASE原则
  47. 47. 新浪微博Feed服务架构 •  数据库就只是作为存储 •  在数据库层面没有任何逻辑 •  业务逻辑应该在应用端处理 •  类似的sql语句 •  select id from timeline where uid =? •  select id,content from content where id in (?)
  48. 48. 新浪微博Feed服务架构 •  问题出现 •  Mysql读写再次出现瓶颈 •  出现瓶颈时各业务互相影响
  49. 49. 新浪微博Feed服务架构 •  垂直拆分 •  按业务拆分到不同的端口和数据库中 content Web timeline
  50. 50. 新浪微博Feed服务架构 •  问题出现 •  Mysql读成为瓶颈
  51. 51. 新浪微博Feed服务架构 •  读写分离 master Web slave Read Replication Write
  52. 52. 新浪微博Feed服务架构 •  问题出现 •  Mysql读再次成为瓶颈
  53. 53. 新浪微博Feed服务架构 •  添加slave节点 master Web Write slave slave Replication Read
  54. 54. 新浪微博Feed服务架构 •  问题出现 •  Mysql写成为瓶颈
  55. 55. 新浪微博Feed服务架构 •  水平拆分 Web master slave master slave master slave
  56. 56. 新浪微博Feed服务架构 •  水平拆分 •  分库 •  物理库和逻辑库 •  分表 •  Hash分布和时间分布
  57. 57. 新浪微博Feed服务架构 •  一些注意事项 •  拆分为足够多的逻辑库 •  方便后续扩容为物理库 •  避免更改字段 •  亿级数据量的库表更改字段会是怎么样? •  节省存储空间 •  选择合适的数据类型,能选tinyint就不选int… •  合理的压缩存储,如pb替换json等
  58. 58. 新浪微博Feed服务架构 •  问题出现 •  Mysql出现慢查询 •  更多是发生在查看历史发博量非常大的用户 的微博列表的时候
  59. 59. 新浪微博Feed服务架构 •  一级索引按月拆分 •  增加二级索引表 0meline   uid   long   id   long   0meline_si   uid   long   stat_date   date   count   int  
  60. 60. 新浪微博Feed服务架构 •  一级索引按月拆分 •  通过二级索引获取对应月份   •  通过一级索引获取具体数据 0meline_si   uid   stat_date   count   100001   2013-­‐08-­‐01   2   100001   2013-­‐07-­‐01   2   100001   2013-­‐06-­‐01   1   ……   ……   ……   0meline_1308   uid   id   100001   555555   100001   444444   ……   ……   0meline_1307   uid   id   100001   333333   100001   222222   ……   ……   0meline_1306   uid   id   100001   111111   ……   ……  
  61. 61. 新浪微博Feed服务架构 •  Sharding小结 •  垂直拆分   •  实现简单   •  扩展能力有限,并且强关联的业务不容易再细拆   •  读写分离   •  主要缓解读压力,读节点可扩展   •  存在主从同步问题,最终体现在一致性问题上   •  水平拆分 •  扩展性强,但是需要预先规划好分库分表策略   •  实现相对比较复杂
  62. 62. 新浪微博Feed服务架构 •  问题出现 •  为了抗更大的读写压力,采用更多更好的设备 (ssd等),但是每次扩容都需要扩容整个数 据库(包括所有历史数据),服务器成本非常 高
  63. 63. 新浪微博Feed服务架构 •  按年归档-冷热数据分离 Web 2012年 master slave slave slave 2011年 master slave slave 2010年 master slave 2009年 master slave slave slave slave slave
  64. 64. 新浪微博Feed服务架构 •  数据库发展历程小结 •  扩展性:Scale  Up  -­‐>  Scale  Out  -­‐>  Scale  Up   •  系统设计:简单  -­‐>  复杂  -­‐>  简单   – 水平扩展:垂直拆分  -­‐>  读写分离  -­‐>                                                      水平拆分  -­‐>冷热分离  
  65. 65. 谢谢

×