为什么要使用消息中间件？
- 解耦：消息中间件可以使不同的应用程序通过解耦的方式进行通信，减少系统间的依赖关系
- 提供异步通信：消息中间件可以实现异步消息传递，提高系统的响应性能。
- 流量削峰：消息中间件可以起到流量削峰的作用，将短时间内的爆发式流量存储在消息队列中，使系统能够平稳地处理请求
- 解决分布式系统数据传输的需求：如分布式场景下的websocket支持。
消息中间件的缺点
- 降低系统可用性: 如果消息中间件出现故障或挂掉，那么使用它的应用程序也会受到影响，导致系统整体可用性降低。
- 降低系统稳定性: 网络故障可能会导致消息丢失（主要发生在RabbitMQ），消息重复，甚至出现脏数据，影响系统的稳定性。
- 引入分布式一致性问题: 在分布式系统中，各个节点之间通信可能会出现延迟，导致数据在各个节点之间不一致。
- 提高系统复杂性: 引入消息中间件后，系统需要考虑的问题会增多，例如消息的顺序性、消息的可靠性、消息的持久性等，这会增加系统的复杂性。
常用的MQ对别
对别总结：
- ActiveMQ：非常成熟，功能强大，在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息而且现在社区以及国内应用都越来越少，官方社区现维护越来越少，几个月才发布一个版本而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用。
- RabbitMq：erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用社区相对比较活跃，几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。
- RocketMQ:接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控,社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的,有些系统要迁移需要修改大量代码,还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的.
- Kafka:kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。
