1、削峰填谷: 高峰流量时，进行缓冲。降低QPS，TPS压力。
2、系统解耦： 系统交互不再进行强依赖，上下游各自处理系统业务。避免系统之间因一个调用导致整个系统链路垮掉。
3、提升性能： 一个消息对应多个系统业务处理，可以多次订阅，各个下游子系统可以各自处理业务相互不影响。
比对的原则：
1、使用场景 如Kafka就适用日志系统，使用大量的数据处理，为了提高实时性，丢掉了一些可靠性。 稳定性上，RocketMQ和RabiteMQ就可以满足，都有技术去保障。
2、可顺序消费
3、性能
4、持久化 可恢复 综述：
基本上在kafka和RocketMQ选择， 如果类似监控，日志等会用Kafka,其他业务场景选择RocketMQ。
Kafka和RocketMQ在消息堆积时的性能都能够有效保障，RabiteMQ不太行。
顺序消息作用很大，只有Kafka和RocketMQ支持。
RocketMQ的唯一缺点是社区少，只支持Java对接。但是有点也很明显，支持事务消息，Java开发，API灵活。
NameServer: 注册协调中心 10s间隔扫描消息，2分钟内没有回复就断开连接
Broker：消息存储区
BrokerId为0表示Master，非0表示Slave；
30s间隔与NameServer保持心跳
Producer：生产者
Consumer：消费者
四、怎么保证消息不丢失
MQ消息都是经历3个阶段：生产阶段，存储阶段，消费阶段
生产：让MQ服务器返回确认消息即可，如果没有返回则进行重试 1、RabbitMQ 是有ACK确认机制 2、RocketMQ有状态确认，SendStatus.SEND_OK SendStatus.FLUSH_DISK_TIMEOUT
存储阶段： 1、RocketMQ：异步刷盘改成同步刷盘，文件持久化后才返回确认消息 2、状态标记：如果存储失败或者其他问题，状态回调，check是否保存好
消费阶段： 1、消费成功或失败，都需要返回确认机制，RocketMQ是有状态，Kafka是通过返回offset
2、如果消费成功但是中间网络问题导致失败，会被重新消费，需要幂等设计
五、幂等设计 核心：保障唯一性消息只消费一次
1、记录消息的唯一性 2、数据库做约束 3、NOSQL做记录存储
六：Kafka高性能原理
1、PageCache
2、零拷贝 从内存直接拷贝至Socket缓存 3、序列化 4、批量操作
