《RocketMQ实战与原理解析》读书笔记

第1章　快速入门

1.1 消息队列功能介绍

1.1.1 应用解耦

1.1.2 流量削峰

1.1.3 消息分发

第2章　生产环境下的配置和使用

2.1 各部分角色介绍

2.2 多机集群配置和部署

2.2.1 启动多个 NameServer Broker

broker配置文件

2.2.2 配置参数介绍

2.3 发送／接收消息示例

2.4 常用管理命令

2.5 通过图形界面管理集群

第3章　用适合的方式发送和接收消息

3.1 不同类型的消费者

3.1.1 DefaultMQPushConsumer 的使用

3.1.2 DefaultMQPushConsumer 的处理流程

3.1.3 DefaultMQPushConsumer 的流量控制

3.1.4 DefaultMQPullConsumer

略

3.1.5 Consumer 的启动、关闭流程

3.2 不同类型的生产者

第4章　分布式消息队列的协调者

NameServer是整个消息队列中的状态服务器。

4.1 NameServer 的功能

消息队列中的各个组件定时上报自己的状态，如果超时会认为不可用，从可用列表里里面移出超时组件。

4.1.1 集群状态的存储结构

RouteInfoManager

4.1.2 状态维护逻辑

4.2 各个角色间的交互流程

4.2.1 流程源码分析

4.2.2 为何不用 ZooKeeper

简单来说，用不到ZooKeeper中复杂的功能，仅需要一个轻量级的元数据服务器，减少运维等相关成本。

4.3 底层通信机制

4.3.1 Remoting 模块

4.3.2 协议设计和编解码

4.3.3 Netty

Netty RemotingServer和NettyRemotingClient

第5章　消息队列的核心机制

Broker是消息队列的核心，主要包括消息的消费和生产、消息的持久化存储等功能。

5.1 消息存储和发送

通过 MappedByteBuffer 方式来提升消息存盘和网络发送的数据。

5.2 消息存储结构

5.3 高可用性机制

5.4 同步刷盘和异步刷盘

异步刷盘是写入内存中，等待一定量统一进行刷盘。
同步刷盘是真正写入磁盘后返回成功。

flushDiskType=ASYNC_FLUSH
flushDiskType=SYNC_FLUSH

5.5 同步复制和异步复制

brokerRole=ASYNC_MASTER
brokerRole=SYNC_MASTER
brokerRole=SLAVE

5.6 本章小结

第6章　可靠性优先的使用场景

6.1 顺序消息

顺序消息是指消息的消费顺序和产生的顺序相同，比如订单的生成、付款、发货，这3个消息必须按顺序处理。
顺序消息分为全局顺序消息和部分顺序消息。全局顺序消息是指某个TOPIC下的所有消息都要有序，部分顺序消息是指每一组消息被顺序消费即可。

6.1.1 全局顺序消息

默认不保证顺序，创建一个TOPIC会有8个读写队列，消息会被写入到任意一个队列中，多个消费者可能启动多个线程并行处理所以消息被那个消费者消费以及被消费的顺序和写入的顺序是否一致是不确定的。

如何保证全局顺序消息？

消除所有的并发处理，把它完全的变成一个队列先进先出这样才能保证全局顺序消息。

6.1.2 部分顺序消息

如何保证部分顺序消息？

同一个业务id的几个消息进入到一个读写队列中，消费的时候同一个队列不能被并发处理。

MessagelisteneOrderly

6.2 消息重复问题

消息队列存在的问题：确保一定投递和不重复投递。也就是所谓的有且仅有一次。

RocketMQ经过权衡保证了确保一定投递，但有可能造成消息重复。

重复的原因：Broker接收到消息但是没有正确返回发送成功的状态，MQ存在重试机制，就造成了消息重复。

    private int retryTimesWhenSendFailed = 2;

解决消息重复的方法？

方法一：确保消费逻辑的幂等性，也就是多次消费和一次消费的作用是一样的。
方法二：维护一个已消费记录，消费前查询这个消息是否被消费。

6.3 动态增减机器

6.3.1 动态增减 NameServer

6.3.2 动态、增减 Broker

6.4 各种故障对消息的影响

主从同步和刷盘策略均为同步模式下即使某台机器出现极端故障也不会丢消息。

6.5 消息优先级

队列是FIFO先入先出的数据结构不支持直接的优先级设置，只能通过间接的方式来设置。

6.6 本章小结

第7章　吞吐量优先的使用场景

7.1 Broker 端进行消息过滤

7.1.1 消息的Tag和Key

一个应用尽可能只用一个topic，不同子类型用Tag表示，对消息设置key，一般是业务唯一表示码。

7.1.2 通过 Tag 进行过滤

7.1.3 SQL 表达式的方式进行过滤

7.1.4 Filter Server 方式过滤

7.2 提高 Consumer 处理能力

为什么要提高消费者的处理能力？

生产者一直大于消费者会导致消息的积压，除了消费逻辑优化以外还有三种方式提高处理能力。

7.2.1 提高消费并行度

增加消费实例数量注意不要Read Queue的数量否则接收不到消息。

7.2.2 以批量的方式进行消费

例如update数据库，一次更新一条不如一次更新多条。

7.2.3 检测延时情况，跳过不重要的消息

7.3 Consumer 的负载均衡

消费者从broker中获取全局信息，自己来实现负载均衡。

7.3.1 DefaultMQPushConsumer 的负载均衡

主要的负载均衡方式在rebalance类下

7.3.2 DefaultMQPullConsumer 的负载均衡

废弃类这里不再赘述。

7.4 提高 Producer 的发送速度

消息发送的步骤：客户端发送请求到服务器、服务器处理请求、服务器返回客户端处理结果。

对速度要求高但是可靠性不高的场景可以使用Oneway的方式，也就是只发送请求不等待应答。

另一种方法是增加多个生产者。

7.5 系统性能调优的一般流程

7.5.1 使用top命令查看cpu和内存的利用率

7.5.2 使用sar命令查看网卡使用情况

7.6 本章小结

番外

为什么DefaultMQPullConsumer被废弃？

官方推荐 DefaultLitePullConsumer 替代 DefaultMQPullConsumer