腾讯云分布式高可靠消息队列CMQ架构最佳实践
Eugene
8年前
<h3><strong>目录</strong></h3> <ol> <li> <p>消息队列的使用场景、价值</p> </li> <li> <p>CMQ底层架构剖析</p> </li> <li> <p>CMQ对比开源rabbitMQ压测</p> </li> <li> <p>CMQ案例最佳实践</p> </li> </ol> <h3><strong>01|消息队列的使用场景</strong></h3> <ul> <li> <p>消息的收发解耦 ：发送方和接收方不需要了解彼此，甚至不需要知道对方的存在；</p> </li> <li> <p>屏蔽不同平台之间的差异 ：不同平台之间通过消息来实现交互，仅仅关心消息的发送和读取；</p> </li> <li> <p>削峰填谷，提高系统应对突发能力 ：发送消息端永远不会堵塞，突发消息缓存在CMQ SERVER 端，消费者按照实际能力读取消息；</p> </li> <li> <p>一次生产多次消费 ：一条消息可以被多钟类型消费者订阅，生产着仅需生产一次即可；</p> </li> <li> <p>跨IDC/WAN传输 ：CMQ支持消息在不同IDC、城市进行生产、消费，自动就近接入，对业务透明；</p> </li> </ul> <h3><strong>02|CMQ底层架构剖析</strong></h3> <p>在分布式大行其道的今天，我们在系统内部、平台之间广泛运用消息中间件进行数据交换及解耦。CMQ是腾讯云内部自研基于的高可靠、强一致、可扩展分布式消息队列，在腾讯内部包括微信手机QQ业务红包、腾讯话费充值、广告订单等都有广泛使用。目前已上线腾讯云对外开放，本文对CMQ 核心技术原理进行分享介绍。</p> <p>按照使用场景可以将消息中间件粗略分为：高可靠和高性能两大类。CMQ主要适用于金融、交易、订单等对可靠性、可用性有较高要求的业务场景。</p> <p>如图1以腾讯充值系统为例，该充值系统通过CMQ 对交易模块、发货部分、结算系统进行异步解耦、削峰填谷，一方面大大降低了模块间耦合度，另一方面减轻了大量突发请求对后端系统的冲击。在月初充值该系统一天经过CMQ转发的消息超过十亿条，每秒峰值超过10w，最高时有数亿条消息通过CMQ的堆积能力缓冲了对后端消费模块的压力。</p> <p style="text-align:center"><img src="https://simg.open-open.com/show/9a74ae557aa3546546db77b43665f2c6.png"> 图1-某充值系统结构</p> <p>CMQ整体结构如图2所示，本文重点介绍后端broker set实现原理。通常情况下一个set由3个节点组成，通过多副本保证消息的可靠性、多节点提高系统可用性。当然，可以根据业务的实际需求通过增加set内节点个数来进一步提高可靠性和可用性，CMQ set 内部结构如图3所示。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/b05f4c1f2cc19261ccb6f582394e591a.png"></p> <p style="text-align: center;">图2-CMQ整体架构图</p> <p style="text-align:center"><img src="https://simg.open-open.com/show/fcba8de070b4a2718df1f915eb3d4391.png"></p> <p style="text-align:center">图3-brokerse t 内部结构图</p> <p>下面分别中数据高可靠、强一致，系统可用性，可扩展、消息全路径追踪方面分别介绍。</p> <h2><strong>高可靠保证</strong></h2> <p>在可靠性保证方面主要包括以下三方面：生产可靠、存储（堆积）可靠、消费可靠：</p> <ul> <li> <h3><strong>生产可靠</strong></h3> </li> </ul> <p>如上图3所示，客户端生产的消息在set 中超过半数的broker 刷盘成功后会返回确认消息告知生产消息成功。如果在一定时间之内客户端没有收到确认信息需要重试来确保消息发送成功。</p> <p>可靠生产带来的一个问题就是消息的重复，在网络异常等情况下很可能CMQ broker已经存储消息成功只是确认包在网络上丢失了，这样客户端重试生产后，在broker上存在两条重复的消息。考虑到消息去重开销较大，目前消息的幂等性需要业务逻辑来保证。</p> <ul> <li> <h3><strong>存储可靠</strong></h3> </li> </ul> <p>CMQSET中一个节点为leader 其他节点为follower，leader 负责所有消息的生产消费。当生产消息到达leader 节点后，通过raft 一致性模块将请求顺序写raft log 并同步刷盘，同时将构造好的raft log 按顺序通过网络发送到其他follower节点，follower节点同步刷盘并返回成功。当leader 收到过半数的节点同步成功信息后将此条请求提交到mq 处理状态机，由mq 状态机将请求应用到相应queue。大致逻辑图4所示。</p> <p style="text-align:center"><img src="https://simg.open-open.com/show/7c2fba135f1ce08054ea71b96bfb9177.jpg"> 图4-数据存储原理示意图</p> <p>由此可见，对于返回客户端成功的消息至少是分别在两个节点磁盘上存储成功的，这就将磁盘故障引起的数据丢失大大降低。另外数据在磁盘上存储时会将检验结果一同记下来，消费者在消费数据之前CMQ broker 会进行比较，确保消息是完整有效的。</p> <ul> <li> <h3><strong>消费可靠</strong></h3> </li> </ul> <p>消费者拉取消息时会指定当前消息的隐藏时间，在隐藏时间内消费者比较显式的对消息进行确认删除，如果超过隐藏时间没有主动删除，此条消息将重新对外可见，可以继续消费。</p> <p>显式确认删除消息是为了防止消息在投递、处理过程中异常而导致的消息丢失。</p> <p>对于消息的确认信息 CMQ broker的处理逻辑和生产消息过程类似，也是一个写入的过程，不同的是此时写入的数据的内容是msgid 和消息状态。</p> <h2><strong>强 一致实现</strong></h2> <p>假如一个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 拥有相同的已经返回确认给用户的全量数据视图，数据是强一致的。</p> <p>对于A 和 B C 所在的网络发生分区的情况（如图5），由于leader A得不到set 中过半节点的回复所以不能处理请求，B C在选举超时后会选举出一个新的leader ，CMQ的接入层会自动进行切换。Raft 算法保证新leader 同样具有完成的数据视图。</p> <p style="text-align:center"><img src="https://simg.open-open.com/show/000f6d61ecfeb1d76ed1ae662ceeb540.jpg"></p> <h2><strong>可用性保证</strong></h2> <p style="text-align:center"><img src="https://simg.open-open.com/show/e16a710ce36d386eeb40e312820902e9.jpg"></p> <p>如上文所述，master 负责所有消息的生产消费，当master 故障时SET中其他follower节点会自动选举出一个新leader，客户端请求会自动重定向到leader节点，RTO和配置的选举超时时间有关，目前是在5s左右。大致过程如上图6所示，具体选举算法请参考raft 论文。</p> <p>CMQ单个set 在CAP理论中优先保证了CP，当SET中过半数节点都正常工作时，才能进行消息的生产消费。对于SET多个节点同时故障的不可用情况，CMQ强大的监控调度能力能够快速对queue进行调度迁移恢复服务，将不可用时间降到最低。</p> <h2><strong>横向扩展，无限堆积</strong></h2> <p style="text-align:center"><img src="https://simg.open-open.com/show/962a6389464c1459458b899c4d6d06a4.jpg"></p> <p style="text-align: center;">图7横向扩展</p> <p>上文中SET的概念对用户来说是透明无感知的，CMQ controller server 根据set的负载情况实时对queue进行调度搬迁。如果某个queue的请求量超过当前set的服务阈值，controller server 可以将queue 路由分布到多个set 上来提高并发量，对于需要海量堆积的服务来说可以通过路由调度来提升堆积上限，理论上可以达到无限堆积。</p> <p>目前CMQ只能保证特定情况下消息的严格有序，例如需要保证单个生产进程、单个消费进程，或者queue的消费窗口设定为1等条件。</p> <h2><strong>全路径消息trace</strong></h2> <p>CMQ系统中，一条消息的完整路径包含生产者、broker、消费者三个角色，每个角色处理消息的过程中都会在trace 路径中增加相关的信息，将这些信息汇聚即可获取任意一条消息的状态和当前经过的完整路径，从而为生产环境中的问题排查提供强有力的数据支持。大大降低了业务定位问题的难度。</p> <h2><strong>小结</strong></h2> <p>CMQ是基于raft 算法来保证数据高可靠、强一致的分布式消息队列，主要服务于订单、交易类业务场景。消息的幂等性需业务侧来保证，在特定情况下可以保证消息严格有序。</p> <p>对于更侧重高性能、高吞吐量业务需求，腾讯云由另外一个消息引擎来提供服务，在协议上同时兼容kafka，很好的满足了大数据场景，具体原理请留意后续文章介绍。</p> <h3><strong>03|CMQ对比开源rabbitMQ压测</strong></h3> <p>RabbitMQ 是具有代表性的开源消息中间件，当前较多地应用于企业系统内，用于对数据一致性、稳定性和可靠性要求较高的场景中。</p> <p>CMQ也是强调高可靠的消息传递，那腾讯云的CMQ，对比rabbitMQ有哪些优势？</p> <ul> <li> <p><strong>功能升级</strong></p> </li> </ul> <p>除了生产、消费确认机制，CMQ还提供了消费回溯功能。</p> <p>用户指定CMQ保存生产消息一定天数，随后将消费回溯到该时间段内某一时间点，从该点开始重新消费。在用户业务逻辑异常时，以时间为起点的消息重放功能对业务恢复非常有帮助。</p> <ul> <li> <p><strong>性能优化</strong></p> </li> </ul> <p>网络IO：CMQ能够批量生产/消费消息，RabbitMQ则不支持批量生产。在大量小消息场景中，CMQ具有更少的请求数和更低的平均延迟。</p> <p>文件IO：CMQ生产/消费消息是顺序写单个文件，并周期落盘存储，充分利用文件系统缓存。RabbitMQ持久化消息先入内存队列进行状态转换，然后写日志缓存，最后写消息文件和索引文件（索引文件为顺序写、消息文件为随机写），涉及三次IO操作，性能较差。</p> <p>CPU：RabbitMQ的日志缓存和状态转换运算较复杂，大量耗用CPU。</p> <ul> <li> <p><strong>可用性提升</strong></p> </li> </ul> <p>CMQ和RabbitMQ都能够使用多台机器进行热备，提高可用性。CMQ基于Raft算法实现，简单易维护。RabbitMQ使用自创的GM算法（Guaranteed Multicast），学习难度高。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/18c006b6f0c263f4dd77cf2f7bef7846.jpg"></p> <p>Raft协议中，Log复制只要大多数节点向Leader返回成功，Leader就可以应用该请求，向客户端返回成功。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/e43640c5c5fe67bea65dc9118302988e.jpg"></p> <p>GM可靠多播将集群中所有节点组成一个环。Log复制依次从Leader向后继节点传播，当Leader再次收到该请求时，发出确认消息在环中传播，直至Leader再次收到该确认消息，表明Log在环中所有节点同步完成。</p> <p>GM算法要求Log在集群所有节点同步之后才能向客户端返回成功；Raft算法则只要求大多数节点同步完成。Raft算法在同步路径上比GM算法减少了一半的等待时间。</p> <ul> <li> <p><strong>压测结果</strong></p> </li> </ul> <p>经内部严格压测，在同等网络、CPU内存环境下，CMQ在保证可靠传递的前提下，QPS表现是rabbitMQ的4倍以上。</p> <p>04|CMQ15年微信春晚红包案例</p> <p><img src="https://simg.open-open.com/show/6622ddc0780438049ea70d5f7c07939d.jpg"></p> <p>春晚红包活动涉及四个大型系统的联动，包括微信、微信支付、红包系统和财付通系统。以下简单介绍各个系统：</p> <p><strong>红包系统：</strong>个人红包的发、抢、拆和列表查看；</p> <p><strong>财付通系统：</strong>包括支付订单、异步入账流水的高性能存储，用户余额和账单的实时展示；</p> <p><strong>微信接入：</strong>确保微信用户公网接入的质量；</p> <p><strong>微信支付：</strong>在线交易的入口。</p> <p>类似红包系统的分布式事务是关注的热点。举一个典型的例子，“用户A给用户B发了10元的红包”，有以下步骤：</p> <ol> <li> <p>从A帐号中把余额读出来</p> </li> <li> <p>对A帐号做减法操作（减10元）</p> </li> <li> <p>把结果写回A帐号中（一次确认）</p> </li> <li> <p>从B帐号中把余额读出来</p> </li> <li> <p>拆开A发送给B的红包，读出数值</p> </li> <li> <p>对B帐号做加法操作（加10元）</p> </li> <li> <p>把结果写到B帐号中</p> </li> </ol> <p>为了保证数据的一致性，上述步骤只有两种结果：都成功完成或者都不成功执行回滚。而且这个操作的过程中，对A、B帐号还需引入分布式锁机制来避免脏数据的问题。在微信红包这个庞大的分布式集群内，事情将变的异常复杂。</p> <p>微信红包系统引入了腾讯云 CMQ 以避免分布式事务增加对系统的开销。同样A用户给B用户发10元红包的场景，下面介绍引入CMQ 后的新策略。</p> <p>在上述案例中的第七步，B 用户拆开了红包，红包里有 10 块钱。在做最后的入账操作时由于当天并发压力大，常出现入账失败的情况。</p> <p>红包团队把入帐失败的请求，全部转入CMQ。当B用户更新账户余额失败时，手机客户端显示等待状态。随后入账系统将不断从 CMQ 重新拉取重试此更新操作。CMQ 保证了这 10 元的入账消息永远不丢，直至它被取出。</p> <p>在除夕当天，用户红包的发、拆、入账等动作，转化为了十亿级别的海量请求。若使用传统的事务方式，会放大并发压力使系统崩溃。</p> <p>CMQ消息队列保证了红包消息的可靠存储、传递，实时写三份保证数据不丢。资金入账失败时，入账系统可异步的多次重试，从CMQ拉数据，直到成功，起削峰填谷的作用。避免失败回滚和频繁轮询数据库等传统方式的弊端。</p> <p>Q&A</p> <p>Q1： <strong>创业公司怎么选择消息队列？</strong></p> <p>A1：开源的消息队列有很多，实现机制复杂，运维成本也很高，对于创业企业来说，选择云服务商提供的消息队列无疑是最省事的，按需使用，成本非常低。</p> <p>Q2： <strong>CMQ生产的消息，如果未被消费保存多久？</strong></p> <p>A2：消息在队列中最长的存活时间，从发送到该队列开始经过此参数指定的时间后，不论消息是否被取出过都将被删除；单位为秒，有效值范围60-1296000秒，也即1分钟到15天。</p> <p>Q3： <strong>相比kafka有什么优势？</strong></p> <p>A3：跟kafka相比，各有侧重点，kafka更强调吞吐性能。CMQ强调是可靠传递，不丢。 CMQ的Kafka版本也即将推出，敬请期待。</p> <p>Q4： <strong>CMQ消费方式是push还是pull？还是两者结合？</strong></p> <p>A4：当前queue的模式我们采取的是pull的方式。 后续的topic的模式会有push，可以支持push到http端，短信，邮件，和queue。</p> <p>Q5： <strong>哪些队列支持pubsub？</strong></p> <p>A5： 其实CMQ支持两种产品形态：queue和topic， 对于queue来说没有pubsub功能，topic有pubsub的能力也能把topic和queue串联起来使用，queue可以作为topic其中的一个sub方。</p> <p><br> </p> <p> </p> <p> </p> <p> </p> <p>来自：http://mp.weixin.qq.com/s?__biz=MzI5MDAzODY5OQ==&mid=2653095328&idx=1&sn=f05a8765ad4694ee1c8c9748ba39fbd8&chksm=f7f25364c085da7269832c931a48e2550c9bfcaf6df9adcfa1c3b010031b697c79894ae99410&scene=0#wechat_redirect</p> <p> </p>