1. RocketMQ的理念：

• rocketMQ同大多数的消息中间件类似，都是基于主体消息的发布和订阅模式，其最核心的就是消息的发送，消息的存储，消息的接收，路由信息四部分组成，他的设计有一下几个特点：

  • nameSrv的出现摒弃了以前需要依赖zookeeper作为注册中心，使用namesrv来保存元数据，设计简单，namesrv之间不相互通信，降低网络消耗，不追求像zookeeper一样的强一致性，而是保证了其最终一致性。
  • namesrv的高性能io存储，RocketMQ追求的是高性能消息发送，其内部存储采用了文件组的形式，组内的每个文件有固定的大小，方便引用内存映射机制，所有主题的消息都是按顺序写入，极大的提高了写的性能，同时为了兼顾消息的消费和消息的查找引入了消息消费的队列文件和索引文件
  • 容忍设计上的缺陷，让用户去解决一些问题，给予用户最大限度的自由发挥，比如消息重复消费的问题。

2. RocketMQ作为一款高性能消息中间件需要解决的问题有以下几个方面

• 架构模式

  • 架构模式与普通的消息中间件类似都是基于发布订阅的模式，核心是消息的发送，消息的存储，消息的接收，消息路由

• 顺序消息

  • 严格保证消息的顺序性，消费者消费的消息严格按照到达消息服务器存储的消息顺序。

• 消息过滤

  • 消费者在消费的时候过滤，消费者在订阅某一个主体的消息的时候可以按照一定规则注册自己感兴趣的消息，一种是broker端过滤，只推送给消费者感兴趣的消息，一种是在消费者端过滤，这种会有很多无用消息需要过滤。

• 消息存储

  • RocketMQ 追求消息存储的高性能，引人内存映射机制，所
    有主题的消息顺序存储在同一个文件中 同时为了避免消息无限在消息存储服务器中累积，引入了消息文件过期机制与文件存储报警机制

• 消息到达低延迟

  • RocketMQ 在消息不发生消息堆积时，以长轮询模式实现准实时的消息推送模式。

• 定时消息

  • 消息发送之后不要求消费者立即消费需要在某个特定的时间点或者任意精度的时间被消费者消费，如果要支持任意精度，势必要在消息的服务端就消息进行排序，性能消耗很大，所以rocketMQ不支持任意精度的定时，而是支持特定的延时级别

• 消息的高可用

  • 1，Broker正常关机
  • 2，Broker异常关机
  • 3，OS Crash
  • 4，机器断电，但 能立即恢复供电情况
  • 5，机器无法开机
  • 6，磁盘设备损坏
  • 情况 1~4 RocketMQ 在同步刷盘机制下可以确保不丢失消息，在异步刷盘的时候会丢失少量消息，5-6属于单点故障，一旦发生，消息全部丢失，如果开启可异步复制，会丢失少量的数据，但是够来rocketMq开启了双鞋机制，满足可用性极高的场景

• 保证每个消息被消费一次

  • 保证每个消息至少被消费一次，但由于ack消息丢失等原因造成的重复消费需要用户自己去处理

• 回溯消息

  • 消息消费之后还可以再次消费

• 消息的堆积能力

  • 应对洪峰数据，提高系统的可用性，必然要求我们有一定的消息堆积能力，RocketMQ采用了磁盘文件（内存映射机制），并且在物理布局上为多个大小相等的文件组成一个逻辑组，可无限循环使用，还提供了过期机制，默认是保留3天的消息。

• 消息的重试机制

  • 消息在消费的时候，如果消费失败，消息中间件支持重新发送消费

3. 整体架构

• rocketMQ的流程，首先启动namesrv，然后broke服务器在启动的时候会向所有的namesrv服务器注册，消息生产者在发送消息之前先从namesrv中根据topic找到对应的namesrv地址列表，然后根据负载均衡算法从列表中选取一个namesrv发送消息，namesrv和broker之间保持长连接，每隔30sbroker会向namesrv发送心跳检测信息，namesrv定时任务会每120秒扫描一次列表如果有超过120秒没有收到消息那么就认为其故障然后移除列表了，，但是这个路由消息不会立马同步给其他namesrv，也不会立马通知生产者需要生产者自己拉取，因为namesrv之间是不同步信息的，会造成短暂的不一致的情况，这是为了降低namesrv的设计复杂度，我们可以从消息的发送端解决这个问题保证消息的高可用，消息到达broker之后，broker会将其存储，并且推送给订阅这个消息的消费者。

下面会根据章节介绍rocketMQ的重要组件namesrv，生产者，存储，消费者，过滤，主从同步，事务