自己网站建设要维护,网站建设与维护专业,广东高职一流专业建设专题网站,钓鱼网站网址导语
随着云计算技术的日益成熟#xff0c;云原生应用已逐渐成为企业数字化转型的核心驱动力。在这一大背景下#xff0c;高效、稳定、可扩展的消息流系统显得尤为重要。腾讯云高级开发工程师李伟先生#xff0c;凭借其深厚的技术功底和丰富的实战经验#xff0c;为我们带…导语
随着云计算技术的日益成熟云原生应用已逐渐成为企业数字化转型的核心驱动力。在这一大背景下高效、稳定、可扩展的消息流系统显得尤为重要。腾讯云高级开发工程师李伟先生凭借其深厚的技术功底和丰富的实战经验为我们带来了《云原生消息流系统 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 在系统中扮演了关键角色负责处理客户端的连接、计算路由信息以及管理消息的续期等逻辑。
在这个新架构下RocketMQ 的层次结构被划分为三层。最上层是用户层负责消息的生产和消费。中间层是 Proxy 层也被称为计算层。这一层主要负责处理客户端的连接请求执行路由计算以及处理消息的续期等关键逻辑。最下层是存储层包括 Namesrv 和 Broker。Namesrv 仍然负责存储元数据如 Topic 的路由信息和 Broker 的列表。而 Broker 则负责存储实际的消息数据、Consumer 队列以及索引等信息。
通过这种层次划分RocketMQ 5.x 实现了更清晰、更灵活的系统架构。Proxy 层的引入不仅提升了系统的可扩展性和可维护性还为用户提供了更便捷、更高效的消息处理体验。
RocketMQ Proxy 是一个专门为 RocketMQ 协议设计的代理服务。目前它主要支持 gRPC 客户端的连接并对 Remoting 协议提供了部分接口支持。通过引入计算层即 Proxy 层RocketMQ 在云环境中的优势变得更为明显。对于服务提供者来说计算和存储资源可以根据实际需求进行灵活部署并按需计费。这种灵活性不仅提高了资源的利用率也使得客户能够更经济高效地使用 RocketMQ 服务。
优势
RocketMQ Proxy 的优势非常显著主要表现在以下几个方面
首先它实现了存算分离。这意味着存储和计算资源可以完全按需付费为用户提供了更高的灵活性和成本效益。用户可以根据实际需求调整存储和计算资源的配比从而更有效地利用资源并控制成本。
其次RocketMQ Proxy 基于 gRPC 协议支持多种编程语言的客户端如 C、Python、Go 等。这一特性极大地简化了不同技术栈用户的使用体验。在过去Remoting 客户端需要针对不同语言进行单独实现而社区版中 Remoting 客户端在各语言中的功能并不对等Java 版本最为完整和稳定。然而有了 Proxy 之后各种语言的客户端逻辑都变得非常简单本质上就是一个 RPC 客户端。这意味着一旦 RPC 客户端稳定下来基本不需要改动代码各种语言和技术栈的用户都可以方便地使用 RocketMQ。
最后RocketMQ Proxy 有助于收敛云上的复杂性。在没有 Proxy 的情况下用户需要直接访问 Namesrv 和 Broker这涉及到复杂的网络配置和隔离问题。然而有了 Proxy 之后用户只需要与 Proxy 进行网络联通无需关心内部细节。这种对内复杂、对外简单的设计理念使得客户看起来更简单从而降低了整体复杂性。此外Proxy 可以充当 HDPHighly Distributed Platform的角色进一步简化了用户的接入过程。 功能预测
讲师对 Proxy 功能未来的发展做出了一些预测
● 流量调度灰度、迁移
首先是流量调度包括灰度发布和迁移。讲师认为随着 Proxy 的功能越来越接近网关它可能会承担起流量调度、灰度发布和迁移的任务。例如在进行跨云多活部署时如果某个云服务出现故障我们需要能够迅速切换到其他服务。这就需要一个上层的调度组件来管理集群间的切换而 Proxy 正是这个角色的理想选择。
● Namesrv、Broker 故障切换
其次是 Namesrv 和 Broker 的故障切换。在正常的发布迭代过程中当 Broker 出现 Bug 并修复后我们需要进行灰度测试以确保新的版本没有问题。这时就需要进行流量灰度可以根据流量、用户等因素来进行。在 RocketMQ 中Proxy 应该承担起这部分的责任负责灰度策略的实施。
● 统一鉴权
最后是统一鉴权。对于 RocketMQ 内部而言Proxy、Namesrv 和 Broker 是紧密集成的不需要进行鉴权。但是对于外部客户来说我们需要确保他们只能访问到他们被授权访问的数据。因此未来 Proxy 可能会支持鉴权功能以防止数据被错误地读取或泄露从而保护我们的数据安全。
如果 Proxy 能够支持以上三个预测的功能那么它的角色将更接近于一个全功能的网关其功能将比现在更加强大和全面。
Pop messages
客户可能会遇到一些问题比如当消费者卡住或不消费时我们不清楚具体原因业务也可能受到影响。在高峰期重启消费者又怕触发Rebalance导致消息延迟对业务造成不良影响。这种情况下用户会质疑我们能否承担责任处理起来非常棘手。Pop Consumer 的出现就是为了解决这些问题。
在 Pop Consumer 模型中假设有三个实例即三个进程属于相同的消费者组每个实例都可以消费所有队列的消息。每个实例在拉取队列时都会进行加法运算然后下一个实例再拉取下一个队列。这种模型与 Push 模型不同Push 模型一旦分配好消费队列比如 Consumer3 确定消费最后两个队列在 Rebalance 之前它只能消费这两个队列。如果它卡住了或发生其他不明状况导致不消费特别是在高峰期重启会带来很大的困扰容易造成消息延迟。这对于金融等对时间敏感的场景来说是不可接受的因为交易慢一秒可能就意味着巨大的成本损失。
而 Pop Consumer 模型有一个 Retry 机制与以前的机制略有不同。当所有 Pop 实例拉取消息时会有一定的概率可以拉取到从事的消息这里可能是指之前未处理成功的消息。这个概率是通过一个随机数算法计算出来的以确定何时可以拉取到 Pop 的从事消息。这样即使某个实例卡住或不消费其他实例仍有机会处理这些消息从而保证了系统的可靠性和稳定性。 Pop and ACK 上面这个图展示了 Pop 消费在 Broker 端拉取消息以及进行 ACK 确认的整个过程。
整个过程从 gRPC 客户端发起请求开始这个请求会先到达 Proxy。Proxy 接着会向 Broker 发送一个 Pop 请求。Broker 收到请求后的第一步是确定要拉取哪个 Queue并将这个 Queue 锁定。锁定期间其他 Pop 客户端或实例将无法拉取这个 Queue 的消息。
锁定 Queue 后Broker 会根据当前的消费位点计算并决定从哪个位置开始拉取消息。确定位置后Broker 会从 Committer 中拉取消息并在此过程中写入一个 Check Point。这个 Check Point 非常重要它记录了哪些位点的消息已经被拉取用于后续的 ACK 确认。
拉取到的消息会进入一个不可见的时间段。这意味着如果 Queue 被释放了其他客户端或实例在拉取消息时会从上一批拉取的最后一条消息的下一条开始。这是因为当前这批消息已经处于不可见状态。
写完 Check Point 后Broker 会释放锁定的 Queue并将拉取到的消息进行包装后返回给 Proxy。Proxy 再通过JRC将消息返回给客户端完成整个 Pop 过程。
与 Push 过程相比Pop 过程的不同之处在于它不会一直锁定 Queue。一旦 Queue 被释放其他 Pop Consumer 实例就可以继续拉取并消费这个消息。这意味着如果之前拉取某个 Queue 的 Pop 实例停止消费其他实例可以接管并继续消费这个消息避免了需要切换消费者或生产者的麻烦。
ACK
当客户端消费完消息后会触发一个 ACK 流程这是确保消息被成功处理的关键步骤。ACK主要分为两大步骤
生成 Checkpoint 与消息句柄在返回消息给客户端时系统会生成一个 Checkpoint这是一个记录消息处理进度的标记。同时还会生成一个消息句柄它是由 Broker Name、QID队列ID和位点信息组合而成的一个字符串。这个句柄在 ACK 时会被客户端携带用于在内存中匹配和确认消息。
内存匹配与位点持久化当客户端发送 ACK 请求时系统会在内存中进行匹配操作。这意味着当客户端确认一条消息时系统会检查这条消息是否与之前拉取的消息匹配。如果所有拉取的消息都被成功 ACK那么 Checkpoint 对应的位点信息就会被持久化保存。这样在下次拉取消息时系统就会从这个持久化的位点开始确保不会拉取到重复的消息。
在某些情况下比如客户端处理消息耗时较长再来进行 ACK 时可能内存中已经没有相关数据了。为了处理这种情况RocketMQ 会将 Checkpoint 的消息持久化到一个特定的 Topic 中并定期重新消费这个 Topic 的消息来进行异步匹配。
Pop 和 ACK 的过程主要实现在 PopMessageProcessor 和 PopBufferMergeService 两个组件中。其中MergeService 负责将 ACK 和 Checkpoint 消息进行匹配并在所有消息都被 ACK 后更新消费的进度。
Pop 的优势
相比于 Push 模型Pop 模型有以下优势
客户端简单性由于 Pop 客户端基于 gRPC 实现因此相对更简单。这种简单性有助于实现快速稳定并减少客户端更新的需求。
无状态性Pop 模型的无状态特性使得切换和升级更加容易实现。
多语言生态支持利用 gRPC 的多语言支持能力Pop 模型在生成不同语言的客户端时能够保持逻辑上的一致性。
思考性问题
为什么 Pop 客户端会比较简单答因为它基于 gRPC 客户端实现而 gRPC 客户端本身具有简单性。
Pop 是否可以替换 PULL并集成到Flink等流平台中答这是一个值得探讨的问题。理论上Pop 由于其无状态性和简单性可能更适合某些流处理场景。然而具体是否能替换 PULL 并集成到 Flink 等平台中还需要考虑平台兼容性、性能需求以及业务需求等多方面因素。
Delay Message
RocketMQ 5.x 中的延迟消息机制与 4.x 版本有所不同。在 4.x 版本中延迟消息是通过一个固定的 Schedule_Topic_XXXX 来实现的它默认支持最多16个队列。每个队列对应一个延迟级别并且每个级别都有一个定时器timer与之关联。这些定时器会定时触发对应级别的延迟消息。当某个延迟级别的消息被触发后系统会启动一个新的定时器来处理下一个延迟级别。然而如果支持的队列数量过多系统的负担会加重可能会影响整体的稳定性。
在 4.x 版本中延迟消息的处理过程是这样的当延迟级别的消息被触发时定时器中的一个报告服务Report Service会将该消息重新发送到正常的 Topic 中这样用户就可以消费到这条消息了。但这种方式存在一些问题比如系统负担过重和稳定性问题等。
因此在 RocketMQ 5.x 中延迟消息的处理机制可能有所改进和优化以解决 4.x 版本中存在的问题。 Timer Message
在 RocketMQ 5.x 中引入了任意维度的定时消息功能这是一个重要的改进。需要注意的是延迟消息和定时消息并不完全相同。在新版本中定时消息也被称作 Timer Message是通过时间轮技术来实现的这种技术能够更有效地处理和管理定时任务提高了系统的性能和稳定性。 RocketMQ 5.x 引入了时间轮模型来实现任意维度的定时消息功能这是一个重要的技术改进。时间轮主要由一些小格子组成每个小格子代表一定的时间单位在 5.x 中默认是每秒。这些格子就像时钟的刻度一样随着时间推进而转动。每个格子或者称为 Slot对应一个定时消息的触发点。
当时间推进到某个特定的 Slot 时系统会检查该 Slot 中是否有定时消息需要触发。这些消息被组织成一个链表链表的每个节点都包含一条定时消息的相关信息。当时间到达链表中某个消息的定时点时系统就会触发该消息。
为了高效处理这些定时消息RocketMQ 5.x 使用了指针和链表的数据结构。每个 Slot 都有一个指针指向其对应的消息链表这样系统就可以快速地找到并处理到期的定时消息。同时RocketMQ 还使用了一个称为 Timer Commit Log 的机制来顺序存储这些定时消息以确保消息的有序性和可靠性。
时间轮模型的好处在于它支持更大范围的定时消息并且性能更好。与以前的模型相比时间轮模型可以处理更多的定时消息同时保持较高的处理效率。此外由于时间轮是循环的所以它可以支持超过48小时的定时消息。当时间超过48小时时时间轮会回到起点并继续下一个周期。
在实现上RocketMQ 5.x 通过异步线程池来处理消息的扭转和触发过程。当一条正常的消息进入系统时它首先被发送到一个专门的 Timer Topic 中。然后异步线程将消息转化为时间轮格式并生成相应的 Timer Log 文件。接着触发器服务会根据时间轮的当前位置来判断是否有定时消息需要触发并根据 Slot 中的指针来找到并处理这些消息。
然而需要注意的是虽然 RocketMQ 5.x 支持了任意维度的定时消息功能但目前并不支持未到期消息的取消操作。这意味着一旦一条定时消息被发送出去就无法在到期之前撤销它。这是当前版本的一个限制未来可能会考虑增加相关的功能来满足用户的需求。
另外关于 4.x 版本的支持情况目前社区上的新版本并不支持时间轮模型的任意延迟消息功能。但是腾讯云上的 4.x 版本已经实现了基于时间轮的任意延迟消息支持为用户提供了更多的选择和灵活性。
5.x 其他特性介绍
以下是关于 RocketMQ 从4.8到5.0版本的一些重要特性的简要解释
● Dledger这是一个容器化的存储方案作为第三方的 Commit Log 使用并支持 Cloud Direct 协议的多副本功能提供数据的冗余和可靠性。
● Dledger Controller这是 RocketMQ 5.x 引入的一个组件用于控制和切换 Dledger 的组成确保数据的一致性和高可用性。
● Request-Reply类似于 RC 协议它要求生产者在发送消息后必须等待消费者的确认。只有当消费者确认收到消息后生产者才会继续发送下一条消息。这确保了消息的可靠传递但可能会增加延迟。
● Broker Container这个特性允许用户在一个进程内运行多个 Broker 实例这些实例可以相互备份提高了系统的容错性和可扩展性。
● Logic Queue / Static Topic / Dynamic Topic逻辑队列是 RocketMQ 中的一个新概念它同时支持静态 Topic 和动态 Topic。静态 Topic 的队列数量是固定的而动态 Topic 的队列数量可以根据 Broker 的数量动态调整。这对于需要灵活扩展的系统非常有用。同时逻辑队列对应的物理队列可以在不影响上层应用的情况下进行替换或调整。
● Light Message Queue轻量级队列设计用于解决大量 Topic 和源数据过大的问题。通过使用轻量级队列可以减小源数据的大小提高系统的处理效率。
● Compaction Topic这个特性主要针对计算平台允许用户像存储普通 Topic 一样存储基于 KV 的状态数据。它提供了写快读慢的特性使得随机读取更加方便。这对于需要维护状态的应用非常有用。
● MQTT (Millions Topic)RocketMQ 现在支持 MQTT 协议这使得它能够处理数百万的 Topic 和队列并支持数百万甚至上亿的设备连接。这对于物联网等需要处理大量设备数据的场景非常有用。
● gRPC ClientRocketMQ 5.x 引入了 gRPC 客户端提供了更多的通信选项和更好的跨平台支持。
● OT Open Telemetry (Prometheus, OT, Log)这个特性主要关注可观测性集成了日志、Metrics 和 Tracing 等功能可以直接与 Prometheus 等监控系统集成提供全面的系统监控和诊断能力。
RocketMQ 上云实践
容器化实践
容器化本质上是为了解决交付的问题。交付在这里指的是进程管理进程管理包含进程的运行以及进程运行时包含的资源等。进程管理是操作系统的一个核心功能它涉及到对系统进程的控制包括创建Create、读取Read通常指查看进程状态、更新Update比如改变进程优先级和删除Delete进程类似 CRUD 操作。
容器技术如 Docker 和 KubernetesK8s提供了解决这些问题的工具和平台。
容器化进程标准化
容器化解决了进程标准化的问题因为只有标准化了以后才能批量生产。
标准化有哪些?
● 进程和进程的生命周期
在 KubernetesK8s中进程的状态转换被重新定义和抽象化。如果我们将传统进程的状态转换视为一个简单的过程如左图所示那么 Kubernetes 则为这些状态转换提供了一个更加复杂但更加健壮的框架如右图所示。Kubernetes 追求的是“最终一致性”这意味着当系统从一个状态向另一个状态转换时它会持续进行调度和调整直到最终达到预期的状态为止。这种机制确保了系统的稳定性和可靠性即使在面临各种挑战和变化时也能保持一致性。 ● 进程管理
当用户需要管理成千上万甚至数十万个进程时传统的管理方式如使用脚本或自己编写的插件或组件并将其嵌入到虚拟机或容器中可能会变得非常繁琐和复杂。然而一旦 Kubernetes 成为管理这些进程的标准化工具它就会提供一套统一且标准化的管理方式。通过 Kubernetes 的控制器和管理器用户可以更加高效地管理和调度这些进程从而简化管理流程并提高系统的可靠性和性能。
● 进程资源隔离
Kubernetes 主要通过 Cgroups控制组来实现 CPU 和内存的隔离确保每个容器都能获得其所需的计算资源并且不会相互干扰。同时在网络方面Kubernetes 使用命名空间来进行标准化的隔离确保每个容器的网络通信都是独立且安全的。这种隔离机制使得多个容器可以在同一台宿主机上高效、稳定地运行而不会相互影响。
● 跨 AZ跨 Region 交付
利用 Kubernetes用户可以轻松实现跨可用区AZ和跨区域的交付。只需为资源打上相应的标签Tag或Label或者添加一个亲和性策略即可实现这一目的。这些亲和性策略还可以根据用户的实际需求进行自定义。这样的机制大大简化了跨地域部署和管理的复杂性。
上图中右边的部分其实就是 KubeletK8S 对于进程状态的实现Kubelet 的实现。当进程启动重新部署后Kubelet 会帮用户自动的把这三个状态进行扭转直到这个状态为最终态为止。
容器化运行时标准化
● 标准化分发包
容器化技术为软件分发提供了标准化的方式。在进程管理之前应用程序及其所有依赖项会被打包成一个容器镜像。这种打包方式使得软件可以方便地分发给不同的客户无论是私有云、公有云用户还是其他类型的用户。因为容器镜像是标准化的所以它们可以轻松地实现量产和部署。
● 标准化运行环境
除了分发包外容器化技术还标准化了进程的运行环境。这意味着无论进程是否依赖于特定的系统库如SMD、Library、SO 等或 Java 的 JDK 等组件容器都能提供一个一致的运行环境。
在下图中这种标准化运行环境主要分为两层
静态层 - 镜像Image这一层包含了应用程序运行所需的所有静态依赖项。例如Java应用程序可能包含 JDK、阿尔萨斯调试工具等C 或 Python 程序可能依赖于特定的库或第三方共享对象SO。这些依赖项都被标准化并封装在容器镜像中。镜像采用分层存储的方式每一层都存储了不同的内容最终为应用程序提供了一个完整的运行环境。
动态层 - 容器Container当从镜像启动一个实例时就创建了一个容器。这个容器是动态的它包含了进程运行时所需的资源如 CPU、内存、持久化卷声明PVC、配置信息以及网络设置等。这些资源在进程启动并转化为容器时由容器运行时自动初始化。这种标准化的环境确保了无论在 Kubernetes 环境的哪个部分运行容器其表现都是一致的。
通过这种方式容器化技术大大简化了软件分发和部署的复杂性同时确保了应用程序在不同环境中都能以一致和可靠的方式运行。
容器化其他优势
只有有了标准化的进程标准化的运行环境和定义的进程生命周期之后才能做到标准化和分发。这时候用户的扩容缩容运维才会更方便。
● 快速扩容 / 缩容
● 标准化运维
● 多进程 HA跨 AZ、跨 Region 交付更简单
● 交付更快、更可靠
容器化提高资源利用率
容器化通过标准化进程管理使得用户可以轻松地同时管理多达50万个进程这不仅简化了进程管理的复杂性还提高了资源的利用率。然而对于许多企业决策者来说他们更关心的是容器化是否能够真正实现降本增效。
事实上降本增效是一个包含两个方面的目标而这两个目标往往难以同时实现。容器化主要贡献在于提高资源利用率。在传统的管理方式下进程往往是散乱分布的很难确保资源得到最大化利用。进程与进程之间可能存在较大的资源间隙。但是通过 Kubernetes 的标准化管理每个进程都可以根据实际需求进行资源申请。Kubernetes 使用 Cgroups 等技术对 CPU 和内存进行隔离确保所有资源都在一个统一的资源池中进行分配。
这种资源池的方式意味着系统可以根据实际需求动态地分配资源尽可能保持 CPU 利用率在40%或50%以上从而提高整体资源利用率。这就像是在一个大家庭中共享食物和水源每个人都可以按需取用避免了浪费。
然而尽管容器化可以提高资源利用率但它并不能直接降低成本。正如一位 Kubernetes 领域的大佬所说“RocketMQ 就是一个人容器化前吃喝多少容器化后也会吃喝多少”这意味着无论是否进行容器化系统的总体资源消耗并不会减少。因此我们不能期望通过容器化来直接降低成本。但是通过提高资源利用率企业可以更加高效地利用现有资源从而间接地实现成本优化和效率提升。 RocketMQ 容器化需要重点关注哪些呢
容器化选择容器平台
腾讯内部有多套容器化平台TKE 标准版 TKE Serverless 等都是久经考验的稳定可靠。腾讯云 RocketMQ 是基于 TKE Serverless 容器平台打造。
TKE Serverless 是腾讯云推出的无须用户购买节点即可部署工作负载的服务模式集群完全兼容原生 Kubernetes支持使用原生方式购买及管理资源按照容器真实使用的资源量计费。TKE Serverless 集群还扩展支持腾讯云的存储及网络等产品同时确保用户容器的安全隔离开箱即用。
在 RocketMQ 容器化选择容器平台时主要考虑
● 是否需要备货
TKE Serverless 无需备货。货源在大池子里无需购买 Node 添加到容器平台大池子货源相对充足。当然也能提高大池子资源利用率。
● 按使用量付费不浪费 CPU、Mem
● 支持固定 IP
在 Pod 重启前后Pod IP 保持不变。
● 支持 VPC-CNIIP 打平
容器化复杂的网络 容器化网络之所以复杂原因在于同一个 RocketMQ 集群需要为多种场景提供服务。这些场景可能包括位于腾讯不同 VPC虚拟私有云内的服务、公网上的服务、开发调试环境、办公环境甚至是位于客户自建机房或其他云服务提供商的服务。每种场景的网络环境都各不相同且彼此间可能并不直接相通。
当用户尝试访问 RocketMQ 集群时他们通常首先从服务器获取路由信息这些信息会返回一个IP列表然后用户通过这个列表与 RocketMQ 集群进行交互。但是难点在于如何让这同一套 RocketMQ 集群能够适应并处理上述所有不同场景的网络接入需求。
为了解决这个问题我们需要实现网络的打通并确保路由信息的实时更新。当网络策略发生变化时这些路由信息必须能够迅速、准确地反映最新的网络状态。这样无论用户从哪个环境、哪个位置访问都能顺畅地连接到 RocketMQ 集群获取所需的服务。这是一个既具挑战性又十分必要的任务以确保 RocketMQ 集群的高效、稳定运行。
容器化其他问题
配置一致性问题
容器化 RocketMQ 时配置文件可以通过 Config Map 下发。同时在不重启进程的前提下也可以通过 Admin API 修改两者需要保持数据一致。
存储问题
在重启前后配置文件、数据文件所挂载的 PVC 需要保持不变。
公有云、私有化兼顾问题
做资源层抽象可以同时适配公有云和私有化的各种容器平台甚至非容器平台。
yaml 、 helm chart 、 operator, 怎么选
分层存储实践
分层存储架构 上图主要描述了两个分发过程Commit Log 的分发和分层存储的分发。
对于 Commit Log 的分发它与常规流程相同。当用户发送一条消息时该消息会被写入 Commit Log 中。随后通过两个异步的 Dispatcher系统会分发并构建 Consumer Queue 的索引和 Index 索引。
在 5.x 版本中分层存储的实现是通过新增一个 Dispatcher 来实现的。这个新的 Dispatcher 会被注册到原有的 Dispatcher 中。当用户写入数据时数据会异步地分发到分层存储的 Commit Log 里。一旦数据被分发到这里新的 Dispatcher 会负责将数据最终分发到 Index File 或 Consumer Queue 中。这些 Index File 和 Consumer Queue 的底层实际上是通过腾讯云上的对象存储来实现的。因此文件会被存储在腾讯云的对象存储里。这个异步分发过程与 Commit Log 的分发过程非常相似。
在生产过程中数据会经历上述的分发和存储过程。而在消费过程中系统会首先尝试从缓存中读取数据。如果缓存中的消息数量不足系统会通过 Consumer Queue 和 Commit Log 的Offset 来定位并读取分层存储中的数据。主要的过程仍然涉及到 Dispatcher 和数据的读取。
简而言之这段描述解释了在一个消息系统中消息是如何被写入、分发、存储和读取的特别是涉及到 Commit Log 和分层存储的部分。
分层存储优势
● Topic TTL自研支持社区不支持
● 冷热数据分级存储
● 真正海量、低成本存储
分布式限流实践
分布式限流架构 在 5.x 版本中我们引入了分布式限流机制这实际上是对集中限流的一种补充。在共享集群中由于存在多租户隔离的需求我们希望每个用户都能按照其购买的 TPS每秒传输次数进行使用而不影响其他用户。因此当用户超过其购买的 TPS 时我们会对其进行限流以确保整个系统的稳定性和公平性。
当然在实施限流的同时我们也会向用户发送告警信息让他们知道当前的流量已经超过了限制需要采取相应措施进行控制。
那么为什么在 5.x 版本中需要引入分布式限流呢这主要是因为 RocketMQ Proxy 在处理流量时存在一些热点问题。尽管 Proxy 现在是无状态的但在处理客户端连接、消息生产和消费确认ACK时仍然存在一定的局限性。具体来说当一个客户端连接到某个 Proxy 进行消息生产或消费时该 Proxy 会负责处理所有的 ACK 确认信息。这是因为只有该 Proxy 才能识别并处理相应的 Check Point 信息。因此当某个 Proxy 上的消息流量过大时其他 Proxy 无法有效地分担其压力。
为了解决这个问题我们引入了分布式限流机制。在这个机制中我们设置了一个集中的管理节点负责定期向各个 Proxy 节点下发流量配额Quota。这样一来即使某个 Proxy 节点上的流量过大也能通过限流机制确保整个系统的稳定性和可用性。同时这也使得其他 Proxy 节点能够在必要时提供一定的支持从而更有效地利用系统资源。
分布式限流特点
● 限流类型全局 or 本地
● 限流维度标签键值对客户端通过标签匹配规则
● 限流阈值请求数/统计周期如 1000/s
● 降级策略当网络等原因导致请求server失败时降级为单机限流 or 直接放行
● 限流效果快速失败 or 均匀排队
● 优先级0-9降序适用多条规则匹配的场景例如通配符和精确匹配
未来规划
未来作者将继续致力于 RocketMQ 的社区布道工作通过撰写技术文章、参与技术交流活动等方式让更多开发者了解并熟悉 RocketMQ 4.x 及 5.x 版本的新特性推动其在行业内的广泛应用。同时作为公司与社区之间的桥梁他将积极分享腾讯云上关于 RocketMQ 的实践经验和代码将久经考验的技术成果回馈给社区助力开源生态的繁荣发展。
在职业发展上作者坚信稳定性是任何系统的基石因此他将持续关注并提升 RocketMQ 在稳定性和可靠性方面的表现。此外作者将始终坚持以用户价值为导向深入了解用户的需求和痛点通过技术创新和产品优化为用户提供更加高效、便捷的消息流处理解决方案。值得一提的是腾讯云 RocketMQ 5.x Serverless 版本已经上线这一新版本将为用户带来更多便利和可能性欢迎大家积极体验并提出宝贵意见。
展望未来期待与更多同行携手合作共同推动 RocketMQ 在云原生消息流系统领域的发展为企业的数字化转型提供强有力的技术支持。
总结
Apache RocketMQ 是一个可靠、高吞吐量、分布式的消息队列服务。 腾讯云作为中国领先的云计算服务商之一也大规模的提供了 Apache RocketMQ 服务。同时腾讯云也对 Apache RocketMQ 进行了一系列优化和定制以更好地适应公有云复杂的业务需求。 在这个过程中腾讯云也积累了大量的经验和技术包括如何优化 Apache RocketMQ 的性能、如何提高其可靠性、如何进行监控和调优等方面。这些经验对于其他企业和开发者也具有很大的参考价值 希望通过以上文章的深入剖析能够为广大技术同行提供有益的参考和启示。
