导读 abbitMQ 是一个在 AMQP（Advanced Message Queuing Protocol ）基础上实现的，可复用的企业消息系统。它可以用于大型软件系统各个模块之间的高效通信，支持高并发，支持可扩展。
优势
异步

比如说，我之前在公司做的一个系统叫 “跟踪提醒平台”，是一个公共的平台，可以给客户或者业务人员推送消息，如电话语音、短信、邮件、APP 内消息和微信消息等。其他系统对接我们，需要在我们系统这边配置提醒规则和对象。然后他们会推送 MQ 消息，我们去消费处理。

为什么使用 MQ 呢？如果不用 MQ 的话，只能通过调用接口的方式。我们考虑到调用接口会有 2 个缺点:

  • 一是会阻塞，像我们系统提醒业务处理过程通常要 1-2 秒，如果一下来了太多请求，可能是处理不过来的，后面的请求只能一直等甚至超时；而 MQ 支持消息堆积，很好解决了这个问题。
  • 二是调用失败无法自动重试，MQ 可以很容易实现失败重试。
    • 削峰

    削峰跟前面说的异步很像，比如有些系统通常是晚上 2 点跑规则然后去给我们推送消息，让我们帮他们提醒客户或业务人员。

    突然大量请求过来，短时间内我们可以处理不过来的，所以需要消息堆积。MQ 可以帮我们存储消息，而且对接方对也不要求实时性， 所以我们可以慢慢消费处理，很舒服。

    解耦

    比如客户报案后，我们处理报案信息生成案件号等逻辑执行完后，需要把报案信息推送给 A、 B、 C 这 3 个其他的系统。

    如果用调用接口方式，调用三次接口，也不是不可以实现。但是如果后期 B 系统说你不需要推送给我了。我这边是不是需要删除掉推送给 B 的代码，这就是代码耦合了。

    通过 MQ 可以解决这个问题，我往指定的 TOPIC:TAG 里推送消息，然后 A、 B、 C 三个项目都去订阅 TOPIC:TAG，推送方式可以广播模式。如果 B 系统不需要报案信息，可以去取消订阅这个 TOPIC:TAG，或者他们自己修改业务代码，而我这边是不需要修改的，美滋滋。

    缺点
    系统可用性降低

    我们在处理下单系统中返回短信给用户用了 MQ、在订单系统和库存系统之间用了 MQ、在处理促销活动也用到了 MQ，如果 MQ 出现问题，就会出现连锁反应，系统崩溃。（系统引入的外部依赖越多，受到的影响也就越多。本来A系统只需要去调用 B、C、D 三个系统的接口就可以了，加入了 MQ 之后，如果 MQ 挂掉了，我们的系统也会受到影响。)

    系统复杂度提高

    我们添加了 MQ 到系统之后，如何保证消息传递的顺序性？消息传递的过程中是否有重复？是否有丢失？这个时候我们就需要在系统中去思考解决这些问题，相应的就将系统的复杂度提高了。

    一致性问题

    系统 A 给 BCD 发送消息，只有都成功才返回成功，若是只有 C 成功，B 和 D 都没有成功，但是返回结果是成功了，这就出现了一个一致性问题需要解决。

    原文来自：https://haicoder.net/rabbitmq/rabbitmq-advs-disadvs.html

    本文地址：https://www.linuxprobe.com/rabbitmq-advantages-disadvantages.html编辑：薛鹏旭，审核员：逄增宝

    Linux命令大全：https://www.linuxcool.com/

    Linux系统大全：https://www.linuxdown.com/

    红帽认证RHCE考试心得：https://www.rhce.net/