消息中间件（MQ）

消费者通过同一个消费队列收到的消息是有顺序的，
不同消息队列收到的消息则可能是无顺序的。

消费者收到的所有消息均是有顺序的

性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景

性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

同步发送失败重投次数，默认为2，因此生产者会最多尝试发送retryTimesWhenSendFailed + 1次。
不会选择上次失败的broker，尝试向其他broker发送，最大程度保证消息不丢。
超过重投次数，抛出异常，由客户端保证消息不丢。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。

消息刷盘（主或备）超时或slave不可用（返回状态非SEND_OK），是否尝试发送到其他broker，
默认false。十分重要消息可以开启。

异步发送失败重试次数，异步重试不会选择其他broker，仅在同一个broker上做重试，不保证消息不丢。

生产者流控，不会尝试消息重投。需要自己实现逻辑

接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活

每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。
然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费

整个Broker的实体，负责处理来自clients端的请求

负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息

提供方便简单的API接口处理消息存储到物理硬盘和查询功能。

高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。

根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。

消息主体以及元数据的存储主体，存储Producer端写入的消息主体内容;
消息内容不是定长的

单个文件大小默认1G ，文件名长度为20位，左边补零，剩余为起始偏移量

消息主要是顺序写入日志文件，当文件满了，写入下一个文件

作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值;
consumequeue文件可以看成是基于topic的commitlog索引文件

consumequeue文件夹的组织方式如下：topic/queue/file三层结构，具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}

文件采取定长设计，每一个条目共20个字节，分别为8字节的commitlog物理偏移量、4字节的消息长度、8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约5.72M

提供了一种可以通过key或时间区间来查询消息的方法

存储位置：$HOME \store\index${fileName}

文件名fileName:以创建时的时间戳命名的

单个文件大小约为400M，可以保存 2000W个索引

底层存储设计为在文件系统中实现HashMap结构，故底层实现为hash索引。

对文件进行顺序读写的速度几乎接近于内存的读写速度；
主要原因OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache(预读取)

优化方向：选择合适的系统IO调度算法

利用了NIO中的FileChannel模型将磁盘上的物理文件直接映射到用户态的内存地址中（减少内存拷贝）

在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应

能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。
消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。

Consumer端在订阅消息时除了指定Topic还可以指定TAG，如果一个消息有多个TAG，可以用||分隔。
其中，Consumer端会将这个订阅请求构建成一个 SubscriptionData，发送一个Pull消息的请求给Broker端。
Broker端从RocketMQ的文件存储层—Store读取数据之前，会用这些数据先构建一个MessageFilter，然后传给Store。
Store从 ConsumeQueue读取到一条记录后，会用它记录的消息tag hash值去做过滤，由于在服务端只是根据hashcode进行判断，无法精确对tag原始字符串进行过滤，故在消息消费端拉取到消息后，还需要对消息的原始tag字符串进行比对，如果不同，则丢弃该消息，不进行消息消费。

和Tag过滤方式一样，只是在Store层的具体过滤过程不太一样，真正的 SQL expression 的构建和执行由rocketmq-filter模块负责的。
每次过滤都去执行SQL表达式会影响效率，所以RocketMQ使用了BloomFilter避免了每次都去执行。SQL92的表达式上下文为消息的属性。

有一个sendLatencyFaultEnable开关变量，
如果开启，在随机递增取模的基础上，再过滤掉not available的Broker代理。
所谓的"latencyFaultTolerance"，是指对之前失败的，按一定的时间做退避。

(1) 发送消息（half消息）。
(2) 服务端响应消息写入结果。
(3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。
(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）

(1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
(2) Producer收到回查消息，检查回查消息对应的本地事务的状态
(3) 根据本地事务状态，重新Commit或者Rollback

默认回查15次，如果15次回查还是无法得知事务状态，rocketmq默认回滚该消息

所有Broker节点再zookeeper上注册一个临时节点，
唯一成功的哪个成为leader,称为Broker Controller, 其他的称为Broker follower

提供两种策略删除旧数据

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

Leader Election算法
（有两种方式实现基于ZooKeeper的分布式锁）

leader负责跟踪所有follower的状态

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower

当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower

从Leader中复制数据，不与producer/consumer交互

在broker上的分配策略

消息同步传输策略

replication是否“活着”包含两个条件

表示需要所有partition成功，才返回成功

表示发送即代表发送成功，不等broker返回确认信息

producer写道partition leader成功后，broker就返回

表示有2个partition成功，就返回成功

zookeeper中保存该Consumer在该Partition中读取消息的offset

保证生产者-mqServer-消费者一对一关系

并行度低

只要消费端出现问题，就会导致整个处理流程阻塞

利用一张日志表来记录已经处理成功的消息的 ID，如果新到的消息 ID 已经在日志表中，那么就不再处理这条消息。

• 一定时间内没有Get操作发生
• 没有Consumer连接在队列上
• 特别的：就算一直有消息进入队列，也不算队列在被使用。
• 通过声明队列时，设定x-expires参数即可，单位毫秒。

它只会让RabbitMQ向你通知失败，而不会通知成功。
如果消息正确路由到队列，则发布者不会受到任何通知。

发送消息时设置mandatory标志 : mandatory=true

缺点: 无法确保发布消息一定是成功的，因为通知失败的消息可能会丢失。

发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()），
缺点：吞吐量下降； 一般选择使用confirm模式替代

所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），
一旦消息被投递到所有匹配的队列之后；rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

三种实现方式

双活的一种模式

rabbitMQ 部署架构采用双中心模式(多中心)，那么在两套(或多套)数据中心各部署一套 rabbitMQ 集群，
各中心的rabbitMQ 服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。

federation 插件