IT评测·应用市场-qidao123.com技术社区

标题: 阿里专家讲解 ：RocketMQ 工作原理和主要架构-主从原理-读写原理-发送消费 [打印本页]

---

作者: 诗林    时间: 2024-11-28 21:51
标题: 阿里专家讲解 ：RocketMQ 工作原理和主要架构-主从原理-读写原理-发送消费
本文主要先容了：
RocketMQ 消息中间件通过范畴模子和技能架构实现高效的消息处置处罚。
其直连模式摆设简化了系统结构，而存储计算分离摆设提拔了资源利用率。通信机制确保消息的快速传输，存储机制则优化了数据长期化。
元数据管理、高效的存储层实现、单条消息的存储格式和构建消息的索引共同构成了其核心原理。
高可用机制保障了系统的稳定性，架构演希望示了其一连优化的过程。
实现对比突出了 RocketMQ 的独特优势。客户端支持 Push 和 Pull 消费，以及 Pop 消费，满意差别场景需求。高级特性如次序消息、定时消息、事务消息和消息查询进一步加强了其功能。
RocketMQ 的原理和架构设计使其成为高性能、可扩展的消息中间件解决方案。

目录
范畴模子
技能架构
直连模式摆设
存储计算分离摆设
通信机制
存储机制
元数据管理
高效的存储层实现
单条消息的存储格式
构建消息的索引
高可用机制
架构演进
实现对比
客户端
Push 和 Pull 消费
Pop 消费
高级特性
次序消息
定时消息
事务消息
消息查询

---

范畴模子

以下是 RocketMQ 中的术语，更多细节请参考 基本概念。

• Message（消息）：Message 是 RocketMQ 传输的基本单位，包含了具体的业务数据以及一些元数据（如消息 ID、主题、标签、发送时间等）。消息可以是文本、二进制数据或其他任何序列化后的对象形式。
  
• Topic（主题）：Topic 是一类消息的逻辑分类名，是 Apache RocketMQ 中消息传输和存储的顶层容器。雷同于邮件系统中的邮箱地址或发布/订阅模式中的“频道”。生产者向特定的 Topic 发送消息，消费者则根据 Topic 订阅并吸收消息。一个 Topic 可以被多个生产者写入，同时也能被多个消费者订阅。
  
• Queue（队列）：每个 Topic 被划分为多个 Queue（队列），或称 MessageQueue，这些队列用于存储消息。生产者发送到 Topic 的消息会被分配到其下的各个 Queue 中；消费者则是从这些 Queue 中拉取消息进行消费。
  
• Subscription（订阅）：Subscription 表示消费者对某个 Topic 消息的爱好表达。订阅关系由消费者分组动态注册到服务端系统，并在消息传输中按照订阅关系界说的过滤规则进行消息匹配和消费进度的维护。
  
• Producer（生产者）：生产者是消息产生的源头，将消息发送到服务端指定 Topic。
  
• Consumer（消费者）：消费者负责从服务端中拉取消息并进行处置处罚。
  
• ProducerGroup（生产者组）：ProducerGroup 是一组生产者的逻辑分组，共享同样的 Topic 发送配置，实现发送端的负载平衡和容错。假如组内某个生产者失败，其他生产者可以继续工作，包管消息发送的一连性。
  
• ConsumerGroup（消费者组）：消费者分组是 Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载平衡分组。和消费者差别，消费者分组并不是运行实体，而是一个逻辑资源。分组中的消费者共同订阅同一个 Topic 并以某种策略（如广播、集群消费）消费消息。在 Apache RocketMQ 中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。
  

技能架构

Apache RocketMQ 服务端底子组件包括 NameServer，Broker，Proxy，推荐使用存储计算分离模式摆设。
直连模式摆设

RocketMQ 是一个范例的发布订阅系统，通过 Broker 节点中转和长期化数据，解耦上卑鄙。Broker 是真实存储数据的节点，由多个水平摆设但不一定完全对等的副本组构成，单个副本组的差别节点上的数据会达到终极一致。单个副本组同一时间只有一个可读写的 Master 和若干个只读的 Slave，主故障时会进行选举来容忍故障，此时单个副本组可读不可写。NameServer 是独立的一个无状态组件，接受 Broker 的元数据注册并动态维护着一些映射关系，同时为客户端提供服务发现的能力。在这个模子中，我们使用差别主题 (Topic) 来区分差别类别的信息流，为消费者设置订阅组 (Group) 进行更好的管理与负载平衡。如下图中间部门所示：

• 服务端 Broker Master1 和 Slave1 构成此中的一个副本组。
  
• 服务端 Broker 1 和 Broker 2 两个副本组以负载平衡的形式共同为客户端提供读写。
  
  
  
  注：Producer 和 Consumer 会和 NameServer，Broker 都维持长毗连。Producer 只会向 Master 副本发送消息，Consumer 可以从 Master 大概 Slave 消费消息。
  

存储计算分离摆设

存储和计算分离是一种良好的模块化设计。无状态的 Proxy 集群是数据流量的入口，提供署名校验与权限控制、计量与可观测、客户端毗连管理、消息编解码处置处罚、流量控制、多协议接入等能力。原 Broker 节点演化为以存储为核心的有状态集群，支持读写多类型消息，它们的底层是多模态存储和多元化的高效索引。存储计算分离的形态利于差别业务场景下单独调整存储或计算节点的数量，来实现扩容和缩容。网关模式接入还能带来升级简单，组网便利等好处。Proxy 和 Broker 都属于服务端组件，内网通信的耽误不会显著增加客户端收发消息的耽误。

注：Proxy 自身会向 NameServer 和 Broker 都建立长毗连，Producer 和 Consumer 仅毗连到 Proxy。
通信机制

Apache RocketMQ 客户端使用 TCP 访问服务端，根据传输的数据格式分为 Remoting 协议和 gRPC 协议。

• Remoting 协议诞生较早，是组件间通信默认的私有协议。此中 Remoting Java 客户端和主堆栈同步演进和迭代，而多语言客户端（以下简称 SDK）归属于 Apache 社区多个独立堆栈。
  
• gRPC 协议自 RocketMQ 5.0 版本推出，以 Protobuf 界说了底层传输的数据格式（详见 RocketMQ API），旨在以云原生主流技能演进轻量、标准、易扩展的客户端服务端通信协议。使用 gRPC 协议的 SDK 是以独立堆栈 RocketMQ Clients 方式演进，支持 Java/C++/.NET/Go/Rust 等浩繁语言。
  
• RocketMQ 5.0 在服务端内部也提供了基于 Protobuf + gRPC 的管控 API 实现。
  

RocketMQ 的接入点是什么？为了简化客户端配置的复杂度，以直连模式摆设的集群，客户端必要和服务端的 NameServer，Broker 进行点对点直连通信，客户端必要配置 NameServer 集群的负载平衡地址。对于以代理模式摆设的集群，无论客户端使用 Remoting 照旧 gRPC 协议，客户端仅需和 Proxy 进行通信，必要将配置接入点为 Proxy 的负载平衡地址。服务端会使用协议协商技能，自动区分 Remoting 和 gRPC 协议并处置处罚客户端的请求。在受限网络情况中，客户端必要同时放通接入点的 8080 和 8081 端口。
存储机制

元数据管理

为了提拔团体的吞吐量与提供跨副本组的高可用能力，RocketMQ 服务端一样平常会为单个 Topic 创建多个逻辑分区，即在多个副本组上各自维护部门分区 (Partition)，我们把它称为队列 (MessageQueue)。同一个副本组上同一个 Topic 的队列数雷同并从 0 开始一连编号，差别副本组上的 MessageQueue 数量可以差别。
 

比方 topic-a 可以在 broker-1 主副本上有 4 个队列，编号 (queueId) 是 0-3，在 broker-1 备副本上完全雷同，但是 broker-2 上大概就只有 2 个队列，编号 0-1。在 Broker 上元数据的构造管理方式是与上述模子匹配的，每一个 Topic 的 TopicConfig，包含了几个核心的属性，名称，读写队列数，权限与很多元数据标识，这个模子雷同于 K8s 的 StatefulSet，队列从 0 开始编号，扩缩队列都在尾部操作（比方 24 个队列缩分区到 16，是留下了编号为 0-15 的分区）。Broker 还管理着当前节点上 Group 的相干信息和消费进度（位点），当消费进度更新时 并不会像 Topic Group 那样立即长期化，而是使用一个定时任务做 CheckPoint。这个周期默认是 5 秒，所以当客户端有上下线，服务端主备切换大概正常发布时，大概会有秒级的消息重复，并观察到堆积量的短暂上升。
高效的存储层实现

RocketMQ 存储的核心是极致优化的次序写盘，数据以 append only 的形式不断的将新的消息追加到文件末尾。RocketMQ 使用了一种称为 MappedByteBuffer 的内存映射文件的办法，将一个文件映射到进程的地址空间，实现文件的磁盘地址和进程的一段虚拟地址关联，实际上是利用了NIO 中的 FileChannel 模子。在进行这种绑定后，用户进程就可以用指针（偏移量）的形式写入磁盘而不用进行 read / write 的系统调用，淘汰了数据在缓冲区之间往返拷贝的开销。固然这种内核实现的机制有一些限定，单个 mmap 的文件不能太大 (RocketMQ 选择了 1G)，此时再把多个 mmap 的文件用一个链表串起来构成一个逻辑队列 (称为 MappedFileQueue)，就可以在逻辑上实现一个无需考虑长度的存储空间来保存全部的消息。

单条消息的存储格式

RocketMQ 有一套相对复杂的消息存储编码用来将消息对象序列化，随后再将非定长的数据落到上述的真实的写入到文件中，存储格式中包括了索引队列的编号和位置。单条消息的存储格式如下：
 

可以发现，单条消息本身元数据占用的存储空间为固定的描述信息和变长的 body 和 properties 部门，而消息的 payload 通常大于 2K，也就是说元数据带来的额外存储开销只增加了 5%-10% 左右。很显着，单条消息越大，存储本身额外的开销（比例）就相对的越少。
构建消息的索引

在数据写入 CommitLog 后，有一个后端的 ReputMessageService 服务 (也被称为 dispatch 线程) 会异步的构建多种索引（比方 ConsumeQueue 和 Index），满意差别形式的读取和查询诉求。在 RocketMQ 的模子下，消息本身存在的逻辑队列称为 MessageQueue，而对应的物理索引文件称为 ConsumeQueue。此中 dispatch 线程会源源不断的将消息从 CommitLog 取出，再拿出消息在 CommitLog 中的物理偏移量，消息长度以及 Tag Hash 等信息作为单条消息的索引，分发到对应的消费队列，构成了对 CommitLog 的引用 (Reference)。ConsumeQueue 中单条消息占用的索引空间只有 20B。当客户端尝试从服务端拉取消息时，会先读取索引并进行过滤，随后根据索引从 CommitLog 中获得真实的消息并返回。

高可用机制

架构演进

最早的时间，RocketMQ 基于 Master-Slave 模式提供了主备摆设的架构，这种模式提供了一定的高可用能力，在 Master 节点负载较高情况下，读流量可以被重定向到备机。备机在正常工作场景下资源使用率较低，造成一定的资源浪费。为了解决这个问题，社区提出了在一个 Broker 进程内运行多个 BrokerContainer，通过在单节点主备交叉摆设来同时负担多份流量，该方案无外部依靠，自愈能力强。这种方式下隔离性弱于使用原生容器方式进行隔离，同时由于架构的复杂度增加导致了自愈流程较为复杂。
另一条演进门路则是基于可切换的，RocketMQ 也尝试过依托于 Zookeeper 的分布式锁和通知机制进行 HA 状态的管理。引入外部依靠的同时给架构带来了复杂性，不容易做小型化摆设，摆设运维和诊断的成本较高。DLedger 方案是基于 Raft 的日记录现，集群内同一个副本组下的 Broker 会自动选主，Raft 中的副本身份被透出和复用到 Broker Role 层面，无外部依靠，然而强一致的 Raft 设计并未支持灵活的降级策略，无法在 C 和 A 之间灵活调整。
而 RocketMQ DLedger 融合模式是 RocketMQ 5.0 演进中结合上述两条门路后的一个系统的解决方案，推荐使用两副本进行摆设，很好的权衡了团体拥有成本和运维复杂度，其核心流程如下：

• 利用可内嵌于 NameServer 的 Controller 进行选主，无外部依靠，对两副本支持友好。
  
• 引入 Epoch-StartOffset 机制来计算日记分叉位点。
  
• 消息在进行写入时，提供了灵活的配置来协调系统对于可用性照旧一致性优先的诉求。
  
• 简化日记复制协议使得日记复制为高效。
  

利用任期 Epoch 和偏移量 StartOffset 实现一个新的截断算法。这种 Epoch-StartOffset 满意如下原则：

• 通过共识协议包管给定的一个任期 Epoch 只有一个Leader。
  
• 只有 Leader 可以写入新的数据流，满意一定条件才会被提交。
  
• Follower 只能从 Leader 获取最新的数据流，Follower 上线时按照选举算法进行截断。
  

下面是一个选举截断的具体案例，选举截断算法头脑和流程如下:

• 主 CommitLog Min = 300，Max = 2500，EpochMap = {<6, 200>, <7, 1200>, <8,2500>}
  
• 备 CommitLog Min = 300，Max = 2500，EpochMap = {<6, 200>, <7, 1200>, <8,2250>}
  

• 备节点毗连到主节点进行 HA 协商，获取主节点的 Epoch-StartOffset 信息并比力
  
• 备从后向前找到任期-起始点雷同的那个点作为分叉任期，在上述案例里是 <8, 2250>
  
• 选择这个任期里主备结束位点的最小值（假如主副本没有切换且为最大任期，则主副本的结束位点是无穷大）
  

实现对比

	模式	优点	缺点
无切换架构	Master-Slave 模式	实现简单，适用于中小型用户，人为干预管控力强。	冷备浪费资源，故障必要人工参与，由于故障的副本组不可写入消息，还会导致一些二级消息消费停息，团体运维成本高。
无切换架构	Broker Container 模式	无需选主，无外部依靠，自愈能力强，故障转移时间从 ~30 秒级低沉为 < 3 秒。	由于数据是从主到备单向复制的，Container 模式会增加一定的运维复杂度，二级消息场景自愈流程较为复杂，还必要长期生产检验。
切换架构	利用 Raft 实现	自动主备切换。	故障转移时间较长，强一致的 Raft 并未支持灵活的降级，无法在 C 和 A 之间做灵活的调整；三副本成本压力较高。复制链路没有有效显现原生存储的优势。
融合架构	基于 Dledger Controller 实现	一套代码同时支持无切换和切换架构，且两种模式可以转换。复制协议相比于其他几种要显著简化，灵活降级。	提高了 NameServer 摆设复杂度，仍需大规模生产情况验证。

客户端

RocketMQ 提供了灵活的负载平衡机制，主要表现在消费者如何平衡地从消息队列中获取消息。
主要分为三种消费模式：Push（推送模式)，Pull（拉取模式），Pop（无状态消费模式）。
Push 和 Pull 消费

RocketMQ 中的 Push 并不是指传统意义上的客户端完全被动吸收，底层是基于长轮询机制实现。

• 长轮询：客户端与 Broker 建立长毗连，并发送拉取消息的请求。假如当前没有新消息，Broker 不会立即响应，而是等候一段时间或直到有新消息到达再返回。
  
• 消费位点：每个消费者维护自己的消费进度（消费位点），Broker 根据这些位点信息，只推送消费者尚未消费的消息。
  
• 重平衡：当消费者组内的消费者实例发生变革时（如增加或淘汰消费者实例），RocketMQ会触发一次重平衡（Rebalance）操作，重新分配消息队列到各个消费者实例，以实现负载平衡。这个过程确保了消息的均匀消费，避免了消息积蓄或某些消费者空闲的情况。
  

Pull 模式更加主动，消费者根据自己的消费能力和需求，主动从 Broker 拉取消息。

• 主动拉取：消费者主动向Broker发送拉取请求，指定要拉取的消息数量和偏移量（或时间戳），Broker 响应包含消息或空效果。
  
• 位点管理和重平衡：与Push模式雷同，每个消费者维护自己的消费进度，并在消费者实例变革时进行重平衡。但是，在Pull模式下，重平衡的逻辑更依靠于消费者的主动参与，消费者必要根据新的队列分配情况调整自己的拉取策略。
  

Push / Pull 消费模式的负载平衡是在客户端完成的，性能较高，但也有一些缺陷。

• 客户端代码逻辑复杂，客户端要实现完备的负载平衡，拉消息，位点管理，消费失败后将消息发回 Broker 重试等逻辑。这给多语言客户端的支持造成很大的阻碍。
  
• 消费者无法无限扩展，当消费者数量扩大到大于队列数量时，有的消费者将无法分配到队列。
  
• 当某些消费者僵死（hang 住）时，会造成其消费的队列的消息堆积。
  

Pop 消费

在 RocketMQ 5.0 中，Pop 消费模式借助 gRPC 封装的接口，促进了轻量化多语言客户端的实现，无需在各客户端重复实现重平衡逻辑，显著提拔了系统的灵活性和扩展性。该设计核心在于将重平衡、位点管理及消息重试等任务转移至服务端处置处罚，有效避免单点故障引起的消息积蓄，优化了团体消息处置处罚服从和系统的水平扩展能力。
 

Push / Pull 模式下队列中有慢任务会壅闭整个队列。比方有位点为 34567 的 5 条消息，消费 offset = 5 时业务逻辑耗时非常久，并发消费模式下 67 两条消息消费较快，而观察到的堆积一直为 3 造成误判。消费者大概服务端宕机，业务对产生几秒的消费重复依然敏感，影响用户体验，比方短信推送场景。甚至，我们还有更有代表性的场景来命中这些 “缺陷”，比方渲染业务，队列中每一条消息代表一个渲染任务。

• 消费者数量较多，同一个订阅组大概有成百上千台机器同时消费。
  
• 该场景下单条数据的处置处罚耗时较长，必要几秒至几个小时不等。
  
• 由于消费者负载高和大量使用竞价实例，导致消费方进程假死和宕机率远高于一样平常业务。
  

传统的消息队列会遇到很经典的 “Work-Stealing” 难题，任务的负载无法平衡的分配到所有消费方，单条消息的壅闭会影响后续消费乐成消息位点的提交。此时我们想要的是一个基于不可见时间的投递算法，该算法大抵的工作流程如下：

• 客户端设置一个不可见时间，比方 5 分钟，并向服务端拉取一批消息。
  
• 服务端返回一批消息，并在后台开始倒计时 5 分钟，消息上会附加一个字段用来标识，也称为 handle。
  
• 假如客户端 5 分钟内没有提交消费乐成（ack by handle），5 分钟后客户端再次可以获取到这批消息。
  

很快我们就会发现这个模子照旧有缺陷的，假如消费者拉取消息 1 分钟后立即宕机了，业务不得不忍受 4 分钟的耽误才能再次处置处罚，哪怕此时其他消费者照旧空闲状态。这个时间就可以选择将消息的不可见时间设置为 1 分钟，在客户端处置处罚业务的同时不绝的 refresh 不可见时间，比方每隔 30 秒就调用 change invisible time，使剩余的不可见时间更新为 1 分钟，此时无论客户端何时宕机，消息的耽误时间会控制在 1 分钟之内。在 RocketMQ 中，这种基于区间和单条消息进行消费的方式被称为 “pop 消费”，对应的客户端实现是 SimpleConsumer，它的简单性在于客户端不再必要关心复杂的负载平衡和位点管理，也更容易适配多语言。
高级特性

次序消息

次序消息是 Apache RocketMQ 提供的一种高级消息类型，支持消费者按照发送消息的先后次序获取消息，从而实现业务场景中的次序处置处罚。 相比其他类型消息，次序消息在发送、存储和投递的处置处罚过程中，更多夸大多条消息间的先后次序关系。Apache RocketMQ 次序消息的次序关系通过消息组（MessageGroup）判定和识别。（注：这个概念在旧版本中被称为 ShardingKey）发送次序消息时必要为每条消息设置归属的消息组，雷同消息组的多条消息之间遵循先辈先出的次序关系，差别消息组、无消息组的消息之间不涉及次序性。Apache RocketMQ 的消息的次序性分为两部门，生产次序性和消费次序性：
如需包管消息生产的次序性，则必须满意以下条件：

• 单一生产者：消息生产的次序性仅支持单一生产者，差别生产者分布在差别的系统，即使设置雷同的消息组，差别生产者之间产生的消息也无法判定其先后次序。
  
• 串行发送：Apache RocketMQ 生产者客户端支持多线程安全访问，但假如生产者使用多线程并行发送，则差别线程间产生的消息将无法判定其先后次序。
  
• Apache RocketMQ 通过消费者和服务端的协议保障消息消费严格按照存储的先后次序来处置处罚。
  

如需包管消息消费的次序性，则必须满意投递次序和有限重试两个条件，详情请参考次序消息设计。
定时消息

在分布式场景中会有定时调理、任务超时处置处罚等场景，使用 Apache RocketMQ 的定时消息可以简化定时调理任务的开发逻辑，实现高性能、可扩展、高可靠的定时触发能力。RocketMQ 服务端有两种实现延时的机制，一种是延时队列，另一种是可长期化单层时间轮。下面简述这两种方案的服务端实现：

• 延时队列实现：通过划分延时 Level 的方式，将差别耽误级别的消息放入差别的耽误队列，排序操作转换为了 O(1) 的 ConsumeQueue 的 append 操作。broker 有一个定时任务不断从各个耽误队列 “消费消息”，假如到达预期时间，就取出消息并重新放入到 commitLog 中。这样设计的延时队列已经满意大部门场景下的需求，如 15 分钟的特定场景，消息会堆积于单个队列中。该方案性能非常高，缺陷是只支持固定隔断的定时消息，比方 1 分钟，15 分钟，60 分钟等。
  
• 可长期化单层时间轮：每一秒为一个定时的 Slot，将所有消息通过长期化的方式放入 TimerLog 中，当定时时间有冲突时使用哈希拉链的方式解决冲突，后一条消息保存对前一条消息的引用。同时对时间轮提供内存锁定，对于所有追加只在 TimerLog 尾部操作。当取出消息的线程从时间轮中扫描 Slot 时，从 TimerLog 中以此拉取所有定时消息并出队。
  

事务消息

RocketMQ 提供了事务消息的功能，接纳 2PC (两段式协议) + 补偿机制（事务回查）的分布式事务功能，通过这种方式能达到分布式事务的终极一致。这里必要先来明白两个概念：

• 半事务消息：暂不能投递的消息，发送方已经乐成地将消息发送到了消息队列 RocketMQ 版服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标志成“暂不能投递”状态，处于该种状态下的消息即半事务消息。
  
• 消息回查： 由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，必要主动向消息生产者组（ProducerGroup）的任意一个客户端询问该消息的终极状态（Commit 或是 Rollback），即消息回查。
  

事务消息发送步调如下：

• 发送方将半事务消息发送至消息队列 RocketMQ 版服务端。
  
• 消息队列 RocketMQ 版服务端将消息长期化乐成之后，向发送方返回 Ack 确认消息已经发送乐成，此时消息为半事务消息。
  
• 发送方开始执行当地事务逻辑。
  
• 发送方根据当地事务执行效果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务消息标志为可投递，订阅方终极将收到该消息；服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接受该消息。 事务消息回查步调如下：
  
• 在断网大概是应用重启的特殊情况下，上述步调 4 提交的二次确认终极未到达服务端，颠末固定时间后服务端将对该消息发起消息回查。
  
• 发送方收到消息回查后，必要检查对应消息的当地事务执行的终极效果。
  
• 发送方根据检查得到的当地事务的终极状态再次提交二次确认，服务端仍按照步调 4 对半事务消息进行操作。
  

消息查询

RocketMQ 作为业务消息的首选，除了上文中 ReputMessageService 线程除了构建消费队列的索引外，还同时为每条消息根据 id, key 构建了索引到 IndexFile。这是方便快速快速定位目标消息而产生的，固然这个构建随机索引的能力是可以降级的，IndexFile文件结构如下：
 

IndexFile 也是定长的，从单个文件的数据结构来说，这是实现了一种简单原生的哈希拉链机制。当一条新的消息索引进来时，首先使用 hash 算法命中黄色部门 500w 个 slot 中的一个，假如存在冲突就使用拉链解决，将最新索引数据的 next 指向上一条索引位置。同时将消息的索引数据 append 至文件尾部（绿色部门），这样便形成了一条当前 slot 按照时间存入的倒序的链表。这里其实也是一种 LSM compaction 在消息模子下的改进，低沉了写放大。当用户按照 UniqueKey（MsgId）大概业务 Key 来进行查询时，会先从索引查询消息报存在 CommitLog 中的位置并取回数据返回客户端。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4