云原生消息流系统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 在系统中扮演了关键角色，负责处理客户端的连接、计算路由信息以及管理消息的续期等逻辑。