消息中间件：
1.你们公司生产环境用的是什么消息中间件？
https://mp.weixin.qq.com/s?__biz=MzU0OTk3ODQ3Ng==&mid=2247484149&idx=1&sn=98186297335e13ec7222b3fd43cfae5a&chksm=fba6eaf6ccd163e0c2c3086daa725de224a97814d31e7b3f62dd3ec763b4abbb0689cc7565b0&scene=21#wechat_redirect
消息中间件的选型：
ActiveMQ
优点：老牌的消息中间件，国内很多公司过去运用的还是非常广泛的，功能很强大。
缺点：没法确认ActiveMQ可以支撑互联网公司的高并发、高负载以及高吞吐的复杂场景，在国内互联网公司落地较少。
而且使用较多的是一些传统企业，用ActiveMQ做异步调用和系统解耦。
RabbitMQ：
优点：可以支撑高并发、高吞吐、性能很高，同时有非常完善便捷的后台管理界面可以使用。
他还支持集群化、高可用部署架构、消息高可靠支持，功能较为完善。
开源社区很活跃，较高频率的迭代版本，来修复发现的bug以及进行各种优化
缺点：基于erlang语言开发的，所以导致较为难以分析里面的源码，也较难进行深层次的源码定制和改造
RocketMQ：
优点：阿里开源的，经过阿里的生产环境的超高并发、高吞吐的考验，性能卓越，同时还支持分布式事务等特殊场景
RocketMQ是基于Java语言开发的，适合深入阅读源码，有需要可以站在源码层面解决线上生产问题，包括源码的二次开发和改造。
Kafka：
优点：Kafka的优势在于专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计。
缺点：Kafka提供的消息中间件的功能明显较少一些，相对上述几款MQ中间件要少很多。
因此Kafka在大数据领域中配合实时计算技术（比如Spark Streaming、Storm、Flink）使用的较多。但是在传统的MQ中间件使用场景中较少采用。
2.为什么在你们系统架构中要引入消息中间件？
1）系统解耦：A系统把消息放进中间件，一大堆子系统自己去拿
2）异步调用：（可以减少调用的耗时）：点外卖--》下单成功后，寻找骑手做成异步的
3）流量削峰：瞬时高峰的时候可以把消息放进中间件，等消费者慢慢处理
3.引入消息中间件之后会有什么缺点？
1）系统可用性降低
原因：一旦你的MQ挂了，就导致你的系统的核心业务流程中断了
思考： 你就必须去考虑这个MQ是如何部署的，如何保证高可用性。
还要考虑如果MQ一旦挂了，你的系统有没有备用兜底的技术方案
2）系统稳定性降低
原因：系统C发了一个消息到MQ，结果那个消息因为网络故障等问题，就丢失了，这就导致系统D没有收到那条消息。
系统C给MQ发送消息，不小心一抽风重复发了一条一模一样的，导致消息重复了，这个时候该怎么办？ 发多了，产生脏数据
系统D挂了之后，要处理积压消息
思考：
消息高可靠传递（0丢失）：
消息幂等性传递（绝对不重复）：
百万消息积压的线上故障处理：
3）分布式一致性问题
原因： 系统C现在处理自己本地数据库成功了，然后发送了一个消息给MQ，系统D也确实是消费到了。
但是结果不幸的是，系统D操作自己本地数据库失败了，那这个时候咋办？
系统C成功了，系统D失败了，会导致系统整体数据不一致了啊。
思考：最终一致性分布式事务的99.99%高可用保障生产实践