RocketMQ5.0 四大核心特性。

核心特性一：可分可合的存储计算分离架构

接下来，详细介绍一下可分可合的存储计算分离架构。可分可合指的是 RocketMQ 可以像现在一样用同一进程去启动 Broker，也可以分开部署。分开部署之后计算节点就能真正的做到无状态，RocketMQ 对存储计算分离的架构的引进是非常谨慎的，一体化部署带来了诸多好处，比如大数据场景下，一体化部署提供就近计算能力，降低带宽成本。业务消息场景下，一体化部署可以降低延迟。与此同时，存储计算分离也有非常多的好处，比如说扩缩容可以更加灵活，可以针对具体计算资源或存储资源进行扩缩容。

因此 RocketMQ 5.0 将会提供可分可合的存储计算分离架构，可以适应多种场景。计算节点是完全无状态的。包括像协议适配、流量租户等管控都会放在计算节点上完成。此外，通过 POP 消费方式把整个客户端的负载均衡逻辑位的管理上升到计算节点，无 Queue Binding，任意的计算节点都能进行收发。另外，由于无状态，可以完成秒级弹性扩缩，并且过程中是没有 Rebalance 负担的。

与此同时，RocketMQ 5.0 会对存储集群进行了优化调整。在存储集群中我们原生的保留了多消息类型的存储支持，包括事务消息、定时消息，重试消息、死信消息等。在副本的选择上，根据不同场景去提供不同支持，包括本地块设备多副本支持、云盘单副本支持。借助多模态存储功能，充分利用云上基础设施降低成本。

另一点非常重要的是多元索引的支持。现在 RocketMQ 存储是一份 CommitLog ，后台线程去分发构建 ConsumeQueue、index 这些索引。那么 RocketMQ 5.0 会对索引全面增强，支持更多样索引。比如加入批处理的索引，消息就可以完成批量发送，批量存储，批量接收，从而提升 RocketMQ Batch 能力。比如消息队列只做消息轮转，查询能力比较弱，在 RocketMQ 5.0 中，消息和 KV 会更好结合在一起，去构建查询索引从而增强 KV 能力。通过一份数据，多种索引，RocketMQ 5.0 可以满足不同场景。

核心特性二：流批一体的数据访问方式

首先介绍全新的消费模式——POP 消费方式。左上角的图是 RocketMQ 4.0 现有消费端的负载均衡架构。比如现在 Topic 分布在 3 个 Broker 上，共计 9 个队列。在集群模式下，1 个消费组有 3 个消费者。根据。所以每个消费者分配到了三个队列。

但这也带来了一些问题，比如说某 Consumer 突然 Hang 住了，这它无法消费消息但也没有掉线，仍然保持和 Broker 的心跳连接，因此也不会将剔除而进行重平衡，所以这个消费者分配到的队列就会有大量的消息堆积，这些队列的消费就会卡住。

这本质上是一个绑定关系问题，一旦 Rebalance 发生后，Consumer 和队列就完成了绑定。针对这个问题，RocketMQ 5.0 推出了一个全新的消费方式，即 POP 消费方式。它取消了 Rebalance 造成的绑定关系，一个队列可以被任意多个 Consumer 进行消费，然后在 Broker 端通过队列锁完成并发控制。

POP 消费中，客户端会直接到每个 Broker 的队列进行请求消费， Broker 会把消息分配返回给等待的客户端。随后客户端消费结束后返回对应的 ACK 结果通知 Broker，Broker 再标记消息消费结果，如果超时没响应或者消费失败，再会进行重试。

Broker 对于每次 POP 的请求，都会有以下三个操作：

1. 对应的队列进行加锁，然后从 Store 层获取该队列的消息；

2. 然后写入 CK 消息，表明获取的消息要被 POP 消费；

3. 最后提交当前位点，并释放锁。

CK 消息实际上是记录了 POP 消息具体位点的定时消息，当客户端超时没响应的时候，CK 消息就会重新被 Broker 消费，然后把 CK 消息的位点的消息写入重试队列。如果 Broker 收到客户端的消费结果的 ACK ，删除对应的 CK 消息，然后根据具体结果判断是否需要重试。

从整体流程可见，POP 消费并不需要 Reblance ，可以避免 Rebalance 带来的消费延时，同时客户端可以消费 Broker 的所有队列，这样就可以避免机器 Hang 住而导致堆积的问题。

有了 POP、PUSH、PULL 等模式之后，RocketMQ 就可以完成流批一体的数据访问方式。比如说在 Streaming 场景下，通过原本 PUSH 方式可以保证很好的顺序消费。但批处理等对顺序要求并不高的场景中，我们可以用 POP 消费的方式对同一队列进行高并发读取，加快数据读取速度。另一方面 POP 消费模式也使得客户端更加轻量化，大量的逻辑都在服务端，对多语言客户端的编写也是更加友好的。

核心特性三：极致弹性扩缩

上图是 RocketMQ 现有架构，比如说我们通过禁写操作，可以使 Broker 1001 的流量自然流入到 1002 上。但在 Streaming 领域，上层业务一般要求存储队列始终固定的，只有这样才能保证流式数据处理的顺序性和完整性，这也就要求扩缩容不会引起队列数量的变化。因此 RocketMQ 5.0 Preview 版本提供了一个逻辑队列概念，把原本的物理队列逻辑组合在一起，一个逻辑队列可以分散到不同 Broker 上面。比如图中的一个逻辑队列，0～100 在 Broker 1001 上，100～1000 在 Broker 1002 上，1000～2000 的在 Broker 1003 上，通过组合可以把多个物理队列串联成了一个大的逻辑队列。

由于逻辑队列是一个 Binding 过程，所以是非常轻量级的操作，因此提供了一个秒级弹性扩充的一个能力，过程中完全没有也没有数据的复制，只要一完成 Broker 扩容，完成绑定操作，流量也就完成了调拨。另外我们也提供双模队列兼容的能力，平时默认还是原来的物理队列，只有指定单个 Topic 开启后，才会使用逻辑队列。

核心特性四：轻量级实时计算