消息队列-消息队列有什么优点和缺点？

面试连环炮

• 你用过消息队列么？
• 说说你们项目里是怎么用消息队列的？
  • 我们有一个订单系统，订单系统会每次下一个新订单的时候，就会发送一条消息到ActiveMQ里面去，后台有一个库存系统，负责获取消息，然后更新库存。
• 为什么使用消息队列？
  • 你的订单系统不发送消息到MQ，而是直接调用库存系统的一个接口，然后直接调用成功了，库存也更新了，那就不需要使用消息队列了呀
  • 使用消息队列的主要作用是：异步、解耦、削峰
• 消息队列都有什么优缺点？
• Kafka、activeMQ、RibbitMQ、RocketMQ都有什么优缺点？
• 如何保证消息队列的高可用？
• 如何保证消息不被重复消费？如何保证消息消费时的幂等性？
• 如何保证消息的可靠性传输，要是消息丢失了怎么办？
• 如何保证消息的顺序性？
• 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
• 如果让你写一个消息队列，该如何进行架构设计，说一下你的思路？

 

优点上面已经说了：解耦、异步、削峰，缺点呢？显而易见的

• 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统接口就好了，人家ABCD四个系统好好的，没啥问题，这个时候却加入了MQ进来，万一MQ挂了怎么办？MQ挂了整套系统也会崩溃了。
• 系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
• 一致性问题：A系统处理完了直接返回成功了，人都以为你的请求成功了，但是问题是，要在BCD三个系统中，BD两个系统写库成功了，结果C系统写库失败了，这样就会存在数据不一致的问题。
• 所以说消息队列实际上是一种复杂的架构，你引入它有好多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最后发现系统复杂性提升了一个数量级，也许是复杂10倍，但是关键时刻，用还是得用。