rocketMQ总结

一、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

rocketMQ总结

一、RocketMQ组成

二、消息模式

消息队列的核心机制

相关推荐