RocketMQ

Pop模式消费和消息粒度负载均衡 在RocketMQ 5.0之前，消费有两种方式可以从Broker获取消息，分别为Pull模式和Push模式。 Pull模式：消费需要不断的从阻塞队列中获取数据，如果没

为了向云原生演进，提高资源利用和弹性能力，RocketMQ在5.0进行了架构的调整与升级，先来看新特性之一，增加了Proxy层。 增加Proxy代理层 计算存储分离 计算存储分离是一种分层架构，将计算

CommitLog 生产者向Broker发送的消息，会以顺序写的方式，写入CommitLog文件，CommitLog文件的根目录由配置参数storePathRootDir决定，默认每一个CommitL

RocketMQ在开启Dledger时，使用DLedgerCommitLog，其他情况使用的是CommitLog来管理消息的存储。在Dledger模式下，消息写入时Leader节点还需要将消息转发给F

RocketMQ 4.5版本之前，可以采用主从架构进行集群部署，但是如果master节点挂掉，不能自动在集群中选举出新的Master节点，需要人工介入，在4.5版本之后提供了DLedger模式，使用R

RocketMQ支持集群部署来保证高可用。它基于主从模式，将节点分为Master、Slave两个角色，集群中可以有多个Master节点，一个Master节点可以有多个Slave节点。Master节点负

消费者负载均衡，是指为消费组下的每个消费者分配订阅主题下的消费队列，分配了消费队列消费者就可以知道去消费哪个消费队列上面的消息，这里针对集群模式，因为广播模式，所有的消息队列可以被消费组下的每个消费者

RocketMQ事务的使用场景 单体架构下的事务 在单体系统的开发过程中，假如某个场景下需要对数据库的多张表进行操作，为了保证数据的一致性，一般会使用事务，将所有的操作全部提交或者在出错的时候全部回滚

全局有序 在RocketMQ中，如果使消息全局有序，可以为Topic设置一个消息队列，使用一个生产者单线程发送数据，消费者端也使用单线程进行消费，从而保证消息的全局有序，但是这种方式效率低，一般不使用

消费者从Broker拉取到消息之后，会将消息提交到线程池中进行消费，RocketMQ消息消费是批量进行的，如果一批消息的个数小于预先设置的批量消费大小，直接构建消费请求ConsumeRequest将消

在上一讲中，介绍了消息的存储，生产者向Broker发送消息之后，数据会写入到CommitLog中，这一讲，就来看一下消费者是如何从Broker拉取消息的。 RocketMQ消息的消费以组为单位，有两种

当Broker收到生产者的消息发送请求时，会对请求进行处理，从请求中解析发送的消息数据，接下来以单个消息的接收为例，看一下消息的接收过程。 数据校验 封装消息 首先Broker会创建一个Message

RocketMQ是通过DefaultMQProducer进行消息发送的，它实现了MQProducer接口，MQProducer接口中定义了消息发送的方法，方法主要分为三大类： send同步进行消息发送

NameServer是一个注册中心，提供服务注册和服务发现的功能。NameServer可以集群部署，集群中每个节点都是对等的关系（没有像ZooKeeper那样在集群中选举出一个Master节点），节点