金吉祥：万亿级数据洪峰下的消息引擎

2020-03-01 55浏览

  • 1.7 万亿级数据洪峰下的消息引擎 1 0 2 C C 牟羽@阿里巴巴 A S
  • 2.自我介绍  花名：牟羽  真名：金吉祥  @阿里巴巴-消中间件  开源软件爱好者，Apache RocketMQ committer  Aliware MQ核心开发 2 C C A S  邮箱：lollipop@apache.org 7 1 0
  • 3.分享内容 阿里消息中间件发展历史 消息中间件核心功能设计 2 双11万亿数据洪峰的挑战CC A S RocketMQ 5.0 展望 7 1 0
  • 4.阿里消息中间件发展历史 2007 Napoli RocketMQ 3.0 ActiveMQ内核 B2B大规模使用 RocketMQ开源 2010 2011 2012 2 C C A S Apache RocketMQ 7 1 0 进入基金会孵化 2016年度最受欢迎 中国开源软件 2015 2016 Notify RocketMQ 1.0 Aliware MQ v1.0 五彩石项目 交易核心消息流转 顺序消息 海量堆积能力 阿里云商业版 专有云输出 2017 成为Apache顶级项目
  • 5.阿里消息中间件现状 MetaQ 有序消息，Pull 模式 海量消息堆积能力 7 1 0 事务消息, Push模式 交易核心消息分发 2 C RocketMQ C A S Notify Aliware MQ 阿里云商业化消息中间件 覆盖公有云、金融云、专 有云、聚石塔
  • 6.分享内容 阿里消息中间件发展历史 消息中间件核心功能设计 2 双11万亿数据洪峰的挑战CC A S RocketMQ 5.0展望 7 1 0
  • 7.消息领域模型 2 C C A S 7 1 0
  • 8.消息组件交互流程 2 C C A S 7 1 0
  • 9.事务消息 2 C C A S 7 1 0 Tips： 1. 保证本地事务与消息处理的最终一致性，并非强一致性。 2. 消息中间件保证消息至少投递一次。
  • 10.顺序消息 2 C C A S 7 1 0
  • 11.消费模式 集群消费模式 2 C C A S 7 1 0 广播消费模式
  • 12.消息过滤 基于消息tag、属性进行过滤 •语法: SQL92子集 •关键字: •NOT •AND •OR •BETWEEN •IN •TRUE •FALSE •NULL 2 C C A S •IS •举例: a IS NOT NULL AND (a IN (‘abc’, ‘def’)) •Server端过滤，节省带宽 7 1 0
  • 13.消息轨迹 2 C C A S 7 1 0
  • 14.分享内容 阿里消息中间件发展历史 消息中间件核心功能设计 2 双11万亿数据洪峰的挑战CC A S RocketMQ 5.0展望 7 1 0
  • 15.历年双十一消息量变化 万亿+ 2 C C A S 千亿 百亿 十亿 2012双11 2013双11 2014双11 7 1 0 五千亿+ 2015双11 2016双11
  • 16.消息中间件核心链路 用户请求 菜鸟蓄洪 交易 交易 天猫满返 7 1 0 堆积消息峰值：千亿条 用户请求 易 易 购物车 用户请求 易 红包火山 2 C C A S 几十万条/秒 Notify+MetaQ Notify+MetaQ Notify+MetaQ 发布消息峰值：千万条/秒 订阅消息峰值：千万条/秒 航旅 交易买卖家 交易安全 BCP 钉钉 淘客
  • 17.万亿洪峰下有哪些问题 磁盘响应慢 IO Util，Load飙高 根本的要求： 7 1 0 容量不足，单机热点 慢请求开始大量增加 可用性无限接近100% 机器假死 2 C C 可靠性无限接近100% A S 磁盘损坏 网卡故障，甚至流量跑满 消息大量堆积 分布式系统雪崩 可用性零点之战：发布消息SLA要求100% > 可靠性
  • 18.双十一当天系统可用性要求 ~ 100% 𝑀𝑇𝐵𝐹 𝑀𝑇𝐵𝐹 + 𝑀𝑇𝑇𝑅 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = 1600 1400 1200 𝑀𝑇𝐵𝐹: Mean time between failure 𝑀𝑇𝑇𝑅: Mean time to recover. 1000 2 C C A = 99.999% S 800 600 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑖𝑙𝑖𝑡𝑦 = 60∗60∗24 − 1 60∗60∗24 400 200 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121 126 131 136 141 146 𝑀𝑇𝑇𝑅 = 1 seconds 7 1 0
  • 19.消息中间件可用性提升方案 容量规划，限流 低延迟分布式存储系统 2 C C 在线熔断机制，秒级隔离 A S 7 1 0 单机故障自动恢复，秒级主备切换
  • 20.慢请求导致雪崩 2 C C A S 7 1 0
  • 21.高并发场景下写消息毛刺（优化前） 2 C C A S 7 1 0
  • 22.低延迟分布式存储系统—访存毛刺分析  Memory access latencyissues: Direct reclaim • Background reclaim (kswapd) • Foreground reclaim (direct reclaim) 2 C C A S 7 1 0
  • 23.低延迟分布式存储系统—访存毛刺分析 Memory access latencyissues: swapout/swapin • Put anonymous pages to disk • Need I/O to read data from disk at next access 2 C C A S 7 1 0
  • 24.低延迟分布式存储系统—访存毛刺分析  Memory access latencyissues: Memory lock  Wake_up_page  Wait_on_page_locked()  Wait_on_page_writebacfk() 2 C C A S LOCKED DIRTY LRU ACTIVE WRITEBACK RECLAIM ANON SWAPCACHE SWAPBACKED HUGE RECLAIM NOPAGE Mem page flags 7 1 0
  • 25.低延迟分布式存储系统—消除访存毛刺 Pre-Allocation + mlock/mlockall vm.extra_free_kbytes vm.swappiness ksw apd w akeup allocate w aterm ark m in 2 C C A S reclaim w aterm ark low 7 1 0 U sed w aterm ark high ksw apd w akeup extra free_kbytes w aterm ark m in allocate reclaim w aterm ark low U sed w aterm ark high
  • 26.高并发场景下写消息毛刺（优化后） 2 C C A S 7 1 0
  • 27.在线熔断机制 ①消息服务器 7 1 0 ②消息服务器 应用 2 C C A S ③消息服务器 ④消息服务器 规则 1. 最多只能隔离 30%的机器。 2. 响应时间过长， 开始隔离1分钟 3. 调用抛异常隔 离1分钟 4. 如果隔离的服 务器超过30%， 则有部分调用 会进入隔离列 表中最早隔离 的机器
  • 28.分布式系统高可用架构理论 Availability A AP CA Pick Two! C Consistency CP P Partition Tolerance It's really just A vs C! 2 C C A S 7 1 0
  • 29.分布式系统高可用架构理论 Master/Slave 异步复制 同步复制 ② Master ③ ④ ① ② Slave 17 Master 0 2 C C A S Client 延迟上升、吞吐下降 消息可靠、故障自动恢复、强一致性 ③ Slave ② ① Client 延迟低、高吞吐 磁盘故障导致部分消息丢失、 故障恢复时间较长、最终一致性
  • 30.消息中间件高可用架构 Controller 提供: • 观察Broker状态的变更. • 执行状态机变更，推送新状态机至ZK ZK 提供: 2 C C A S 7 1 0 • 持久化存储状态机 • 以临时节点的方式存储Broker的状态 • 提供状态变更通知相应Watcher的机制 工作流程: 汇报状态 监听状态机变更 变更状态
  • 31.故障自动恢复Tips: 机器宕机自动恢复  低 MTTR  消息发送RT上升可控  系统吞吐损耗可控  多副本，提升消息可靠性 2 C C A S 99.99% 时间处于同步复制状态 7 1 0 ♻♻Failover
  • 32.系统可用性提升 变量 取值 & 说明 MTBF of MQ(小时) 876, 意味着1年内机器故障宕机10次 MTTR without HA(分钟) 30, 涵盖故障报警、机器重启，服务启动的耗时 MTTR with HA(秒) 30, 故障自动恢复 集群规模 是否高可用 是否顺序 1主 ❌ ❌ 2主 ❌ 1主1备 ❌ 2M2S ❌ 1M ❌ 2M 0 2 C C A S 17 ❌ 消息可用性 99.94% 99.999967% ❌ 99.99904% ❌ 超过10个9 ❌ 99.94% ❌ ❌ 99.88% 1M1S ❌ ❌ 99.99904% 2M2S ❌ ❌ 99.9980% 顺序
  • 33.分享内容 阿里消息中间件发展历史 消息中间件核心功能设计 2 双11万亿数据洪峰的挑战CC A S RocketMQ 5.0展望 7 1 0
  • 34.RocketMQ 5.X 展望 2 C C A S 7 1 0
  • 35.2 C C A S 7 1 0