前面我们简单介绍过NameServer和Broker是如何实现高可用的，NameServer是数据集中集群。现在我们重点来看下RocketMQ4.5版本以后的Broker高可用原理

深入探索：利用日志服务查看API调用日志

RocketMQ是一款低延迟、高并发、高可用、高可靠的分布式消息中间件。其除了可为分布式应用提供异步解耦的能力，还在大促峰值期间提供了蓄洪、消费限速、失败重试等能力，且具备高可用、负载均衡、消息可追溯等特性。 以下将从客户端源码阅读入手，从其调度消费链路以及高可用角度进行对其进行深入了解。

上一章节，我们了解了RocketMQ持久化原理的MessageQueue、消息发送和消息存储，现在我们学习一下RocketMQ持久化原理的存储性能优化。

数据在RocketMQ中是分布式存储的。生产者发送消息时，先从NameServer获取到路由信息，然后根据一定算法将消息发送到某个Master-Broker中。但是，Topic是一个逻辑概念，对于某个Topic来说，属于它的消息分布在不同的Broker上，那如何决定消息到底分布在哪个Broker上呢？现在我们先了解一下MessageQueue、消息发送和消息存储。

Nameserver和Zookeeper在用途和功能上有一些相似之处，都用于管理分布式系统的配置信息和命名服务。然而，它们的具体实现和使用场景有所不同。Nameserver主要用于域名解析，关注于将域名映射到相应的IP地址，提供域名服务；而Zookeeper主要用于分布式系统的协调和管理，关注于分布式数据的一致性和共享，提供分布式协调服务。

生产部署前一般都需要进行性能测试，所以本章我们来看下如何对RocketMQ进行性能测试

Rocketmq是由国人开发，贡献给Apache组织的项目，其采用Java语言开发。经过历年双十一流量洪峰的洗礼，并发性和可靠性得到了充分的验证，且支持的功能丰富，是活跃度较高的中间件之一，由于中文文档丰富，在国内很有市场。

我们介绍了RocketMQ的基本架构，并对其中的NameServer、Broker、Producer、Customer这四个核心组件进行了简要讲解。RocketMQ实现高可用和可扩展的思路其实没什么新意，就是基于Raft协议的主从架构，以及数据分散集群模式。

介绍RocketMQ的死信队列功能

RocketMq的多种集群模式

rocketMq热点队列扩散处理方式

RocketMQ 支持 HTTP 协议，以便非 Java 语言的开发者更方便地使用其消息发送和消费功能。本文介绍实现客户端无状态消费，支持消息生产、消息消费接口，允许消费方主动ACK 的 RocketMQ的 HTTP RESTful接入服务实现原理

消息队列RocketMQ是一种高可用的消息队列系统，它能够保证消息传递的可靠性和稳定性。为了测试RocketMQ的高可用性，可以采取以下步骤： 部署多个RocketMQ实例，并将它们组成一个集群。 向集群中的某一个实例发送大量的消息，并观察消息是否能够被其他实例成功消费。 测试单个实例的故障转移能力，比如关闭一个实例，观察剩余实例是否能够继续正常工作，并且已经发送但未被消费的消息是否能够被其他实例消费。 测试整个集群的故障转移能力，比如关闭多个实例，观察剩余实例是否能够继续正常工作，并且已经发送但未被消费的消息是否能够被其他实例消费。 通过以上测试，可以验证RocketMQ的高可用性，确保其在生产环境中能够稳定运行。

RocketMQ4.x可观测主要是基于消息轨迹来实现，在发送消息和消费消息时，将上下文中的参数添加进轨迹消息，将轨迹数据数据当成消息保存到本身集群中。而从5.x版本使用Telemetry遥测协议将可观测开关以及接入点下发到客户端，将客户端上报的所有可观测消息在Proxy侧做收敛，再统一使用标准的OpenTelemetry和Opencensu两个协议上报到SLS，SLS再通过TLog的方式与Prometheus、Grafana进行对接，来支持标准化的可观测协议，达到更丰富的可观测能力。 即对于使用5.x gRPC SDK客户端的用户无法通过原本的轨迹消息进行可观测，而是需要借助于新的能力，我们想提供即使使用新的SDK客户端也能观察到原本的消息轨迹的支持。

RocketMQ服务端通过CommitLog存储消息数据，并使用ConsumeQueue来保存每条消息在CommitLog中的物理偏移量。然而通过对ConsumeQueue和CommitLog整体遍历寻找消息的方式无疑非常的低效。因此，RocketMQ设计IndexFile支持通过唯一Key和时间范围来快速查询检索消息。

使用GO语言访问RocketMQ

rocketmq消息采用顺序写入追求极高的写入性能，本文主要聚焦rocketmq的磁盘写入以及主从复制分析消息写入流程

在一些跨地域管控业务中，需要对多个地域的服务进行同时的变更，例如异地双活业务切流，需要同时变更2个地域的路由规则，将某个地域的业务转移到另外一个地域中。 跨地域管控的问题在于，用户VPC是封闭的，网络通道是单向的，一般正常情况下是无法从VPC外部对内部服务进行访问的。 本方案提出一种基于预置逆向网络代理服务的方式，实现公有云上管控中心与用户VPC直通的跨地域管控方法。

从源码层面剖析rocketmq如何实现任意延迟消息

RocketMQ是一款具备低延时、高性能的消息队列产品。单个消费进程是有性能的上限的。不同的业务场景，消耗的时间不同。短则毫秒级，长则可能几秒甚至几分钟。 为了提高消费的性能，需要可以并行去消费消息。并行消费消息的时候，通过消费的负载均衡，把消费的任务分摊到多个消费者实例上，提高整体的消费性能。