rocketMQ总结

Posted 2020-12-08 anhaogoon

一、RocketMQ组成

1、NameServer 协调者，类似zookeeper，基于内存完成
2、Broker 实例
3、Topic
4、tag topic里的标签
5、Message Queue topic里的队列
6、offset 标记消息在Message Queue里的位置,标记消费读取时自增长

 

二、消息模式

Clustering 

同一个 ConsumerGroup (GroupName相同)里的Consumer 只消费所订阅消息一部分内容。

Broadcasting
同一个 ConsumerGroup (GroupName相同)里的Consumer 只消费所订阅消息是全部内容。

实现区别:

Clustering模式即同组ConsumerGroup下的每个Consumer消费位置不同,由Broker端存储和控制Offset

Broadcasting模式下每个Consumer使用LocalFileOffsetStore本地存储Offset

 

三、生产消费

DefaultMQProducer

返回状态:FLUSH_DISK_TIMEOUT表示同步刷盘策略下规定时间内未完成刷盘 FLUSH_SLAVE_TIMEOUT表示主备模式下SYNC_MASTER方式规定时间内未完成主从同步 SLAVE_NOT_AVAILABLE表示主备模式下SYNC_MASTER方式没有找到Slave SEND_OK表示发送成功

延时消息:setDelayTimeLevel设置延迟时间

自定义消息发送规则:使用MessageQueueSelector类在覆写select方法中返回选中的MessageQueue

事务支持:两阶段提交协议 发送方向RocketMQ发送待确认消息-持久化后返回发送成功-将本地事务逻辑与发送确认消息包装在同一事务中并执行事务-RocketMQ收到确认消息后订阅方对消息可见并消费 发送方事务阶段异常则待确认消息作废 发送方提供给RocketMQ回查接口用于查询事务结果

同步发送: 需要等MQ返回相应

异步发送：无需MQ返回相应，需要实现SendCallback

 

消费者： (分push、pull模式)
interface MQPushConsumer:
DefaultMQPushConsumer：由系统控制读取操作，收到消息后自动调用传人的处理方法来处理

 

interface MQPullConsumer:
实现类 DefaultMQPullConsumer：读取操作中的大部分功能由使用者自主控制,使用者记录offset

Push与Pull比较:Push(推)由服务端主动推送消息至客户端,实际通过Pull保持连接并等待服务端获得从生产者发送来的消息,在等待期间若获得消息则通过连接发送至消费者,在等待超过限定时间后返回空结果至消费者 Pull(拉)由消费者发起连接到服务端获得消息,需预判消息发送频率,连接频率过长过短均有问题

四、协调者

 

1.功能

概览:各角色机器均定期发送数据至协调者 协调者根据消息请求码做相应处理，更新存储的对应信息 协调者彼此之间互相独立 无状态 

2.结构

HashMap<String,List<QueueData>> topicQueueTable key为Topic名称 List长度代表Master Broker个数 QueueData存储Broker名称、读写queue数量、同步标识

HashMap<String,BrokerData> BrokerAddrTable key为Broker名称 BrokerData包含所属的Cluster名称、Master Broker地址和Slave Broker地址

HashMap<String,Set<String>> ClusterAddrTable key为Cluster名称 value为BrokerName集合

HashMap<String,BrokerLiveInfo> BrokerLiveTable key为BrokerAddr BrokerLiveInfo包括这台Broker机器的上次更新时间 

HashMap<String,List<String>> filterServerTable key为BrokerAddr value为与这个Broker关联的多个FilterServer地址

3.Remoting模块

概览: 通信通过Remoting模块统一自定义消息格式RemotingCommand完成 

 

 

4.协议格式

 

消息队列的核心机制

---

1.消息存储结构

物理存储文件CommitLog 消息的逻辑队列ConsumerQueue类似数据库的索引文件 每个Topic下的每个MessageQueue有一个对应的ConsumeQueue文件

2.高可用机制

在创建Topic时将Topic的多个MessageQueue创建在多个Broker组中(相同Broker名称 不同BrokerId的机器组成一个Broker组)，当一个Broker组内的Master不可用时可向其他Broker组的Master发送消息

3.同步刷盘和异步刷盘

异步刷盘:写入到内存即返回写成功 当内存消息量累计到一定程度后，统一写入磁盘

同步刷盘:写入内存后通知刷盘线程刷盘，刷盘完成后刷盘线程唤醒等待的线程返回写成功的状态

4.同步复制和异步复制

同步复制:Master和Slave均写成功后返回成功状态

异步复制:Master写成功即返回成功状态

5.磁盘读取机制
顺序写，随机读，零拷贝

6.写入及复制机制
Master读和写，Slave只读，生产者写入Master，Master复制到Slave

顺序机制
1、完全顺序
需要把Topic的读写队列设置为1，Producer 和 Consumer 并发设置为1

2、部分顺序
1)生产者需要把消息发送到同一个Message Queue;
2)消费组需要不并发读一个Message Queue;

 

 

为什么不用Zookeeper
RocketMQ不需要Master选举等复杂功能

 

 

rocketMQ和kafka不同
1、偏向事务机制；
2、不支持Master选举，即不能Slave转Master