腾讯云分布式高可靠消息队列 CMQ 架构

作者:张浩

在分布式大行其道的今天,我们在系统内部、平台之间广泛运用消息中间件进行数据交换及解耦。CMQ是腾讯云内部自研基于的高可靠、强一致、可扩展分布式消息队列,在腾讯内部包括微信手机QQ业务红包、腾讯话费充值、广告订单等都有广泛使用。目前已上线腾讯云对外开放,本文对腾讯云CMQ 核心技术原理进行分享介绍。

CMQ消息队列主要适用于金融、交易、订单等对可靠性、可用性有较高要求的业务场景。

以腾讯充值系统为例,该充值系统通过CMQ 对交易模块、发货部分、结算系统进行异步解耦、削峰填谷,一方面大大降低了模块间耦合度,另一方面减轻了大量突发请求对后端系统的冲击。在月初充值该系统一天经过CMQ转发的消息超过十亿条,每秒峰值超过10w,最高时有数亿条消息通过CMQ的堆积能力缓冲了对后端消费模块的压力。架构如图1:

图1-某充值系统结构

图中腾讯云消息队列CMQ整体结构如图2所示,本文重点介绍后端broker set实现原理。通常情况下一个set由3个节点组成,通过多副本保证消息的可靠性、多节点提高系统可用性。当然,可以根据业务的实际需求通过增加set内节点个数来进一步提高可靠性和可用性,

图2-CMQ整体架构图

CMQ set 模块内部结构如图3所示。

图3-brokerset 内部结构图

下面分别中数据高可靠、强一致,系统可用性,可扩展、消息全路径追踪方面分别介绍。

在可靠性保证方面主要包括以下三方面:生产可靠、存储(堆积)可靠、消费可靠:

生产可靠

如图3所示,客户端生产的消息在set 中超过半数的broker 刷盘成功后会返回确认消息告知生产消息成功。如果在一定时间之内客户端没有收到确认信息需要重试来确保消息发送成功。

可靠生产带来的一个问题就是消息的重复,在网络异常等情况下很可能CMQ broker已经存储消息成功只是确认包在网络上丢失了,这样客户端重试生产后,在broker上存在两条重复的消息。考虑到消息去重开销较大,目前消息的幂等性需要业务逻辑来保证。

存储可靠

CMQ SET中一个节点为leader 其他节点为follower,leader 负责所有消息的生产消费。当生产消息到达leader 节点后,通过raft 一致性模块将请求顺序写raft log 并同步刷盘,同时将构造好的raft log 按顺序通过网络发送到其他follower节点,follower节点同步刷盘并返回成功。当leader 收到过半数的节点同步成功信息后将此条请求提交到mq 处理状态机,由mq 状态机将请求应用到相应queue。大致逻辑图4所示。

图4-数据存储原理示意图

由此可见,对于返回客户端成功的消息至少是分别在两个节点磁盘上存储成功的,这就将磁盘故障引起的数据丢失大大降低。另外数据在磁盘上存储时会将检验结果一同记下来,消费者在消费数据之前CMQ broker 会进行比较,确保消息是完整有效的。

消费可靠

消费者拉取消息时会指定当前消息的隐藏时间,在隐藏时间内消费者比较显式的对消息进行确认删除,如果超过隐藏时间没有主动删除,此条消息将重新对外可见,可以继续消费。

显式确认删除消息是为了防止消息在投递、处理过程中异常而导致的消息丢失。

对于消息的确认信息 CMQ broker的处理逻辑和生产消息过程类似,也是一个写入的过程,不同的是此时写入的数据的内容是msgid 和消息状态。

强一致实现

假如一个set中有3个节点(A, B, C),A为leader,B C 是follower。如上图所示,对于返回客户端成功的请求数据在CMQ 中至少在两个节点上存在,假设为A B,此时如果leader A故障,B C 两个follower 会自动选举出一个新leader,CMQ 使用的raft 算法可以保证这个leader 一定是拥有最全量log 信息中的一个,在此必定是B。此时B继续对外服务,B 和A 拥有相同的已经返回确认给用户的全量数据视图,数据是强一致的。

对于A 和 B C 所在的网络发生分区的情况(如图5),由于leader A得不到set 中过半节点的回复所以不能处理请求,B C在选举超时后会选举出一个新的leader ,CMQ的接入层会自动进行切换。Raft 算法保证新leader 同样具有完成的数据视图。

可用性保证

如上文所述,master 负责所有消息的生产消费,当master 故障时SET中其他follower节点会自动选举出一个新leader,客户端请求会自动重定向到leader节点,RTO和配置的选举超时时间有关,目前是在5s左右。大致过程如上图6所示。

CMQ单个set 在CAP理论中优先保证了CP,当SET中过半数节点都正常工作时,才能进行消息的生产消费。对于SET多个节点同时故障的不可用情况,CMQ强大的监控调度能力能够快速对queue进行调度迁移恢复服务,将不可用时间降到最低。

横向扩展,无限堆积

上文中SET的概念对用户来说是透明无感知的,CMQ controller server 根据set的负载情况实时对queue进行调度搬迁。如果某个queue的请求量超过当前set的服务阈值,controller server 可以将queue 路由分布到多个set 上来提高并发量,对于需要海量堆积的服务来说可以通过路由调度来提升堆积上限,理论上可以达到无限堆积。

目前CMQ只能保证特定情况下消息的严格有序,例如需要保证单个生产进程、单个消费进程,或者queue的消费窗口设定为1等条件。

全路径消息trace

CMQ系统中,一条消息的完整路径包含生产者、broker、消费者三个角色,每个角色处理消息的过程中都会在trace 路径中增加相关的信息,将这些信息汇聚即可获取任意一条消息的状态和当前经过的完整路径,从而为生产环境中的问题排查提供强有力的数据支持。大大降低了业务定位问题的难度。

小结

CMQ是基于raft 算法来保证数据高可靠、强一致的分布式消息队列,主要服务于订单、交易类业务场景。消息的幂等性需业务侧来保证,在特定情况下可以保证消息严格有序。

对于更侧重高性能、高吞吐量业务需求,腾讯云由另外一个消息引擎来提供服务,在协议上同时兼容kafka,很好的满足了大数据场景,具体原理请留意后续文章介绍。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

4 条评论
登录 后参与评论

相关文章

来自专栏ImportSource

NoSQL-ReadConsistency-读取一致性

翻译内容: NoSQL Distilled 第五章 Consistency 一致性 作者简介: ? 本节摘要: 一致性向来是分布式...

3075
来自专栏性能与架构

Redis的消息机制 - 发布订阅

发布订阅(pub/sub)是一种消息通信模式,主要目的是解除消息发布者、消息订阅者之间的耦合 pub/sub的特点 (1)时间非耦合 发布者和订阅者不必同时在线...

41012
来自专栏Java进阶架构师

「架构技术专题」作为java程序员的你还不知道网站架构的演化(2)?

CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,而反向代理是部署在网站的中心机房,当用户请求到达中心机房后,首先访问的反向代理,如果反...

874
来自专栏社区的朋友们

消息队列 CMQ 七大功能实践案例

本文先简单介绍 CMQ 底层的架构实现,然后着重结合CMQ的功能特点来介绍 CMQ 的实践案例,让大家快速理解和上手 CMQ 的开发。

7898
来自专栏架构师之路

状态同步,究竟是推还是拉?

状态同步,有好友状态的同步,有群友状态的同步,有的需要实时同步,有的能够容忍延时。结合具体场景来看下,状态同步,究竟是推还是拉。

1012
来自专栏Linyb极客之路

聊聊微服务架构及分布式解决方案

事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性:

663
来自专栏CSDN技术头条

一场完美的“秒杀”:API加速的业务逻辑

一天清晨,我被一个客户电话惊醒,客户异常焦急,寻问CDN能不能帮助他们解决“秒杀”的问题,他们昨天刚刚进行了“整点秒杀活动”,结果并发量过大,导致服务宕机,用户...

2088
来自专栏Laoqi's Linux运维专列

LVS 三种负载均衡模式详解

3738
来自专栏Rainbond开源「容器云平台」

基于akka的分布式实时消息系统

1624
来自专栏即时通讯技术

移动端IM中大规模群消息的推送如何保证效率、实时性?

众所周之,群聊是移动端IM的服务端技术难点所在,难在哪?大量的群聊消息,是一条条推给群内成员还是可以使用什么样的优化策略?试想一个2000人大群,一条消息的发出...

731

扫码关注云+社区