云原生消息流系统 Apache RocketMQ 在腾讯云的大规模生产实践

作者 | 李伟

本文将围绕 RocketMQ 5.x 的新特性展开探讨，详细解读其在腾讯云上的实际应用案例，并展望未来的发展规划。

随着云计算技术的日益成熟，云原生应用已逐渐成为企业数字化转型的核心驱动力。在这一大背景下，高效、稳定、可扩展的消息流系统显得尤为重要。腾讯云高级开发工程师李伟先生，凭借其深厚的技术功底和丰富的实战经验，为我们带来了《云原生消息流系统 Apache RocketMQ 在腾讯云的大规模生产实践》的分享。本文将围绕 RocketMQ 5.x 的新特性展开探讨，详细解读其在腾讯云上的实际应用案例，并展望未来的发展规划。

从 2022 年 9 月 22 日社区开始推 5.x 后，很多厂商公司都在研究或者使用 5.x 版本的 RocketMQ，在使用的过程中可以发现，很多问题比如消费卡住的问题等就可以通过 Proxy 和 Pop 的消费来解决。

接下来我们先从第一个主题 RocketMQ 5.x 的新特性开始。

RocketMQ 5.x 的新特性

RocketMQ 5.x 版本的新特性涵盖了两个方面：首先，它增强了那些广受用户关注并频繁使用的核心功能，这些功能在实际应用中发挥着至关重要的作用；其次，该版本还引入了一系列全新的功能特性，这些新功能将进一步丰富 RocketMQ 的应用场景，并提升其在消息流处理中的性能和效率。

RocketMQ 5.x Arch

RocketMQ 5.x 的架构相较于 4.x 有了显著的变化，新增了几个关键组件，使得整个系统更加完善和高效。在部署 RocketMQ 时，我们会按照一定的顺序进行：首先是 Namesrv、控制器、Broker，然后是 Proxy，最后是生产消费环节。

在生产消费环节中，有两种类型的客户端：一种是基于 TCP 的生产者，通常使用 Remoting 协议，这是 4.x 版本常用的客户端；另一种则是 gRPC 客户端，在代码仓库中被称为 RocketMQ Clients。这些客户端通过不同的协议和端口与各个组件进行通信。

展开全文

以 Namesrv 和 Broker 之间的通信为例，当 Namesrv 启动后，它会提供一个注册服务。接着，在启动 Broker 时， Broker 会根据配置的 Namesrv 地址将自己的心跳信息上报给 Namesrv。这个过程中，Broker 会使用 Remoting 协议通过 9876 端口将 Topic 的路由信息上报给 Namesrv。同时，如果存在控制器，Broker 还会通过 19876 端口向控制器上报状态信息，以便在主从切换时进行管理。

在 RocketMQ 4.x 中，生产者在发送消息前会先通过 Namesrv 获取路由信息，然后根据这些信息将消息发送给相应的 Broker。同样地，消费者在消费消息时也会先从 Namesrv 获取路由信息，然后再根据这些信息从指定的 Broker 中拉取消息进行消费。这种机制确保了消息能够准确、高效地传输到目标 Broker 并被正确消费。

RocketMQ 5.x 与 4.x 之间的一个显著差异在于客户端的变化。在 5.x 版本中，客户端采用了 gRPC 通信方式，与 4.x 的客户端相比，它不再持有路由信息。这种改变简化了客户端的角色和责任。

当 gRPC 客户端需要发送消息时，它会直接发送一个 RPC 请求给 Proxy 组件。在这个过程中，Proxy 扮演了之前 Remoting Client 的角色。Proxy 会负责先去 Namesrv 上获取 Topic 的路由信息，然后根据这些信息决定将消息发送给哪个 Broker。这就是 5.x 版本中消息发送的过程。

在消费消息时，过程也是类似的。gRPC 客户端通过发送 Pop 的 gRPC 请求给 Proxy 来请求消息。Proxy 在访问 Broker 时使用 Pop 协议，这种协议解决了之前 Push Consumer 可能遇到的消息堆积和卡住的问题。通过 Pop 协议，消费者可以更灵活地拉取和处理消息，提高了系统的整体性能和可靠性。

总的来说，RocketMQ 5.x 通过引入 gRPC 客户端和 Proxy 组件，以及使用 Pop 协议进行消费，实现了更高效、更灵活的消息处理机制。这些改进有助于提升系统的可扩展性、性能和用户体验。

RocketMQ Proxy

RocketMQ 在 5.x 版本中引入了 Proxy 组件，这是其向云原生架构转型的初步尝试。Proxy 在系统中扮演了关键角色，负责处理客户端的连接、计算路由信息以及管理消息的续期等逻辑。