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

​

极牛技术实践分享活动

极牛技术实践分享系列活动是极牛联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。

每期不一样的技术主题，和行业专家深度探讨，专一解决技术实践难点，推进技术创新，每两周的周三20点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。

嘉宾介绍

张 浩 腾讯云产品经理

负责腾讯云消息队列、弹性块存储、负载均衡器等多款iaas层产品的产品规划、迭代，性能体验优化等 。

闫二辉 腾讯云资深存储架构师

在大规模存储、PaaS、虚拟化领域有长期深厚积累。目前主要从事互联网中间件的设计研发相关工做。

周维跃 腾讯云资深研发工程师

负责腾讯云IaaS层虚拟化资源调度运营系统的设计研发。

目录

消息队列的使用场景、价值

CMQ底层架构剖析

CMQ对比开源rabbitMQ压测

CMQ案例最佳实践

01|消息队列的使用场景

消息的收发解耦：发送方和接收方不须要了解彼此，甚至不须要知道对方的存在；

屏蔽不一样平台之间的差别：不一样平台之间经过消息来实现交互，仅仅关心消息的发送和读取；

削峰填谷，提升系统应对突发能力：发送消息端永远不会堵塞，突发消息缓存在CMQ SERVER 端，消费者按照实际能力读取消息；

一次生产屡次消费：一条消息能够被多钟类型消费者订阅，生产着仅需生产一次便可；

跨IDC/WAN传输：CMQ支持消息在不一样IDC、城市进行生产、消费，自动就近接入，对业务透明；

02|CMQ底层架构剖析

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

按照使用场景能够将消息中间件粗略分为：高可靠和高性能两大类。CMQ主要适用于金融、交易、订单等对可靠性、可用性有较高要求的业务场景。

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

图1-某充值系统结构

CMQ总体结构如图2所示，本文重点介绍后端broker set实现原理。一般状况下一个set由3个节点组成，经过多副本保证消息的可靠性、多节点提升系统可用性。固然，能够根据业务的实际需求经过增长set内节点个数来进一步提升可靠性和可用性，CMQ set 内部结构如图3所示。

图2-CMQ总体架构图

图3-brokerset 内部结构图

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

高可靠保证

在可靠性保证方面主要包括如下三方面：生产可靠、存储（堆积）可靠、消费可靠：

生产可靠

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

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

存储可靠

CMQSET中一个节点为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所示，具体选举算法请参考raft 论文。

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

横向扩展，无限堆积

图7横向扩展

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

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

全路径消息trace

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

小结

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

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

03|CMQ对比开源rabbitMQ压测

RabbitMQ 是具备表明性的开源消息中间件，当前较多地应用于企业系统内，用于对数据一致性、稳定性和可靠性要求较高的场景中。

CMQ也是强调高可靠的消息传递，那腾讯云的CMQ，对比rabbitMQ有哪些优点？

功能升级

除了生产、消费确认机制，CMQ还提供了消费回溯功能。

用户指定CMQ保存生产消息必定天数，随后将消费回溯到该时间段内某一时间点，从该点开始从新消费。在用户业务逻辑异常时，以时间为起点的消息重放功能对业务恢复很是有帮助。

性能优化

网络IO：CMQ可以批量生产/消费消息，RabbitMQ则不支持批量生产。在大量小消息场景中，CMQ具备更少的请求数和更低的平均延迟。

文件IO：CMQ生产/消费消息是顺序写单个文件，并周期落盘存储，充分利用文件系统缓存。RabbitMQ持久化消息先入内存队列进行状态转换，而后写日志缓存，最后写消息文件和索引文件（索引文件为顺序写、消息文件为随机写），涉及三次IO操做，性能较差。

CPU：RabbitMQ的日志缓存和状态转换运算较复杂，大量耗用CPU。

可用性提高

CMQ和RabbitMQ都可以使用多台机器进行热备，提升可用性。CMQ基于Raft算法实现，简单易维护。RabbitMQ使用自创的GM算法（Guaranteed Multicast），学习难度高。

Raft协议中，Log复制只要大多数节点向Leader返回成功，Leader就能够应用该请求，向客户端返回成功。

GM可靠多播将集群中全部节点组成一个环。Log复制依次从Leader向后继节点传播，当Leader再次收到该请求时，发出确认消息在环中传播，直至Leader再次收到该确认消息，代表Log在环中全部节点同步完成。

GM算法要求Log在集群全部节点同步以后才能向客户端返回成功；Raft算法则只要求大多数节点同步完成。Raft算法在同步路径上比GM算法减小了一半的等待时间。

压测结果

经内部严格压测，在同等网络、CPU内存环境下，CMQ在保证可靠传递的前提下，QPS表现是rabbitMQ的4倍以上。

04|CMQ15年微信春晚红包案例

春晚红包活动涉及四个大型系统的联动，包括微信、微信支付、红包系统和财付通系统。如下简单介绍各个系统：

红包系统：我的红包的发、抢、拆和列表查看；

财付通系统：包括支付订单、异步入帐流水的高性能存储，用户余额和帐单的实时展现；

微信接入：确保微信用户公网接入的质量；

微信支付：在线交易的入口。

相似红包系统的分布式事务是关注的热点。举一个典型的例子，“用户A给用户B发了10元的红包”，有如下步骤：

从A账号中把余额读出来

对A账号作减法操做（减10元）

把结果写回A账号中（一次确认）

从B账号中把余额读出来

拆开A发送给B的红包，读出数值

对B账号作加法操做（加10元）

把结果写到B账号中

为了保证数据的一致性，上述步骤只有两种结果：都成功完成或者都不成功执行回滚。并且这个操做的过程当中，对A、B账号还需引入分布式锁机制来避免脏数据的问题。在微信红包这个庞大的分布式集群内，事情将变的异常复杂。

微信红包系统引入了腾讯云 CMQ 以免分布式事务增长对系统的开销。一样A用户给B用户发10元红包的场景，下面介绍引入CMQ 后的新策略。

在上述案例中的第七步，B 用户拆开了红包，红包里有 10 块钱。在作最后的入帐操做时因为当天并发压力大，常出现入帐失败的状况。

红包团队把入账失败的请求，所有转入CMQ。当B用户更新帐户余额失败时，手机客户端显示等待状态。随后入帐系统将不断从 CMQ 从新拉取重试此更新操做。CMQ 保证了这 10 元的入帐消息永远不丢，直至它被取出。

在除夕当天，用户红包的发、拆、入帐等动做，转化为了十亿级别的海量请求。若使用传统的事务方式，会放大并发压力使系统崩溃。

CMQ消息队列保证了红包消息的可靠存储、传递，实时写三份保证数据不丢。资金入帐失败时，入帐系统可异步的屡次重试，从CMQ拉数据，直到成功，起削峰填谷的做用。避免失败回滚和频繁轮询数据库等传统方式的弊端。

Q&A

Q1：创业公司怎么选择消息队列？

A1：开源的消息队列有不少，实现机制复杂，运维成本也很高，对于创业企业来讲，选择云服务商提供的消息队列无疑是最省事的，按需使用，成本很是低。

Q2：CMQ生产的消息，若是未被消费保存多久？

A2：消息在队列中最长的存活时间，从发送到该队列开始通过此参数指定的时间后，不论消息是否被取出过都将被删除；单位为秒，有效值范围60-1296000秒，也即1分钟到15天。

Q3：相比kafka有什么优点？

A3：跟kafka相比，各有侧重点，kafka更强调吞吐性能。CMQ强调是可靠传递，不丢。 CMQ的Kafka版本也即将推出，敬请期待。

Q4：CMQ消费方式是push仍是pull？仍是二者结合？

A4：当前queue的模式咱们采起的是pull的方式。后续的topic的模式会有push，能够支持push到http端，短信，邮件，和queue。

Q5：哪些队列支持pubsub？

A5： 其实CMQ支持两种产品形态：queue和topic， 对于queue来讲没有pubsub功能，topic有pubsub的能力也能把topic和queue串联起来使用，queue能够做为topic其中的一个sub方。

此分享由腾讯的张浩在极牛线上技术分享群里所分享，有意加入的技术朋友，请在极牛公众号(ji-niu)里回复“技术分享”。