阿里巴巴 金吉祥:万亿级数据洪峰下的消息引擎

Cartel

2017/11/14 发布于 技术 分类

2016年,阿里巴巴将自主研发的第三代分布式消息引擎RocketMQ捐赠给Apache软件基金会。作为近些年双十一大促核心基础产品,它的架构演进是怎么样的?面对双十一万亿级洪峰,它是如何保证稳定性和可用性的,都有哪些借鉴思想?面对分布式经典问题 - 慢请求,它是如何做到99.996%的延迟落在了10ms以内,而99.6%的延迟在1ms以内的?本次分享将为大家带来分布式消息系统在高可用、高可靠领域的一些实践经验,以及在分布式消息存储上的低延迟、高吞吐的性能优化的分享。

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