腾讯企业级消息中间件DevOps实践 闫二辉 腾讯

2020-03-01 442浏览

  • 1.腾讯企业级消息中间件 DevOps之路 闫二辉 腾讯中间件专家工程师
  • 2.
  • 3.
  • 4.
  • 5.闫二辉(zizayan) 腾讯中间件专家工程师，2012年加入腾讯基础架构部 主要从事： Ø 腾讯分布式服务开发框架TSF：微服务开发和生命周期管理PaaS平台 Ø 消息中间件CMQ、CKafka:高可靠、强一致、高弹性分布式消息服务 Ø IoT Hub ：安全、高并发、多协议设备接入与规则引擎解析
  • 6.• 背景介绍 • 从开发、运维维度解析核心原理 • 分布式消息系统对测试的挑战 • 微信红包中如何使用消息中间件
  • 7.消息中间件应用场景 Ø 业务解耦: 同步变异步 最终一致 Ø 削峰限流： 防止雪崩 按需消费 Ø 广播： 透明生产 谁需要谁订阅 Ø 延时消费： 定时触发-简化业务逻辑 Ø 回档消费： 离线消费-从指定点消费
  • 8.消息中间件应用场景 Ø 流数据处理： 按需对消息过滤分类 简化业务程序逻辑 Ø 分布式事务 多个本地事务 简单。高效，最终一致
  • 9.背景介绍 CRMQ-Rabbitmq 2012内部大规模使用 CRMQ-Raft 2014年自研2.0 Ckafka 2014年开始内部使用 CMQ 2016年上线腾讯云 Ckafka 2017年上线腾讯云 ØCMQ:金融级别，多副本，高可靠，强一致，多级容灾 Ø Ckafka： 大数据领域，高吞吐，低延时 Ø MQ forIoT:MQTT接入，支持千万并发，安全性高 Ø 内部日消息量：超万亿条 Ø 接入业务个数：超万个 分布式消息系统
  • 10.分布式消息系统特点 最大特点：可扩展性(Scale Out) 核心理念：多个节点协同工作，完成单个节点无法处理的任务 对硬件要求低 强调横向可扩展性 不允许出现单点故障服务不可用（RTO） 不允许单点故障导致数据丢失(RPO) 核心问题：CAPCMQ:CPKafka:AP(配置可调整)
  • 11.DevOps 流程 Ø 开发阶段：方案设计、代 码设计、LLT（单元测 试、模块测试）; Ø 测试阶段：测试设计、自 动化脚本、HLT（系统测 试、联调测试）; Ø 灰度阶段：灰度规则和策 略、灰度测试设计、监控 告警; Ø 上线阶段：定时在线测试 设计、日常运营 监控告警
  • 12.• 背景介绍 • 从开发、运维维度解析核心原理 • 分布式消息系统对测试的挑战 • 微信红包中如何使用消息中间件
  • 13.架构介绍 典型三层架构 Ø 适配层： 协议解析 弹性伸缩 Ø 存储层： 多副本 强一致 高可靠 高可用 高性能 低延时 Ø 运营难点：如何做到发布变更对业务透明？ 如何做到弹性扩展？ 节点故障如何处理？ 集群故障如何处理，园区级别故障如何处理？
  • 14.弹性伸缩 Ø 问题：性能和堆积不受限与set，支 持透明scale out， 可以无限扩展 üControllerserver:向生产者 消 费者 下发扩缩容路由信息; ü生产: 获取路由信息，轮询多个 broker set 实现消息生产 ü消费: 获取路由信息，通过轮询 主动拉 或者 server 推的方式消 费数据
  • 15.高可靠(1/2) Ø 数据可靠性：系统有n个数据对象，在1年内会损坏m个对象，可靠性为1-m/n Ø 可靠性相关因子：副本数、磁盘故障率、修复率 Ø 常见 master+Nslave数据多副本问题： ü数据一致性问题：异步复制会导致slave上数据丢失，同步复制到所有slave导致 系统可用性低 ü同步复制性能问题：每个请求都发起一次主从数据同步，导致系统性能低下 ü持久化问题：在master、slave cache中还未来得及持久化到磁盘的数据存在异常情 况下丢失的可能 ü刷盘性能问题：每个请求都强制刷盘一次，导致系统IO负载高
  • 16.高可靠(2/2) Ø 问题：异步复制无法保证强一致，同步复制到所有slave导致可用性低 ü方案：master同时向所有slave同步数据，salve 收到数据存储成功后向master返回成功， master 收到过半数节点返回成功后应用到mq状态机，返回用户成功。 举例：一个set 有3个节点组成，自动选举出一个 master，两个slave • Master 负责消息的生产消费请求，收到请求后先通 过raft一致性模块写raft log到本地并同步给所有 slave • Slave 收到master发来的raft log持久化到本地同时 返回master 成功信息 • Master 收到set中过半节点的成功信息后将请求信息 提交到mq 状态机 • Mq 状态机处理请求信息后返回用户成功
  • 17.高性能(1/2) Ø 问题：同步复制性能问题 Master每收到一个请求都向所有slave各发起一次网络IO, slave 处理成功后回复master成功。 Master 和slave 还需要对收到的请求同步刷盘 Ø 分析：单次请求同步复制下，同步刷盘耗时： üTtotal=Tcreat_raft_log+Tmaster_fsync_raft_log+Treplicate_raft_log+Tapply_raft_log üTcreat_raft_log、Twrite_raft_log Tapply_raft_log 受限单机处理性能 üTreplicate_raft_log=Traft_log网络传输+Tslave_fsync_raft_log，Traft_log网络传输取决于RTT值 üTtotal=Tcreat_raft_log+Tmaster_fsync_raft_log+ Traft_log网络传输+Tslave_fsync_raft_log +Tapply_raft_log 其中Tmaster_fsync_raft_log与slave的 Traft_log网络传输 Tslave_fsync_raft_log 是并行发生的。 fsync_raft_log时间取决于磁盘性能，raft_log 网络传输时间取决于网络RTT。 由此可见这两个值是硬 件相关的，因此我们只能通过提高每次批量发送raft_log 和批量fsync 刷盘来提高QPS(在牺牲一定请求延 时情况下，可配置)
  • 18.高性能(1/2) Ø 解决思路：批量同步、批量刷盘提升性能 Ø 具体方法： ü批量fsync：master 通过定时、定量两个维度合并请求批量刷 盘，提高QPS(可配置) ü 批量发送raft log到slave:同上 ü 严格同步刷盘：master slave 遵循fsync 后才返回成功的逻 辑，确保异常断电、宕机情况下的数据100%不丢失。
  • 19.节点可用性 Ø 问题：当set内节点间发生网络分区时如何确保数据一致性？ ü当slave 单独在一个分区时，master可以 得到过半数节点的应答，无任何影响； ü 当master 单独成为一个分区时由于得不到大多数节点的应答，超时后最合适的 salve 会 提升为master ü具体过程： 关键变量： • Log序号（index） • Master任期号（term） Raft Log同时记录了index和term。 Raft数据同步核心思想： 1）Master通过选举产生，同时产生了一个新的term，且新term > 老term 2）Slave只接受大于或者等于当前term的连续log。 3）Master根据Slave的上一条log和term，发送差量log，实现数据一致性。
  • 20.集群可用性 SDK Ø 问题：raft解决了单节点 故障导致的可用性问 题，如果同一个set内多 个节点故障，怎么办？ Ø 解决方案：双SET服务能力 正常访问 容灾访问 master slave master slave Set1 ü ü ü ü Control Server 分别在两个set创建Topic/Queue元数据 一个Set真正对外服务，另外一个standby Set内节点故障选举时间最大2s，Set 间故障切换时间5s 切换时数据顺序性问题 slave slave Set2
  • 21.跨园区可用 Ø 问题：金融业务要求具备跨园区容灾能力 Ø 思路： set内节点同园区部署，不同园区的set间异步同步数据 ü 1 2 ! set, ! !
  • 22.Log Trace 系统 Ø 问题：如何满足业务日常定位问题需求？消息丢了，延时大了。。。 ES ES ! ! ü全路径日志追踪： 1) 支持对消息的生产 消费全流程trace， 2) 方便查看消息延时，是否丢失，投递几次等常见运维问题
  • 23.• 背景介绍 • 从开发、运维维度解析核心原理 • 分布式消息系统对测试的挑战 • 微信红包中如何使用消息中间件
  • 24.分布式消息系统测试 Ø 做好分布式系统的测试比做分布式系统本身更难 Ø 设计的时候就要考虑如何测试这个特性 ü 功能测试 ü 压力测试 ü 异常注入测试 ü 一致性测试
  • 25.一致性测试 Cilent! Cilent! Control Node! ! ! ! 1! ! Generator! ! ! ! ! ! ! ! Nemesis! 3 History! Cilent! master 2 slave slave Cilent! Ø 记录执行结果 Ø 验证执行结果 Ø 停止集群分析结果 Model! 4 5 Checker! Ø 部署要测试的集群 Ø Control Node执行测试 程序 ü 启动集群 ü 生产5个执行序列 ü 5个线程执行序列 • 调用Client执行请求 • 通过SSH登录N1-N2注入故障 6 !
  • 26.• 消息中间件应用场景 • 腾讯消息中间件核心技术原理解析 • 分布式系统对开发、测试、运维的挑战 • 微信红包中如何使用消息中间件
  • 27.微信红包中如何使用消息中间件 Ø目标：应对财付通转账接口异常， 列表更新异常，回调写用户信息异 常等场景，缓存失败请求，由独立 模块补偿重试。 Ø对消息中间件的要求： 高可靠 强一致 高性能
  • 28.微信红包中如何使用消息中间件 Ø正常流程： 写详情KV 写发列表KV LRsync写用户发DB Ø异常流程： ü 对于LSvr返回失败或者超时，HBSvr写CMQ。写CMQ 失败立刻重试2次，丢弃并写错误日志 ü CMQ Task调LSvr返回失败或超时，Task20秒后重试， 重试2次后丢弃并记错误日志 ü 写详情KV或者发列表KV失败，返回业务失败 ü CMQ修复失败和LRsync写DB失败，则依赖DB对账解决 ü 如果LSvr到LRsync间管道堆积超过50%，LRsync直接落 盘
  • 29.