1.优势，使用场景
（1）异步处理
（2）解耦
（3）抗压
2.使用代价
（1）维护成本，挂掉怎么办，消息丢失怎么办
（2）数据一致性
3.选择消息队列
如何分析？
1.分析是否符合业务的基本要求，市面常见基本标准是否满足,接下来是性能，稳定性，安全性，最后一点是否有业界参考案例。
2.缺点，不满足什么要求，相互对比的劣势，要求成本
RabbitMq:
优点：简单，易用，具备点对点，订阅模式，消息确认等常见消息队列特点，快速上手
缺点：erlang编写，出现问题很难定位，二次开源麻烦；消息堆积能力差；与同款产品相比性能相对低点，每秒几万
参考场景：小项目，同步改异步，用来解决一部分问题，开箱即用
RocketMq:
优点：具备常见消息队列的功能，包括事务消息；性能高，毫秒级消费，每秒十几万消费能力；稳定，有很多项目参考案例。
缺点：与很多框架生态集成不太容易
参考场景：实时性要求高的金融业务项目
kafka:
优点：具备基本功能，包括事务消息；性能高，表现在处理量大不是速度快；稳定，有很多项目参考案例；大数据领域生态发展好
缺点：消息延时处理稍差，
参考场景：数据埋点，日志记录，大数据相关处理
4.消息模型
RabbitMq：
主要思路：
生产者通过exchange 投放到队列，然后消费者从队列拉取消息进行消费
发布-订阅模式怎么实现？ 通过exchange 投放到多个队列，多个消费者消费
rabbitmq 各大模式也主要是在exchange上动手脚
RocketMq:
主要思路：
生产者生产消息根据nameserver 获取broker信息，再投递到具体的broker下的topic 的队列里面，消费者是一个组也可以是一台机器，消费一个或多个topic下队列的消息
发布订阅核心概念和rabbitMq 不一样的点在于：
rocketMq 是多个消费者组订阅同一个topic，只有一个队列有值，每个组各自消费
rabbitMq 是多个队列里面都有值，每个队列的消费者消费就是发布订阅
5.使用
基于不同的设计思路，使用方式也不一样，各自功能也不一样
RabbitMq相关模式:
1基于队列
生产者与消费者一对一；
生产者与消费者一对多(work),只有一个能消费，不是每个都消费；
2.基于交换器exchange，发布订阅
(1)direct交换器，一对一key关联一致的队列
(2)fanout 交换器绑定的所有队列
(3)topic key通配符模糊匹配
可以看出RabbitMq的设计以及思路还是相对简单的
RocketMq 相关模式