Java进阶面试

消息中间件：

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%高可用保障生产实践

消息中间件在你们生产项目里具体是哪个业务场景下落地的？

这个业务场景有什么技术挑战？

为什么必须要在这个业务场景里用消息中间件技术？

具体使用消息中间件的时候是怎么来用的？