分布式缓存与队列
•Descargar como PPTX, PDF•
13 recomendaciones•2,055 vistas
新浪微博新员工培训及其技术交流活动topic，主要阐述从中小系统发展到大型系统的技术演化过程
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 分布式缓存与队列
Similar a 分布式缓存与队列 (20)
分布式缓存与队列
- 2. 缓存和队列概述 雪崩 高可用 单点故障 Ram Is The New Disk 异步化处理 横向扩展 对于一个大流量在线系统，你是否听过：
- 3. 缓存和队列概述 • 实现一个简化版微博系统 – 发表微博、查看用户发的微博列表 – 评论微博、查看微博评论列表和评论数 – 加关注、查看关注列表
- 6. 缓存和队列概述 • 从四条主线来说明怎么一步步解决问题 o 查看微博列表数据－memcached o 发布微博和评论－memcacheq o 加关注和查看关注列表－redis、memcached o 加和查看微博计数－redis、handlersocket
- 8. Feed Timeline • 问题出现 – 读请求很慢，大量mysql慢查询和超时情况 – mysql每秒可支撑千级别qps
- 10. Feed Timeline • 问题出现 – 数据太多本地缓存放不下 – 影响JVM GC，进而影响系统整体性能 – 多个Web时存在缓存同步问题
- 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. 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. 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. 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. Feed Timeline • Memcached使用示例 – 操作命令 • set <key> <flags> <exptime> <bytes> <data block> • get <key> • delete <key> – 尽量减少value大小，节省存储和带宽成本 • memcached客户端quickLZ压缩 • 从业务层面做相应压缩
- 17. Feed Timeline • 问题出现 – mysql再次出现性能瓶颈，读取压力过大 • 单台mc容量有限，缓存数据大量过期 • 缓存命中率下降，进而导致大量请求穿透到mysql – memcached出现慢查询情况 • mc单机吞吐量有限，读压力超过可支撑最大限度 • 带宽成为瓶颈
- 19. 分布式概述 • 实现分布式的方式 – 客户端实现分布式 • memcached、memcacheq、redis、mysql… – 服务端实现分布式 • cassandra、dynamo、hbase…
- 20. 分布式概述 • 客户端实现分布式
- 21. 分布式概述 • 客户端实现分布式常用算法 – 取模求余算法 – 一致性hash算法
- 22. 分布式概述 • 取模求余算法 node1 node2 node3 hash(id) % 3 (0) (1) (2)
- 23. 分布式概述 • 取模求余算法－加节点 node1 node2 node3 hash(id) % 4 (0) (1) (2) node4 (3)
- 24. 分布式概述 • 一致性哈稀算法
- 26. 分布式概述 • 客户端实现分布式常用算法 – 取模求余算法 • 优点：算法简单 • 缺点：加减节点时震荡厉害，命中率下降厉害 – 一致性hash算法 • 优点：加减节点时震荡较小，保持较高命中率 • 缺点：负载不够均衡，出现热节点 注意点：当存在单点时，优先考虑一致性hash
- 27. Feed Timeline • 问题出现 – 某memcached crash，读写此mc报错 • 可能是硬件或其它原因导致crash • 典型的单点问题
- 28. Feed Timeline • 防单点 – failover – 一致性哈稀
- 29. Feed Timeline • 如果有资源：master/slave Mysql Web Memcached Master Cluster Memcached Slave Cluster
- 30. Feed Timeline • 问题出现 – mysql压力再次过大，性能出现瓶颈 – mc容量出现瓶颈，命中率降低
- 31. Feed Timeline • 在线扩容memcached – 保证高可用，注意命中率 Slave node1 node2 node3 Backup(old master) node1 node2 node3 Master(new master-empty) node1 node2 node3Client (get) node4
- 32. Feed Timeline • 问题出现 – memcached读再次成为瓶颈 – 读取量会持续成倍增长 – 期望有线性扩容的方案
- 33. Feed Timeline • 线性扩展－L1 Cache Slave node1 node2 node3 Master node1 node2 node3 L1 cache node1 node2 node3 Client (get)
- 34. Feed Timeline
- 35. Feed Timeline • 打造高可用memcached－容量规划 – 请求量 – 命中率 • 预热，防止雪崩 – 带宽 • 网卡、交换机 – 存储容量 • 预估存储大小 • 过期策略、剔除率 – 连接数
- 36. Feed Timeline • 小结 无cache 进程内 集中式 分布式 master/slave L1 cache
- 38. Create Feed • 问题出现 – 写入有一定延迟，期望轻量级发布 – 前端承担太多职责，期望资源集中式管理
- 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. Create Feed • 问题出现 – 单机出现读写瓶颈 – 存在单点故障风险
- 42. Create Feed • 分布式memcacheq – 轮询读取，随机写入，写入失败写入下一个 Mysql Web MemcacheqMemcacheq ...... Processor
- 43. Create Feed • 问题出现 – Feed消息大小跨度比较大（xxb – 4k），平均大 小< 512b，90%以上在512b以下 – mcq由于采用定长存储，所以大小设置为4k – 浪费磁盘空间及其有一定的性能损耗
- 44. Create Feed • 分成多种纬度大小的mcq Resouce Web Memcacheq （ 5 1 2 b ） Processor Memcacheq （ 4 k）
- 45. Create Feed • 问题出现 – 高峰时读写memcacheq有较多慢请求，甚至超时 – memcacheq读写成为瓶颈
- 46. Create Feed • 在线扩容memcacheq – 先上线processor，后上线web，why? – 避免队列堆积情况
- 47. Create Feed • 问题出现 – 队列堆积，造成微博延迟 – 冷数据从磁盘读取，恶性循环
- 48. Create Feed • 打造高速队列处理系统 – 按业务和处理速度拆分队列 – 处理速度合理预估 – 可降级 – 避免数据库查询
- 49. Create Feed • 队列堆积处理 – 加快队列数据处理能力 • 扩容队列处理机或开更多处理线程 • 当资源成为瓶颈时，降级处理 – 解决mcq读写性能瓶颈，提高吞吐量 • 整体成为瓶颈：扩容队列 • 某节点成为瓶颈：若无堆积考虑下线此节点
- 50. Create Feed • 问题出现 – 启用新的IDC以实现跨机房容灾及其提高就近用 户访问速度 – 消息需要在各IDC之间传输
- 51. Create Feed • wmb（weibo message broker）
- 52. Create Feed • memcached统计和监控 – message per second – message per day – 峰值写入 – 队列堆积数（stats queue）
- 54. Social Graph • 问题出现 – 读成为瓶颈，出现大量慢查询 – 对于关系业务，期望的是提供高速的接口
- 55. Social Graph • 使用redis存储 – 为什么不用memcached? • redis支持更丰富的数据结构 • redis做为storage Mysql Web Redis
- 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. 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. 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. Social Graph • 问题出现 – 读写出现瓶颈，大量慢查询 – Redis服务器cpu 100% – 单机成为瓶颈
- 60. Social Graph • 分布式redis Web RedisRedis ......
- 61. Social Graph • 问题出现 – 获取关注列表比较慢 – redis服务器cpu比较高 – hgetall成为瓶颈
- 64. Weibo Counter • 问题出现 – 读成为瓶颈，出现大量慢查询 – 对于计数业务，期望的是提供高速的接口
- 66. Weibo Counter • 问题出现 – 读写出现瓶颈，大量慢查询 – Redis服务器cpu 100% – 单机成为瓶颈
- 67. Weibo Counter • 分布式redis Web RedisRedis ......
- 68. Weibo Counter • 问题出现 – 容量成为瓶颈 – 微博纬度的计数器，一直在快速增长
- 69. Weibo Counter • 支持滚动的redis First Redis Second Redis MysqlClient set set set Client get get
- 70. Weibo Counter • 问题出现 – redis可以存放的数据量较小，随着业务的发展， 穿透到mysql的量逐渐增大
- 71. Weibo Counter • rediscounter – 消息定长存储 • 节省>60%的空间 – 启动时预分配所有内存 – aof支持position
- 72. Weibo Counter • 问题出现 – 滚动切换成本较大，伴随着较大风险 – 资源耗费成本比较大
- 73. • 问题出现 – …… …… – …… ……
- 74. • 架构在不断演化中 – 没有永恒的和一成不变的方案 – 合适的场景使用合适的技术和方案 – 力求简单可靠 – 为未来一段时间考虑但不过度设计
- 75. QA Thank You