Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

分布式缓存与队列

1,791 views

Published on

新浪微博新员工培训及其技术交流活动topic,主要阐述从中小系统发展到大型系统的技术演化过程

Published in: Technology, Business

分布式缓存与队列

  1. 1. 分布式缓存与队列 新浪微博 洪小军 @XiaoJunHong 2012.8.16
  2. 2. 缓存和队列概述 雪崩 高可用 单点故障 Ram Is The New Disk 异步化处理 横向扩展 对于一个大流量在线系统,你是否听过:
  3. 3. 缓存和队列概述 • 实现一个简化版微博系统 – 发表微博、查看用户发的微博列表 – 评论微博、查看微博评论列表和评论数 – 加关注、查看关注列表
  4. 4. 缓存和队列概述 • 快速搭建完成并上线 Mysql Web
  5. 5. 缓存和队列概述 但是随着用户和流量的不断增长,开始出现 各种各样的问题……
  6. 6. 缓存和队列概述 • 从四条主线来说明怎么一步步解决问题 o 查看微博列表数据-memcached o 发布微博和评论-memcacheq o 加关注和查看关注列表-redis、memcached o 加和查看微博计数-redis、handlersocket
  7. 7. Feed Timeline Feed Timeline Mysql Web
  8. 8. Feed Timeline • 问题出现 – 读请求很慢,大量mysql慢查询和超时情况 – mysql每秒可支撑千级别qps
  9. 9. Feed Timeline • 加本地缓存 Mysql Web In-Process Cache
  10. 10. Feed Timeline • 问题出现 – 数据太多本地缓存放不下 – 影响JVM GC,进而影响系统整体性能 – 多个Web时存在缓存同步问题
  11. 11. Feed Timeline • 集中式缓存 Mysql Web Memcached
  12. 12. 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.
  13. 13. Memcached简介 • Key-Value • Simple Protocol – set/get – incr/decr – stats • Lazy Expiration • LRU • Not Support Traversal • Access – Telnet – printf 'statsrn' | nc ip port – Java client
  14. 14. Memcached简介 The primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixedsize memory chunks coming from a few predetermined size classes.
  15. 15. Feed Timeline • Memcached使用示例 – 单条微博数据结构 • key:status id • value:content protocol buffer object(why not json?) – 用户微博列表数据结构 • key:user id • value:status id array(bytes,why not java long[]?) – nio byte buffer convert long[] to byte[]
  16. 16. Feed Timeline • Memcached使用示例 – 操作命令 • set <key> <flags> <exptime> <bytes> <data block> • get <key> • delete <key> – 尽量减少value大小,节省存储和带宽成本 • memcached客户端quickLZ压缩 • 从业务层面做相应压缩
  17. 17. Feed Timeline • 问题出现 – mysql再次出现性能瓶颈,读取压力过大 • 单台mc容量有限,缓存数据大量过期 • 缓存命中率下降,进而导致大量请求穿透到mysql – memcached出现慢查询情况 • mc单机吞吐量有限,读压力超过可支撑最大限度 • 带宽成为瓶颈
  18. 18. Feed Timeline • 分布式memcached Mysql Web MemcachedMemcached ......
  19. 19. 分布式概述 • 实现分布式的方式 – 客户端实现分布式 • memcached、memcacheq、redis、mysql… – 服务端实现分布式 • cassandra、dynamo、hbase…
  20. 20. 分布式概述 • 客户端实现分布式
  21. 21. 分布式概述 • 客户端实现分布式常用算法 – 取模求余算法 – 一致性hash算法
  22. 22. 分布式概述 • 取模求余算法 node1 node2 node3 hash(id) % 3 (0) (1) (2)
  23. 23. 分布式概述 • 取模求余算法-加节点 node1 node2 node3 hash(id) % 4 (0) (1) (2) node4 (3)
  24. 24. 分布式概述 • 一致性哈稀算法
  25. 25. 分布式概述 • 一致性哈稀算法-加节点
  26. 26. 分布式概述 • 客户端实现分布式常用算法 – 取模求余算法 • 优点:算法简单 • 缺点:加减节点时震荡厉害,命中率下降厉害 – 一致性hash算法 • 优点:加减节点时震荡较小,保持较高命中率 • 缺点:负载不够均衡,出现热节点 注意点:当存在单点时,优先考虑一致性hash
  27. 27. Feed Timeline • 问题出现 – 某memcached crash,读写此mc报错 • 可能是硬件或其它原因导致crash • 典型的单点问题
  28. 28. Feed Timeline • 防单点 – failover – 一致性哈稀
  29. 29. Feed Timeline • 如果有资源:master/slave Mysql Web Memcached Master Cluster Memcached Slave Cluster
  30. 30. Feed Timeline • 问题出现 – mysql压力再次过大,性能出现瓶颈 – mc容量出现瓶颈,命中率降低
  31. 31. Feed Timeline • 在线扩容memcached – 保证高可用,注意命中率 Slave node1 node2 node3 Backup(old master) node1 node2 node3 Master(new master-empty) node1 node2 node3Client (get) node4
  32. 32. Feed Timeline • 问题出现 – memcached读再次成为瓶颈 – 读取量会持续成倍增长 – 期望有线性扩容的方案
  33. 33. Feed Timeline • 线性扩展-L1 Cache Slave node1 node2 node3 Master node1 node2 node3 L1 cache node1 node2 node3 Client (get)
  34. 34. Feed Timeline
  35. 35. Feed Timeline • 打造高可用memcached-容量规划 – 请求量 – 命中率 • 预热,防止雪崩 – 带宽 • 网卡、交换机 – 存储容量 • 预估存储大小 • 过期策略、剔除率 – 连接数
  36. 36. Feed Timeline • 小结 无cache 进程内 集中式 分布式 master/slave L1 cache
  37. 37. Create Feed Create Feed Mysql Web
  38. 38. Create Feed • 问题出现 – 写入有一定延迟,期望轻量级发布 – 前端承担太多职责,期望资源集中式管理
  39. 39. Create Feed • 异步化处理 Resouce Web Memcacheq Processor
  40. 40. Memcacheq简介 • Memcached Protocol – set/get – stats queue • Berkeley DB Storage • Fixed Size Value • 10000+ qps • Access – Telnet – printf 'stats queuern' | nc ip port – Java client
  41. 41. Create Feed • 问题出现 – 单机出现读写瓶颈 – 存在单点故障风险
  42. 42. Create Feed • 分布式memcacheq – 轮询读取,随机写入,写入失败写入下一个 Mysql Web MemcacheqMemcacheq ...... Processor
  43. 43. Create Feed • 问题出现 – Feed消息大小跨度比较大(xxb – 4k),平均大 小< 512b,90%以上在512b以下 – mcq由于采用定长存储,所以大小设置为4k – 浪费磁盘空间及其有一定的性能损耗
  44. 44. Create Feed • 分成多种纬度大小的mcq Resouce Web Memcacheq ( 5 1 2 b ) Processor Memcacheq ( 4 k)
  45. 45. Create Feed • 问题出现 – 高峰时读写memcacheq有较多慢请求,甚至超时 – memcacheq读写成为瓶颈
  46. 46. Create Feed • 在线扩容memcacheq – 先上线processor,后上线web,why? – 避免队列堆积情况
  47. 47. Create Feed • 问题出现 – 队列堆积,造成微博延迟 – 冷数据从磁盘读取,恶性循环
  48. 48. Create Feed • 打造高速队列处理系统 – 按业务和处理速度拆分队列 – 处理速度合理预估 – 可降级 – 避免数据库查询
  49. 49. Create Feed • 队列堆积处理 – 加快队列数据处理能力 • 扩容队列处理机或开更多处理线程 • 当资源成为瓶颈时,降级处理 – 解决mcq读写性能瓶颈,提高吞吐量 • 整体成为瓶颈:扩容队列 • 某节点成为瓶颈:若无堆积考虑下线此节点
  50. 50. Create Feed • 问题出现 – 启用新的IDC以实现跨机房容灾及其提高就近用 户访问速度 – 消息需要在各IDC之间传输
  51. 51. Create Feed • wmb(weibo message broker)
  52. 52. Create Feed • memcached统计和监控 – message per second – message per day – 峰值写入 – 队列堆积数(stats queue)
  53. 53. Social Graph Social Graph Mysql Web
  54. 54. Social Graph • 问题出现 – 读成为瓶颈,出现大量慢查询 – 对于关系业务,期望的是提供高速的接口
  55. 55. Social Graph • 使用redis存储 – 为什么不用memcached? • redis支持更丰富的数据结构 • redis做为storage Mysql Web Redis
  56. 56. Redis简介 Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. REmote DIctionary Server
  57. 57. Redis简介 • Advanced、Fast Key-Value Store • Rich Data Types – Strings:get/set/incr/decr – Hash:hget/hgetall/hset – List:lpush/lpop/lrange – Set:sadd/srem/smembers – Info • Uses Memory As Main Storage • Single Thread • Uses Disk For Persistence – rdb – aof • Replication • Access – Telnet – printf ‘info rn' | nc ip port – Java client
  58. 58. Social Graph • Redis使用示例-Social Graph – 数据结构[hash] • key:user id • fields:friend ids • value:added time – 相关命令 • 加关注:hset user_id friend_id added_time • 删关注:hdel user_id friend_id • 获取关注用户的时间:hget user_id friend_id • 获取关注列表:hgetall user_id
  59. 59. Social Graph • 问题出现 – 读写出现瓶颈,大量慢查询 – Redis服务器cpu 100% – 单机成为瓶颈
  60. 60. Social Graph • 分布式redis Web RedisRedis ......
  61. 61. Social Graph • 问题出现 – 获取关注列表比较慢 – redis服务器cpu比较高 – hgetall成为瓶颈
  62. 62. Social Graph • 加Memcached Mysql Web Memcached Redis
  63. 63. Weibo Counter Weibo Counter Mysql Web
  64. 64. Weibo Counter • 问题出现 – 读成为瓶颈,出现大量慢查询 – 对于计数业务,期望的是提供高速的接口
  65. 65. Weibo Counter • 计数独立存放到redis中 Mysql Web Redis
  66. 66. Weibo Counter • 问题出现 – 读写出现瓶颈,大量慢查询 – Redis服务器cpu 100% – 单机成为瓶颈
  67. 67. Weibo Counter • 分布式redis Web RedisRedis ......
  68. 68. Weibo Counter • 问题出现 – 容量成为瓶颈 – 微博纬度的计数器,一直在快速增长
  69. 69. Weibo Counter • 支持滚动的redis First Redis Second Redis MysqlClient set set set Client get get
  70. 70. Weibo Counter • 问题出现 – redis可以存放的数据量较小,随着业务的发展, 穿透到mysql的量逐渐增大
  71. 71. Weibo Counter • rediscounter – 消息定长存储 • 节省>60%的空间 – 启动时预分配所有内存 – aof支持position
  72. 72. Weibo Counter • 问题出现 – 滚动切换成本较大,伴随着较大风险 – 资源耗费成本比较大
  73. 73. • 问题出现 – …… …… – …… ……
  74. 74. • 架构在不断演化中 – 没有永恒的和一成不变的方案 – 合适的场景使用合适的技术和方案 – 力求简单可靠 – 为未来一段时间考虑但不过度设计
  75. 75. QA Thank You

×