概述
消息队列存储有利于解耦，削峰，异步，日志处理。
常存数据：日志信息，Metrics数据，用户行为
Kafka
如何使用：
创建集群 -> 新增Topic -> 编写生产者逻辑 -> 编写消费者逻辑
基本概念
Producer、Cluster、Consumer、Topic（逻辑队列）、Partition
)
partition
其中partition可以并行处理，其中又唯一的Offset，可以用来保证消息在partition中的顺序性。
每个封片（partition）有多个replica（副本），Leader Replica可以从LSR中（In-Sync Replicas）选出，Follwer尽力拉取Leader的数据，如果和Leader差距过大就退出LSR。
LSR可以保证Leader宕机仍可用。
broker
表示集群中的节点。
通过Batch可以让消息批量从Producer发向Broker。
但是如果网络带宽不够用怎么办？
通过压缩机制来减少消息大小，如Snappy，Gzip压缩算法。
Broker消息文件结构
Broker采用顺序写（末尾添加）的方法，提高写入效率
Consumer
Consumer消费哪个Partition的分配方式：
手动分配：不能避免数据熔断等问题
自动分配：rebalance，可以感知到宕机和故障，从新进行分配
Kafka的问题
存在重启过慢，负载不均衡，没有自己的缓存等问题
BMQ
简介
兼容Kafka,存算分离
RocketMQ
基本概念：
与kafka的不同：
- RocketMQ新增了同步刷盘机制，保证了可靠性；一个RocketMQ实例只有一个partition, 在replication时性能更好。
- RocketMQ写入性能上不如kafka, 主要因为kafka主要应用于日志场景，而RocketMQ应用于业务场景，为了保证消息必达牺牲了性能，且基于线上真实场景没有在RocketMQ层做消息合并，推荐在业务层自己做.
- RocketMQ支持的队列数远高于kafka支持的partition数，这样RocketMQ可以支持更多的consumer集群
- kafka与RocketMQ都支持长轮询，消息投递的延迟在几毫秒内。
- RocketMQ支持消费失败重试功能，主要用于第一次调用不成功，后面可调用成功的场景。而kafka不支持消费失败重试
- kafka不保证消息有序，RocketMQ可保证严格的消息顺序，即使单台Broker宕机，仅会造成消息发送失败，但不会消息乱序。
- RocketMQ支持按消息标识或消息内容查询消息，用于排查消息丢失问题；kafka不支持消息查询。
- 支持分布式事务消息
- 支持定时级别，定时级别用户可定制
