Raft 算法原理及其在 CMQ 中的应用(下)

Raft 算法原理及其在 CMQ 中的应用(下)

作者:陈云 2017-09-01 15:49:41
开发
开发工具
算法 早期我们在rabbitmq的基础上搭建了一套可扩展消息中间件CRMQ1.0,由于rabbitmq的GM同步算法在性能等方面存在瓶颈,所以自研了基于raft算法的内部版本CRMQ2.0和腾讯云CMQ,在保证强一致高可靠的前提下,性能和可用性都有显著提升。

三 Raft在CMQ中的应用

早期我们在rabbitmq的基础上搭建了一套可扩展消息中间件CRMQ1.0,由于rabbitmq的GM同步算法在性能等方面存在瓶颈,所以自研了基于raft算法的内部版本CRMQ2.0和腾讯云CMQ,在保证强一致高可靠的前提下,性能和可用性都有显著提升。实现上采用了生产Confirm + 消费Ack机制保证消息不丢失,Confirm和Ack机制均通过raft来保证。生产的消息通过Raft转为Entry同步到大多数节点并提交,完成后各节点状态机应用该Entry,将消息内容写入磁盘,之后由Leader节点回复客户端Confirm,表示消息生产成功。消费时客户端从Leader节点拉取消息,消费完成后通过Ack命令通知服务端消息已消费可删除,Ack请求经Raft同步后,各节点应用该请求,之后消息被删除不会再投递。下面介绍详细过程:

生产流程:

1)生产者将生产消息的请求发往Leader的Raft模块。

2)Raft模块完成Entry的创建和同步。

3)大多数节点上持久化并返回成功后Entry标记为Committed。

4)所有节点的State Machine应用该日志,取出实际的生产请求,将消息内容写入磁盘,更新ApplyIndex。该步骤不需要刷盘。

5)Leader回复客户端Confirm,通知生产成功。

6)如果此后机器重启,通过raft日志恢复生产消息,保证了已Confirm的消息不丢失。

消费流程:

1)消费者从Leader节点拉取消息。

2)Leader收到后从磁盘加载未删除的消息投递给客户端。

3)客户端处理完成后Ack消息,通知服务器删除消息。

4)Ack请求经Raft同步后标记为Committed。

5)各节点状态机应用该日志,将消息对应的bit置位,将其设置为已删除并更新ApplyIndex。

6)通知客户端删除成功。

7)如果机器重启,通过Raft日志恢复Ack请求,保证了已删除的消息不会再投递。

快照管理:

快照管理与业务紧密相关,不同系统快照制作的成本差异很大,CMQ中快照的内容十分轻量,一次快照的耗时在毫秒级,平均5min创建一次,各节点独立完成。实现上内存中维护了一份动态的快照,制作快照时首先拷贝出动态快照的副本,之后处理流继续更新动态快照,用拷贝出的副本创建快照文件,不影响实际的处理流。快照具体内容包括:

1)term:快照对应Entry的term (参照算法)

2)index:快照对应Entry的 index (参照算法)

3)node_info:Entry时的集群配置信息。

4)topic info:每个队列一项。CMQ中同一队列生产的消息顺序写入,分片存储,因此只需记录***一个分片的状态(分片文件名,文件偏移量)。

5)queue info:每个队列一项。CMQ中采用bitmap记录消息的删除情况,在内存中维护,在制作快照时dump到快照文件。

可靠性:业界统一的衡量标准为RPO(Recovery Point Objective),反映故障时数据恢复完整性的指标。由于只有提交的日志才会被应用到状态机,且raft日志在写入时会强制刷盘,所以故障重启后通过快照+raft日志即可恢复,不会丢失数据,RPO=0。不过,如2.7节所述,Leader故障时可能会产生重复数据,需要通过幂等性保证或去重机制来解决该问题。

可用性:业界统一的衡量标准为RTO(Recovery Time Objective),反映故障时业务恢复及时性的指标。follower故障对系统没有影响(RTO=0),leader故障时其他节点通过自发选出新leader,而且CMQ中前端具备自动重连功能,当连接断开后会自动寻找新leader,系统不可用时间大大降低。目前CMQ中配置的选举超时时间为2s~4s,在不考虑选举冲突的前提下,RTO上限为4s。

在CMQ中,Leader通过与Follower的心跳判断自己是否已网络分区,当检测到分区时(大多数节点上次心跳回复时间距现在超过2s),主动断开前端连接,前端发现后会自动寻找新Leader。这段时间内客户端请求会超时,在连上新Leader后,客户端重试之前超时的任务,后续请求恢复正常。

四 Raft算法性能优化

Raft算法的性能瓶颈主要有两方面:

1) 每次日志写入后都需要刷盘才能返回成功,而刷盘是一个比较耗时的操作。

2) 由于算法限制,所有的请求都由Leader处理,不能做到所有节点皆可提供服务。

针对以上两个问题,我们做了以下优化:

1)Batch Processing:在请求量较大时,并不是每一条日志写入都刷盘,还是累积一定量的日志后集中刷盘,从而减少刷盘次数。对应的,在同步到Follower时也采用批量同步的方式,Follower接收后将日志批量写盘。

2)Multi-Raft: 进程中同时运行多个raft实例,机器之间组建多raft 组,客户端请求路由到不同的group上,从而实现多主读写,提高并发性能。通过将leader分布在不同机器上,提高了系统的整体利用率。

3)Async-rpc: 在日志同步过程中采用同步rpc方式,在一端处理时另一端只能等待,性能较差。我们采用异步的方式使得leader端发送和Follower端处理并发进行。发送过程中leader端维持一个发送窗口,当待确认的rpc数达到上限停止发送,窗口值上限:


在与同属于高可靠(多副本同步刷盘)的Rabbitmq性能对比中,相同压测场景下CMQ速度可以达到RabbitMQ的四倍左右。

以下为TS60机器1KB消息大小时性能数据:

测试中CMQ采用单Raft组方式以保证测试公平性。监控显示CPU、内存和网卡均未达到瓶颈,系统瓶颈在磁盘IO,iostat显示w_await远大于svctm。主要原因在于刷盘耗时,造成写操作排队等待。

实际生产环境CMQ中我们将raft组和磁盘进行绑定,实现raft组之间磁盘的隔离,一方面保证了磁盘的顺序读写,另一方面充分利用机器的cpu 、内存、网卡等资源。

五 通用Raft库

CMQ中完整实现了Raft算法并解决了很多细节难点。考虑到分布式系统设计的复杂性,如果开发者只专注于业务相关部分,将可以显著降低开发难度,提高系统的质量,所以我们将CMQ中的raft部分以库的方式独立出来,使用者用它即可搭建一套强一致高可用分布式系统。目前该库已经完成基线版本开发并在部门落地使用,验证完成后会陆续开放给更多业务使用。

六 总结

消息中间件通常分为高可靠版本和高性能版本两种。CMQ是一款金融级的高可靠分布式消息中间件,通过raft保证了消息的可靠不丢失。同时在性能和可用性方面相比竞品都有显著提高。此外,我们自研的高性能版本的消息中间件ckafka也已在腾讯云上线,***兼容kafka0.09~0.10版本客户端,关于CKafka的具体技术介绍请关注后续技术文章。

Raft算法强调了Leader的地位,选举和日志同步都是围绕Leader展开。由Leader负责处理所有请求保证了系统的强一致性;Leader选举和日志同步算法保证了数据的可靠不丢失;此外上述步骤只需要大多数正常互联即可,从而极大提高了系统的可用性,少量机器故障不受影响。不过,所有请求由Leader处理并没有充分利用从节点的资源,目前google的Spanner已支持从从节点读取,后续我们也会在这方面作更进一步的研究。Raft算法易于理解和工程化,相信未来会应用在越来越多的分布式系统中。

原文链接:https://cloud.tencent.com/community/article/937437

【本文是51CTO专栏作者“腾讯云技术社区”的原创稿件,转载请通过51CTO联系原作者获取授权】

戳这里,看该作者更多好文

责任编辑:武晓燕
来源: 51CTO专栏
Raft
算法
CMQ