消息队列专题part5(RocketMQ工作原理)原创

呃，接下来我们来看M的一些，首先来做对M能一简介啊，M其实左边这是出来它的一些功能。啊，这种淡蓝色的这种呢，其实是它的一些基础的一些能力吧，啊，然后呢，它的绿色的这些呢，其实是它的一些特性能力，然后右边的这种啊，其实是它的一些高阶的能力，那其实它包含的能力呢，主要有消息的过滤啊，它可以支持按照探克或者按照哈希以及按照自定义的属性来进行消息的过滤，然后在消息可靠性方面呢。它可以通它支持可以通过同步双写的方式来保证不丢失，同时呢。在在4.5以后，它也支持了通过啊版本的一个啊rap算法来去保证数据的一个可靠性，然后在消息重试和从头方面的话，其实它分为两类，第一类的话就是消费者这边的一个啊消息的消费，消息失败的一个重试，以及生产者同步生产消息失败之后的一个重头，啊一步生产失败的一个重试，然后事物消息的话，他这边支持啊分布式事物的一些能力，然后呢，将本地事物和发布定义到一个全局事务中，保证事物的一个一致性，那还有延时消息的话，就是它支持延时消息，用来实现延时队列的一些功能。

流量控制的话，它分为两种啊，第一种的话是当博能力达到瓶颈的时候呢，进行生产者的一个流控啊，第二种的话就是当消费者啊能力达到一个瓶颈的时候呢，他进行一个消费者的一些流，其实这些呢是它的一些核心的一些能力啊，接下来我们来看那rie MQ它整体的一个架构啊，它的整体架构呢，跟其实跟前面介绍的内容大同小异，就是左边呢是生产者，生产者的一集群啊，然后呢，中间是我们的一个broke的一些信息，然后右边呢，是我们的消费者的一个集群啊，多个消费者啊，那上面呢，其实在。

的集，集群包括它的啊，每个topic对应的那些对列，以及broke上面的一些啊，这集群原数据信息。啊，这就是其实它整个的一个一个架构，其实跟卡夫卡一呃大同小异，只不过卡夫卡里面的话，它其实采用来去做啊，服务的一些原信息的一些配置和维护啊这个to。时在一个是个集群，那内部呢，它就是会分成多个小群啊，就是它的一个一个master master1队就表示的是一对群啊，这是一对集群，这是一堆群，它其实是由啊多组小集群拼在一起购置的一组大集群，那包括内部主要就负责消息的一些存储，查询以及服务的包可用等等。

啊，接下来我们其实也会从三个方面来看整个M的一些吧，第一个是从M的一个单的一个环境来看啊，第二部分是从多实力的环境，集训环境来看啊，单实力环境我们主要去重点关注它的内部的一个啊，就是存储模型的一些设计，以及它的消息的查询等等，然后在多实例环境下面的话，主要关注它的数据的一些啊，同步方式以及它集群的一些，呃，支持哪些集群，它的数据的一些啊，如何同步等等。呃，本节呢，我们来重点介绍一下MQ的单实力环境的一些内容，然后单实力环境的话，其实也是跟卡夫卡一样，我们是从。

啊，以下四个内容来进行介绍，那第一部分内容的话就是介绍啊IEMQ，它主体的一个模型以及功能，第二部分呢，介绍啊rock MQ它的一个消息存储和检索的一些内容，第三部分呢，介绍MQ它的呃消息清理以及最后介绍消息消息的一个消费模型。啊，首先我们来看rocket MQ它的一个主体模型，其实它的主体模型呢，上面这一层其实跟卡夫卡以及其他的。消息队列都一样，我们重点关注的是消息队列，它内部的一个。实现，然后在这边的话，IEMQ，首先它的消息内部呢，是可以支持按照take或者是来进行一个消息的过滤，那我们看在它内部的话，同样以一个topic，然后是啊，三个分区，单副单副本的这样一个三组。

踢球来看的话。首先rockie MQ它的分区呢，是在它的分区会是在呃整个的一个呃大的集群绿部呢，又会分成啊三个小的集群，那三个小集群呢，首先这个topic会做一个topic的一个分片啊，分散在每个小集群里面，每个小集群里面呢，又会按照message q去啊做一个拆，嗯做一个分片，所以它的分片呢是二级，这个跟卡夫卡不一样，所以我们来看那每一个啊到每一个集群内部的时候啊，那每一个集群内部master节点的时候呢，啊，它内部的数据它是这样组织的啊，首先呢，它规定了就是呃一个呃一个集群里面一个master啊，它会管理，它上面可以去管理多个topic的信息，而在这个时候呢。啊，它是规定了啊，一个实例里面，一个节点上面啊，所有的topic的数据呢啊，全部是存在啊叫做topic log里面，这个跟卡卡是不一样，卡夫卡是啊，它是所有的数据呢，是按照Q存在这个啊每一段里面，而rocket MQ它是所有的topic的数据，所有的数据全部存在一个。com里面，也就是说同一时间一个实例上面只有一个。com文件是在被写的，然后呢，在这种情况下面的话，那不同的topic它的数据呢，需要去啊怎么来分离的呢？啊，其实这一块也就是通过message q来分离的啊，它的所有的。

它的所有的数据消息据存在，那所面它就会一个分离，那分离的时候，每一个topic会有它自己对应的多个message q队列，那每一个队列里面呢，从的就是其实就是这一条消息啊，这条消息在com log里面的写在什么位置，以及它的长度是多少啊，以及它这个消息的一个tag，这个我们后面会看到它的具体的格式，所以它啊，它这个MQ里面呢，它也是啊，这每一段呢，每一段里面做的就是一个索引啊，这就是整个它的一个特点，同时呢，在呃。

Rocket MQ里面它每个啊实例上面又有一个一点击X文件啊，这个点击X文件呢，它也是它里面呢，主要存储的就是啊是一些实间信息，以及按照啊K进行哈希的一些信息啊实际上是将啊一个哈希map呢啊，它不存储在了一个磁盘上面，就是这样一个结构，后面我们会详细看到啊，那在这一块的话，其实它整个文件的布局上面很有特点啊，它所有的就不管是你的message q里面的每一个啊索引文件，还是说这个点ex的文件以及com log，它都是固定大小的啊，那些固定大小的情况下的话，它就能够啊在上层通过m map去啊内存映射，然加速它的读，同时在写的时候呢，它是顺序写磁盘的，所以读写的性能啊相对都很高，然后在Q里面的这每一项，所以项呢，它也是按照定去设计的啊，那在这种情况下面的话，能够很快的加速一个通过啊冲数。

可以用磁盘阅读的一个能力，然后呢，提升一个啊，所以访问的一个效效率和性能啊，这就是整个啊，如果给MQ，其实它主体模型里面，它的一个存储模型上面整体的一个特点吧。我们接下来来看MMQ它里面的哦，Rockie MQ它里面的一个消息存储的类型，其实这张图呢，就对于我们前面提到的啊，整个的一个过程，生产者生产的消息呢，会丢到我们的这一个实例上面的com log里面去啊，数据写进去之后呢，那其入每一个每一个这个message q里面队列里面呢，存储的就是这条消息啊，在这个com log里面的一个写入的一个位置，以及呢，它的一个长度是大小是多少，以及呢，它的一个啊，这个消息对应的一个哈希tag是多少啊，其实就对应的是其实这边的这一个，这一个ma q里面的组，每一项呢，其实就对应的是这样一个结构啊。com log的一个偏移量，写入的一个偏移量啊一个啊这个数据的一个长度啊，通过偏移量加长度，我们就可以读取到这一条数据，然后呢，它消息的一个tag的一个哈，Code值是多少啊，通过这个可以来做一个消息的一个过滤。

啊，这就是整个它的一个特点啊，我们可以看到在它的com log呢文件，文件是固定大小的，然后呢，通过上层，通过m map去映射做一个图啊，其实这些这这张图呢，可以在呃，Rockie MQ它的官网的一个GI up文档上面可以找到设计文档这里面啊其实这张呢，是它同样是以同样一个视角，只不过是另外一个维度来展示出来的，它的一个特点就是写都是写这同一个文件啊，一台节点上面同一世界只有一个comlo来处理一个写的一个的一个，然后其所以这里面其他每一个Q里面，所里面存是的一些偏移量，就是索引信息啊。

那接下来我们再来看ma rocket MQ它里面的一个消息检索的一些一个能力吧，其实在Macy，其实在rocket MQ里面，它的消息检索呢啊，其实它有三种方式，那第一种的话就是按照它的message ID啊，每一条消息都有一个message ID啊，第二种是按照message k来去查询，第三种的话就是按照消息的一个偏移量来查询，我们首先来看那message ID呢，其实它给如给MQ里面，它给每一条消息生成的一个message ID呢，它是按照啊下面的这种格式，就是它的这个message ID，其实是由三部分信息拼成啊，就是当前这一个的一个IP信息，以及它的一个端口信息，然后再加上这条消息写在了当前的一个移位置。啊，通过这三部分信息生成的服务端生成的这个message ID呢，那根据message ID来查这个消息的数据的时候呢，其实第一步就是首先解析出来这个broke的IP和port，解析出来之后呢，那第二步就会去啊，我这个消我这个broke去发请求，然后呢传入这个偏移量，然后呢，这个broke呢，就会根据这个偏移量去找到对应的一个啊com log的位置，然后呢，读取这样一个数据啊就是这样一个过程，那第二个的话就是按照message k，按照message k呃和第三步按照消息内偏移量去。

消费的时候呢，其实都是会利用的这样一个它的index文件，它的index文件的格式呢，其实像左边这张图描述的一样，其实就是一个呃，可以理解成一个大的一个哈希map，它的哈希冲突的时候呢，是采用啊我们的一个啊链拉链法，就是所有的哈希相同哈希值的元素呢，通过一个列表来串联在一起，关联在一起，只不过它的这个哈希map呢，它是存储在磁盘上面，也是一种比较新仪的一种做法啊，比较有特色啊，那这里面它是怎么去关联的呢？我们来看它其中的每一项呢，其实啊，首先第一个呢，就是它开指的它是由四段组成，这其中的啊集中存的，那这四段呢，第一第一个就是K的这个哈希值啊，然后呢，根据这个K呃，哈希值匹配出来之后的话，它里面再调的是这条消息写入comlo的一个位置，然后呢，什么时间写入的时间戳啊，最后呢，有一个这一条，同时这一利下下一条。

土相同哈希值的写在这条消息的什么位置啊，所以它这边的话，其实是整个呢，这是上面是一个就是槽的一个哈希槽的一个表啊，它里面呢，可以定义了500万个哈希槽，那这500万个哈希槽那。嗯，可以容纳很多的数据，那整个这个它能存储的数据呢，就是两千万条啊，这个文件的大小呢，是400兆，根据它文档上面是说，然后呢，也是一个固定大小啊上传采用m map去加速度，我们可以在这边可以看到它的数据写入的时候呢，是这样子啊，比如说首先这一个这一条元素，它的哈希值呢，命中到这一个槽上面，那首先就记入到这个地方，记录完了之后，另再来一条元素的话啊，它的哈希又会命入它，然后这那这时候的话就往当前的这个节点的啊，那个ex的index呢，复制成前一个的，然后同时呢，把它的一个下标设置的这个位置啊，就是一次按照这种方式去存的，所以这是它整个的一个文件的一个啊查询的一个逻辑，所以这里面这个文件呢，它其实是按照一个啊文件命名是按照它的一个时间戳来命名的，这样子的话，也可以根据一个时间范围来去啊，检索和消费我们的一个消息啊，这就是整个rockie MQ它的一个消息检索的一些内容。

啊，然后它里面消息过滤这一块的话，其实它啊支持几种方式，那第一种的话最简单就是按照这个tag来过滤啊，我一个topic，我可以设置tag，那每一条我要在消费者消费的时候呢，它可以指定说我要这个topic下面什么tag的一些数据啊，就是按照tag过滤。第二种的话就是它支持按照来过滤，那按照这个circlel过滤的话，它里面啊涉及到circle的一些编译以及执行以及解析等等的内容，这一块的逻辑呢比较复杂，我们就不展开细说了，感兴趣的可以去看搜一些资料，或者是看一下他官方文档的介绍，那第三部分呢，就是呃，也消费者也可以按照自定义的一些属性来进行过滤啊，其实整个的过滤呢啊，本质上就是在这个。

还是依靠它的一个媒Q里面的每一项啊，那每一项里面其实是包含了一个哈希值的，一个哈希值啊T的哈希code值，然后它在过滤的时候呢，根据这个哈希code的值过滤出来相等的啊，相等的那个消息，然后在下在消费者正边去处理的时候呢，同时还需要去根据这个啊哈奇库的值相等，同时呢，要去判定这个tag值是不是相等，再做二二次的一个过滤啊，这是它的一个特点。

啊，其实介绍完它的这两块内容之后，我们来看啊，如IEMQ，其实它呃，它的一个刷盘的一些内容，其实它刷盘的时候呢，啊，它是分为两种啊，一种的话就是同步刷盘，那同步刷牌就是啊消费者生产者生产一条消息发给博克，博克内部呢啊写我们的一个堆内存上面，那堆内存上面呢，最终又会将这个消息呢，啊写到我们的一个虚拟内存里面，虚拟内存里面呢，最终就会将它，啊我们通过上层呢，手动调用这样一个flash接口。啊，或者FC接口啊，将它刷到磁盘上面，最后呢，再去响应我们的一个，嗯，生产者，那这一系列过程呢，其实就是一个同步刷出的动作，那同步刷盘呢，其实可以看到它的一个啊时间呢，其实是比较比较长的，那我们相对应的就是一个异步刷盘，异步刷盘呢，其实就是将这样一条数据呢，写入到最终写入到我们的虚拟内存之后呢，那最终啊，再由异步的线程去进行一个刷盘，这个异步线程可以是啊操作系统内部的，呃，内核线程也可以是用户线程上层做的一些定时任务啊，异步线程去做异步的双盘操作。

啊，最后呢，我们再来介绍一下啊，IEMQ它的一个啊，消息的一个消费模型啊，其实他的消息消息的消费模型上面的话，其实跟前面的那个卡夫卡其实有点类似，那首先第一步的话，其实它的呃。队列模型这一块是差不多的，然后呢，我们来看它的发布啊，地阅模型其实也是一条消息啊，交给交给队列之后，那对于上层的，对于下游的一个消费者而言，其实它里面支群支持集群模式和广播模式啊，集群模式呢，其实就是啊，一个集群内部那这些啊，它会包含多个消费者，那多个消费者呢，他在消费上游的数据的时候呢，也是一个消费者可以消费多个messageq的数据，但是一个message q呢，同一时间只能被一个消费者去消费，而广播模式的话，那就是啊，将上游的一个消息呢，可以同时分给分发给多个消费者去啊同时消费也就是一个广播的这种模式啊，这其实也呃，也跟卡夫卡里面的一个消费者组的这个概念是一致的啊，所以这是在卡rie MQ里面，这一块内容跟卡夫卡大同小异。

啊，这就是我们这一节介绍的一些M的单实环境下面的一，然后。下一节我们来重点介绍MQ的实力环境、集训环境面的一些容。啊，我们来看现在来看rocket MQ它的一个数据复制和故障转移的一些内容吧。其实在rocket MQ里面啊，它的架构呢，就是一直在提，就是4.5以前呢，其实它支持的是集群的一些架构，主要呢，就是呃，一些储存的架构，而在4.5以后呢，它同时也有新增加了一种啊，就是扩展版的rapft。

底层是rap的算法去支持的一套啊强一致性的架构，那为什么它会新增加这一个呢？其实理由有两点啊，第一个的话就是在最初的时候，它的主存架构模式下啊，以同步的复制的时候呢，它其实存在一个问题，就是当主节点啊挂掉之后呢，它不能做到一个自动的故障转移啊，然后这时候的话，其实在运维上面的话极不友好，同时呢啊，对于生产环境上面的一个啊，故障的切换时间呢，会往往会很长啊，那同时呢，它就需要去解决这个问题，也就是怎么样能够达到一个自动的故障转移啊，这是第一个它要解决的问题。第二个的话就是在于一些金融场景下面的时候的话，它其实往往需要对消息的一个强一致性有一定的啊要求啊，其实那存在这两点问题，其实后面呢，给MQ其实是通过引入的开源的一个这样一个啊基础库，然后呢，它是基于rap的算法啊，实现了一个分布式的日志库。

那它底层呢，就采用了这样一套架构来去啊，解决了这两个问题啊，第一个的话就是它解决了自动自动故障转移的这个问题呢，它是采用啊rap的算法自动选出来实现的，那第二个的话，强一致性就本身由rap的算法来保证的啊，那我们来看，其实往往在一些组件再去啊，涉及到怎么样解决故障自动转移的这个话题下面的话就是主存模式下面啊通常呢，要不就是采用第三方的一些组件，比如说look keepper或者etcd啊来做这种第三方组件选啊这种模式这种特点呢，就是它引入的新的组件啊，那运维的复杂度呢，同时也严重上升，那第二种的话，其实就是集群内部啊，各个节点时间能够自发的发起一个悬主啊，比如说例，像rap的算法的一个悬主等等。

就是如IEMK，他最终就选择了后者啊，这就是它的一个特点啊，这是它故障转移，然后数据复制的话，所谓不管是啊底力热版本还是说主存的这种版本，其实它的数据啊都是由啊master，然后同步给slave，不管是自动，不管是同步复制还是异步复制啊，同时呢，在raft这一边的话，就是由leader啊，同步给我们的follow这两个节点，然后这样一个模式进行数据的一个复制。同时呢，在rocket MQ里面啊，它的数据的分片，它的数据呢，前面也在提到，就是它首先呢，它的集群呢，是由多个分的。集群切片集群来构成啊，就是每一就是每一组啊，Master slave节点构成一个小的集群啊，它是由多组小群拼在一起，所以这时候的话，对外其实访问是一个topic，那在集群内部的话，就是首先这个topic呢，会按照集群来做一个啊topic的分片，那分到每一个集群内部之后的话，小集群内部之后。

他又会啊，再将这个topic呢，做一个啊，队列的一个啊分区就是分片，再细节做下一级的分片，所以它是两层的分片啊，那在这种模式下面，同时它的不同集群不同的啊分片集群之间呢，因为比如说不同啊，因为集群的一些配置不同，可能会导致啊比如说。呃，它的集群，集群一上面呢，可能是啊会分它的配置高一些，会分配的那个队列多一些，而集群二呢，可能是配置中等，那就分配啊，一般分配几个Q啊，基于C的话，可能啊是做一些其他的工作，那可能就在它上面，甚至都不会去再去啊分配一些队列啊，它这种呢就是啊，可以在不同的集群之间去设置不同数目的一个队列，这是它的一一大特点，就可以结合集群自身的一个啊情况来进行分，进行一个队列的创建，所以这边可以看到，以这个集群二的来说的话，你看他他这边的话就是啊以topic。

G2我们来看的话，就是以这个啊topic来说的话啊，那呃，以这个topici来说的话，那G1上面其实它创建了六个队，而在啊集二上面其实只创建了四个，而在集群三呢，其实只创只创建了两个，这其实就是它可以根据不同的不同的集群的一些配置或者不同的业务场景来去做。啊，那接下来其实就是M的一个存在的一些生产上面的负载均衡吧，这一块的话，其实在卡卡里面也前面提到过这一部分内容啊，在MQ里面，它其实在负载均衡的时候呢，它是将同一个topic下面的所有的啊Q呢拉在一起进行一个负载均衡啊，它默认的方式呢，就是龙胸的负载均衡啊，其实这一块的话，也可以是按照K进行哈希，或者是按照啊平均的一种方式去隆胸。

啊，平均或者是随机的方式啊，这些都是一些主啊，就是比较常见的一些负载均衡的一些方式啊，然后另外的话，其实就是他在消费者这边的一个负载均衡上面来说的话，它支持比较多啊，像第一种就是比较平均的，就是两个消费者，然后呢，四个队列，那每个消费者消费两个，然后这种平均分配。这是一种常见的，然后第二种的话就是啊，像这种环形分配，就是一人一个一人一个啊这种环形分配啊，然后呢，第三个的话就是它支持也支持一致性，哈希的这种分配啊，其实本质上就是一个负载均衡的方式嘛，那就是将啊哪个队列分给哪个消费者去进行处理啊，大概就是这个意思，然后呢，他也支持同机房以及就近机房的一些分配，这些呢，其实都是他针对这种啊不同的一些业务场景以及集群环境做的一些个性化的一些啊分配方式啊。

啊，其实到这一块的话，我们其实就啊，加上整个rocket MQ它的一个多实例的一些啊内容呢，做了一些啊总结做了一些讲解，其实在这一块的话，它的rocket MQ它的多实力啊，主要是集群环境跟那个呃。啊顶立着白鬼的一个强一致性的环境呢，这两个呢，它其实其实一对比的话，其实就可以发现他他们之间其实还是有很多的一些相通的一些之处，呃，下面呢，我们再对rock m q它整体的那个内容做一个总结吧，啊就是它的架构上面就是啊主存的架构跟。主从架构跟那个强一致性的架构啊，其实中间是很类似的，只不过是将我们的master style换成了我们的啊Li和photo这样一种方式啊，这就是整个的一个它其实在啊架构上面改变，同时在啊commit log同时在那个替换成强一致性架构之后呢，它底层啊，就是将原先的那个com log那个文件呢，替换成了就是本身delete rap算法里面的那个啊它的日志的那个文件就是变成了com log做的这样一个替换啊。那另外一方面的话，就是我们来看一下它的啊所有集群之间的一个对比情况啊，就是它支持集群呢，它其支持几种方式，第一种就是啊单个master，就是基本上就是单是单机的这样一个环境啊，第二种的话就是它支持多个master，没有对，每个master没有slave节点，第三个就是它支持master有slave节点，但是它master和slave之间数据的复制呢，是按照异步方式去复制，那第四种呢，就是master和之间呢，它的数据。

现在是同步双写的这种。储存复制，那我们一一来看。单个master的节点的时候呢，它的特点就是啊，结构比较简单，同时呢扩容呢比较方便啊，但同时这种方式下面的话就是它整体来说是可用，但是呢啊它的性能最高，但是呢在生产环境其实不推荐去使用啊，另外一个就是多master这种情况下的话，就是因为每个master它没有一个那节点做备份嘛，所以它的故障的时候呢，可能会出现丢失消息，同时整体来说它的是一个可用的啊，那这种场景呢，其实适合在一些啊消息可靠性比较高，但同呃略高，但是呢实时性一般啊，同时性能要求不太高的一些场景里面。

啊master slave节异步的复制的这种场景里面呢，跟同步复制呢，他们呢都是结构比较复杂，因为引入了一个主从复制的啊这种啊数据备份的一项能力，那同时呢，其实在消息的一个可靠性上面啊，异步复制呢，它是有毫秒级的一个数据的丢失啊双写同步双写呢，其实就不存在这个问题啊，但是呢，它异步复制的时候呢，整体可用，同时呢啊它的一个实时性呢，是比较毫秒级别啊，性能呢很高，因为异步复制吧，同时呢它它主要就是用于消息的要求可靠性呢是中等，同时呢实时性也是中等的这种场景，而一同步双写的时候呢，啊，它的特点就是数据不丢失，加上它有一个很大的问题就是啊它的主节点发生故障之后呢，它的主备不能做一个自动的切换啊，同时这个倍机呢，只能处理堵，不能只能处理读，不能处理写啊，这种情况下面就会处啊，存在一个我们的整体，如果master的节点故障之后呢，会存在一个整体服务的。

可写。这个比较危险啊，那它的性能呢，其实比异步的呀啊低于10%啊，大概是10%啊，在这种场景里面，其实啊，它的实时性呢，也并不比异步方式啊太高太多啊，同时呢，其实这种场景呢，还是要根据具体业务来考虑啊，就是因为储储存不能达到一个自动的一个故障切换嘛，所以这个这个场景还是要稍微谨慎，那其实在鼎立这版本的这一个里面的话，其实它的故故障呢，就可以做到一个自动的转移，同时呢，消息支持一个强一致性啊，这就是整个啊rockie MQ它整个集群的一些对比的一些特点。