RocketMQ 集群。本书不仅由浅入深的介绍了 RocketMQ 的架 构与实现，而且包含了多年线上超大规模集群开发运维经验的总结，通过本书不仅能够掌握 分布式消息平台的设计原理，对线上疑难问题排查分析、性能调优与架构设计也大有帮助。 目录 开篇：我的另一种参与 RocketMQ 开源社区的方式 6 1.1 RocketMQ 核心概念扫盲篇 10 1.2 生产环境中，autoCreateTopicEnable 2 从异步复制的配置示例；2m-noslave 是 2 主的示例 配置。由于本文主要是搭建一个学习环境，故采取的部署架构为 1 主的部署架构，关于生产 环境下如何搭建 RocketMQ 集群、如何调优参数将在该专栏的后续文章中专门介绍。 Step3：修改 Nameserver jvm 参数 cd bin vi runserver.sh # 定位到如下代码 JAVA_OPT="${JAVA_OPT} setSuggestPullingFromSlave(diff > memory); // @3 代码@1：首先介绍一下几个局部变量的含义：  maxOffsetPy 当前最大的物理偏移量。返回的偏移量为已存入到操作系统的 PageCache 中的内容。  maxPhyOffsetPulling 本次消息拉取最大物理偏移量，按照消息顺序拉取的基本原则，可以基本预测下次开始 拉取的物理偏移量将大于该值，并且就在其附近。

异步消费。  Push Consumer Consumer 的一种，应用通常吐 Consumer 对象注册一个 Listener 接口，一旦收到消息，Consumer 对象立 刻回调 Listener 接口方法。  Pull Consumer Consumer 的一种，应用通常主劢调用 Consumer 的拉消息方法从 Broker 拉消息，主劢权由应用控制。  规范中描述的优兇级是挃在一个消息队列中，每条消息都有丌同的优兇级，一般用整数来描述，优兇级高的消 息兇投递，如果消息完全在一个内存队列中，那举在投递前可以挄照优兇级排序，令优兇级高的兇投递。 由亍 RocketMQ 所有消息都是持丽化的，所以如果挄照优兇级来排序，开销会非常大，因此 RocketMQ 没有特 意支持消息优兇级，但是可以通过发通的方式实现类似功能，即单独配置一个优兇级高的队列，和一个普通优兇级 ，和一个普通优兇级 的队列， 将丌同优兇级収送到丌同队列即可。 对亍优兇级问题，可以归纳为 2 类 1) 只要达到优兇级目的即可，丌是严格意丿上的优兇级，通常将优兇级划分为高、中、低，戒者再多几个级 别。每个优兇级可以用丌同的 topic 表示，収消息时，挃定丌同的 topic 来表示优兇级，返种方式可以解决 绝大部分的优兇级问题，但是对业务的优兇级精确性做了妥协。 2) 严格的优兇级，优兇级用整数表示，例如

的消息，返回消息的 offset 即消息地址 commitLog 中消息偏移量。Prepared 状态消息不被消费 发送消息 ok，执行本地事物分支， 本地事物方法需要实现 rocketmq 的回调接口 2）2） 2) LocalTransactionExecuter ， 处 理 本 地 事 物 逻 辑 返 回 处 理 的 事 物 状 态 LocalTransactionState 3) 二 RequestCode.SEND_MESSAGE 选 择 对 应 的 处 理 器 SendMessageProcessor 根据请求消息内容构建消息内部结构 MessageExtBrokerInner 调 DefaultMessageStore 加消息写入 commitlog 2.2 分布式事物消息落地 2.2.1 消息落地 commitLog 针对事物消息的处理，消息的第 20 状态的表格文件， 遍历存储事 务状态的表格记录 如果是已经提交或者回滚的消息调过过， 如果是 prepared 状态的如果消息小于事务回查至少间隔时间（默认是一分钟）跳出终 止遍历 调 transactionCheckExecuter.gotocheck 方法向 producer 回查事物状态， 根据 group 随机选择一台 producer 查询消息，根据 commitLogOffset

低延迟分布式存储系统 – PageCache的毛刺解决方案小结 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺解决方案小结 操作系统Page Cache Radix Tree 自旋锁，产生几秒的大毛刺 如果遇到坏盘，可能Block若干分钟，对系统产生致命影响。 操作系统Page Cache Radix Tree 每个Page的阻塞锁，产生几百毫秒小毛刺 写入数据平均响应时间不超过1ms 写入

低延迟分布式存储系统 – PageCache的毛刺解决方案小结 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺解决方案小结 操作系统Page Cache Radix Tree 自旋锁，产生几秒的大毛刺 如果遇到坏盘，可能Block若干分钟，对系统产生致命影响。 操作系统Page Cache Radix Tree 每个Page的阻塞锁，产生几百毫秒小毛刺 写入数据平均响应时间不超过1ms 写入

缺少稳定的多语⾔言类库 • Cloud AI Ops⽅方⾯面 • 容器器化部署，K8S编排 • 诸如IoT/IIoT新场景下的规模化部署能⼒力力不不⾜足 • HTTP/RESTful/JSON 灵活调⽤用，监控及运维能⼒力力不不⾜足 • Cloud云⼚厂商⽅方⾯面 • 不不同云⼚厂商之间消息产品互操作性成本较⾼高，⽤用户跨云⼚厂商迁移难 • 云上与云下产品的⽆无缝衔接能⼒力力差 云原⽣生与业界标准