目录
- [1 从场景入手](#1 从场景入手)
- [2 RocketMQ是什么？](#2 RocketMQ是什么？)
- [3 RocketMQ及和Kafka的区别](#3 RocketMQ及和Kafka的区别)
-
- [3.1 在架构上做了减法](#3.1 在架构上做了减法)
-
- [3.1.1 简化协调节点](#3.1.1 简化协调节点)
- [3.1.2 简化分区](#3.1.2 简化分区)
- [3.1.3 底层存储](#3.1.3 底层存储)
-
- [3.1.3.1 Kafka底层存储](#3.1.3.1 Kafka底层存储)
- [3.1.3.1 RocketMQ底层存储](#3.1.3.1 RocketMQ底层存储)
- [3.1.4 简化备份模型](#3.1.4 简化备份模型)
-
- [3.1.4.1 Kafka备份模型](#3.1.4.1 Kafka备份模型)
- [3.1.4.2 RocketMQ备份模型](#3.1.4.2 RocketMQ备份模型)
- [3.1.5 RocketMq架构](#3.1.5 RocketMq架构)
- [3.2 在功能上做加法](#3.2 在功能上做加法)
-
- [3.2.1 消息过滤](#3.2.1 消息过滤)
- [3.2.2 支持事务](#3.2.2 支持事务)
- [3.2.3 加入延时队列](#3.2.3 加入延时队列)
- [3.2.4 加入死信队列](#3.2.4 加入死信队列)
- [3.2.5 消息回溯](#3.2.5 消息回溯)
1 从场景入手
假设A服务过来一个请求，但是不想让B服务马上处理，需要等待一段时间才做处理，比如定时外卖的场景。
那如何处理上述问题，那就可以在服务之间加一个中间层。
2 RocketMQ是什么？
是国产自研的消息队列，是Apache的顶级项目
和Kafka一样都是消息队列
3 RocketMQ及和Kafka的区别
其实就是RocketMQ在Kafka的架构上做了一些架构上的调整
总结：在架构上做了减法，在功能上做了加法
3.1 在架构上做了减法
3.1.1 简化协调节点
zookeeper在Kafka架构中会和broker通信，维护Kafka信息，一个新的broker加入后，其他broker会立马感知它的加入。
像这种在分布式结构下让多个实例同时获取同一份信息的服务就是所谓的分布式协调服务
zookeeper不仅可用于服务注册和发现 ，还可以用于分布式锁管理 ，配置管理 等场景。
Kafka只用到部分场景，有点杀鸡用牛刀了！
下面是rocketMq的架构：
所以RocketMQ把zookeeper去掉，使用nameServer，用更轻量的方式管理消息队列的集群信息。
后来Kafka也发现了zookeeper过重的问题，从2.8.0版本移除zookeeper，通过broker之间加入一致性算法Raft实现同样的效果。
下面是Kafka的架构：
这就是所谓的Kraft或Quorum模式
3.1.2 简化分区
RocketMQ也会拆分多个分区，不叫partition，叫queue
kafka的partition中会存入完整消息，但是RocketMQ的queue中只存入一些简要信息，比如消息偏移offset，而消息的完整信息放到commitLog里，通过offset可以定位到commitLog的某条消息。
在Kafka中消费者只需要直接从partition中读取消息，然而在RocketMQ中，消费者需要先从queue中读到offset的值，再跑到commitLog上将完整的数据读取出来，也就是读取了两次
看起来Kafka的设计更高效，但是为何RocketMQ要用此设计？
3.1.3 底层存储
3.1.3.1 Kafka底层存储
Kafka下有partition，每个partition是由多个segment组成的，生产者发送数据也就是在往segment中写入数据，就是往磁盘做写入，磁盘的顺序写 入会比随机写 入快很多，性能差距很大，可高达几十倍。
为了提升性能，Kafka对于每个segment的写入也都是顺序写。
但是当topic变多了，Kafka下的partition也会增多，对应的segment文件也会变多，同时写多个topic下的partition就相当于写多个文件，不同的topic下的文件存放在磁盘的不同地方，这样的话即使segment内部是顺序写，但是针对于不同topic下的文件是随机写。
3.1.3.1 RocketMQ底层存储
为了缓解同时写多个文件带来的随机写的问题，RocketMQ将单个broker地下的多个topic数据，全部写到"一个"逻辑文件CommitLog上，这就消除了写多个文件的随机写 问题，将所有写操作变成了顺序写，提升了RocketMQ在多topic场景下的写性能。
3.1.4 简化备份模型
3.1.4.1 Kafka备份模型
底层就是同步segment数据
3.1.4.2 RocketMQ备份模型
RocketMQ直接同步commitLog数据，以broker为单位区分主从
3.1.5 RocketMq架构
3.2 在功能上做加法
3.2.1 消息过滤
Kafka支持通过topic将数据进行分类
场景：
当我们有如上图4、5、6、7一共4条数据，他们有不同类型，如果我们只想要vip6的数据。
kafka需要消费topic为用户数据的所有消息，再将vip6的用户过滤出来。
RocketMQ支持给用户数据打tag ，消费者根据tag 过滤所需要的数据，消费者就可以只消费这部分数据，就剩下了消费者过滤数据的资源消耗。
3.2.2 支持事务
Kafka支持事务，保证发送的一批消息同时成功或者同时失败，
但是我们写业务代码的时候，希望执行一些自定义逻辑和生产者发送消息这两件事要么同时成功要么同时失败，这是RocketMQ支持的事务能力
3.2.3 加入延时队列
当我们希望消息被投递出去之后，消费者不是立马消费而是过一段时间再去消费，也就是所谓的延时消息，这就要用到RocketMQ的延时队列，而Kafka就需要程序员自己实现类似的功能。
3.2.4 加入死信队列
消费消息是有可能失败的，失败后一般可以设置重试，如果多次重试失败，RocketMQ会将消息放在一个专门的队列中，方便我们单独做处理，这种专门存放失败消息的队列就是死信队列，kafka不支持，需要程序员实现。
3.2.5 消息回溯
Kafka支持从某个地方开始消费，即offset，后来也支持时间（0.10.1版本后）
RocketMQ不仅支持调整offset，还支持调整时间