为什么使用mq？

消息总线(Message Queue)，后文称MQ，是一种跨进程的通信机制，用于上下游传递消息。

在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。

使用了MQ之后，消息发送上游只需要依赖MQ，逻辑上和物理上都不用依赖其他服务。

什么时候不使用消息总线

既然MQ是互联网分层架构中的解耦利器，那所有通讯都使用MQ岂不是很好?这是一个严重的误区，调用与被调用的关系，是无法被MQ取代的。

MQ的不足是：

• 系统更复杂，多了一个MQ组件
• 消息传递路径更长，延时会增加
• 消息可靠性和重复性互为矛盾，消息不丢不重难以同时保证
• 上游无法知道下游的执行结果，这一点是很致命的

举个例子：用户登录场景，登录页面调用passport服务，passport服务的执行结果直接影响登录结果，此处的“登录页面”与“passport服务”就必须使用调用关系，而不能使用MQ通信。

无论如何，记住这个结论：调用方实时依赖执行结果的业务场景，请使用调用，而不是MQ。

MQ对应的优点是：

• 高并发
  

在高并发分布式环境下，由于来不及同步处理，请求往往发生堵塞，比如说，大量的insert、update之类的请求同时到达mysql，直接导致无所的行锁和表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。

• 松耦合

MQ提供松耦合的应用架构。松耦合一般是为了减轻经典RPC（Remote Procedure Calls）调用的紧耦合架构而被引入的。该松耦合以异步形式存在，任何一个应用对MQ的调用不依赖于任何其它应用，没有任何依赖或者时序要求。应用依赖于MQ的能力保证消息传递。因此，我们把应用发送消息的形式称之为触发和忘记（fire-and-forget）--应用发送消息到MQ之后并不关心消息如何或者什么时候被传递。同样的消息的接收者也不关心消息从哪里或者如何到来。在不同的环境中这样做的好处是允许客户端使用不同的语言编写甚至使用不同的线路协议。MQ作为中间人存在，允许不同环境的集成和异步交互。

当我们考虑分布式应用设计时，耦合是很重要的。耦合是指两个或多个应用间的相互依赖。考虑耦合的一个简单办法是思考其中某个应用改变所产生的影响，即其它应用所需要作出的改变。是否一个应用的变化会强制其它应用跟着改变？如果答案是肯定的，则这些应用是紧耦合的。如果一个应用的变化无需强制其它应用跟着改变，则这些应用是松耦合的。这说明了紧耦合系统比松耦合系统更难维护。也就是说，松耦合系统更能适应未知的变化。

COM,CORBA,DCE和EJB等使用RPC的技术，它们是紧耦合的。使用RPC，当一个应用调用另一个应用，调用者将被阻塞知道被调用者返回结果。图1.1描述了这个过程。

调用方（Application one）将被阻塞直到被调用方（Application two）返回控制权。很多系统使用RPC并且成功了。但是对于这样一个紧耦合系统确实有很多缺点：最显著的缺点是，即使很小的一个改变都要较高的维护代价;正确的时机也很重要，当请求从应用1发到应用2时，两个系统都必须正常工作，同样的，响应从应用2发送到应用1时，两个系统也必须正常工作。这样的时序要求有点麻烦，使得系统稳定性降低。现在我们把这个紧耦合系统和图1.2的系统进行比较。

在图1.2中，应用1发送消息到MOM只是一个单方行为。可能一段时间后，应用2从MOM接收消息，这也是一个单方行为。任何一方都不需要知道另一方的存在，它们之间也没有任何时序要求。所以在分布式系统设计时，松耦合系统比紧耦合系统有巨大的优势。如图所示，这就是MQ存在的地方。

考虑现在其中的一个应用必须搬到一个新的地方。这可能在新硬件引入或应用需要移动时发生。如果是一个紧耦合系统，这样的迁移会很困难，因为系统的其它部分都必须停止工作等待迁移完成。如果是松耦合系统，系统的各个部分能够自由迁移而不影响其它部分。考虑这样一个场景，应用A和B各有很多个实例，其中各个实例分布在不同的机器上。MQ安装在另外的机器上。在这种情况下，任何一个应用实例都可以自由移动而不影响其它应用。事实上，多个MQ实例也可以通过network of brokers配置联合使用。这就允许MQ实例自由迁移而不影响应用A或应用B。采用这种架构，系统的任何一部分在任何时间都可以停机进行维护而不影响整个系统。

请大家多多关注我的头条号，谢谢大家！

==================================================

MQ是用来通信的，利用消息队列暂存数据报文，跟数据库有本质区别 。
没觉得使用MQ有什么方便的，IBM号称其功能强大，协议无关，其实就是一个通信中间件，类似于CICS、BEA TUXEDO、TongLINK等等。
中间件其最终功能就是通信转发，只不过内部实现得好不好的问题。

不用中间件而直接采用socket、http等方式通信也是可以的。

1.高并发
在高并发分布式环境下，由于来不及同步处理，请求往往发生堵塞，比如说，大量的insert、update之类的请求同时到达mysql，直接导致无所的行锁和表锁，甚至最后请求会堆积过多，从而触发too many connections错误。

通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。

2.松耦合

MQ提供松耦合的应用架构。松耦合一般是为了减轻经典RPC（Remote Procedure Calls）调用的紧耦合架构而被引入的。该松耦合以异步形式存在，任何一个应用对MQ的调用不依赖于任何其它应用，没有任何依赖或者时序要求。应用依赖于MQ的能力保证消息传递。因此，我们把应用发送消息的形式称之为触发和忘记（fire-and-forget）--应用发送消息到MQ之后并不关心消息如何或者什么时候被传递。同样的消息的接收者也不关心消息从哪里或者如何到来。在不同的环境中这样做的好处是允许客户端使用不同的语言编写甚至使用不同的线路协议。MQ作为中间人存在，允许不同环境的集成和异步交互。

调用方（Application one）将被阻塞直到被调用方（Application two）返回控制权。很多系统使用RPC并且成功了。但是对于这样一个紧耦合系统确实有很多缺点：最显著的缺点是，即使很小的一个改变都要较高的维护代价;正确的时机也很重要，当请求从应用1发到应用2时，两个系统都必须正常工作，同样的，响应从应用2发送到应用1时，两个系统也必须正常工作。这样的时序要求有点麻烦，使得系统稳定性降低。现在我们把这个紧耦合系统和图1.2的系统进行比较。

在图1.2中，应用1发送消息到MOM只是一个单方行为。可能一段时间后，应用2从MOM接收消息，这也是一个单方行为。任何一方都不需要知道另一方的存在，它们之间也没有任何时序要求。所以在分布式系统设计时，松耦合系统比紧耦合系统有巨大的优势。如图所示，这就是MQ存在的地方。

==========================================

消息总线（ Message Queue），后文称 MQ，是一种跨进程的通信机制，用于上下游传递消息。

MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。

使用了MQ之后，消息发送上游只需要依赖MQ，逻辑上和物理上都不用依赖其他服务。

既然MQ是互联网分层架构中的解耦利器，那所有通讯都使用MQ岂不是很好？这是一个严重的误区，调用与被调用的关系，是无法被MQ取代的。

MQ它是一个高效的可嵌入库，它解决了大部分应用程序需要解决的问题，变得在网络上有良好的可伸缩性，而没有多少成本。

它能在后台线程异步处理I/O。这些线程使用无锁数据结构与应用程序线程进行通信，所以并发.MQ 应用程序不再需要锁、信号量，或其他等待状态。

组件可以动态地来去自如，而MQ 会自动重新连接。这意味着你可以以任何顺序启动组件。你可以创建“面向服务的架构”（SOA），其中的服务可以在任何时间加入和离开网络。

它根据需要自动对消息排队。为此，它会智能地在对消息排队之前，将消息尽可能地推进到接收者。

它有一个处理过满队列（称为“高水位标志”）的方法。当队列满时，.MQ 会自动阻止发件人，或丢弃消息，这取决于你正在做的是哪种消息传递（即所谓的“模式”）。

它可以让你的应用程序通过任意传输协议来互相交流，这些协议可以是：TCP、多播、进程内、进程间。你不需要更改代码以使用不同的传输工具。

它使用依赖于消息传递模式的不同策略，安全地处理速度慢/ 阻塞的读取者。

它可以让你采用多种模式，如请求- 应答和发布- 订阅来将消息路由。这些模式是指你如何创建拓扑结构和网络结构。

它可以让你创建代理（proxy）来排队、转发，或通过一个调用来捕获消息。代理可以降低网络互联的复杂性。

它使用在线路上的简单组帧原封不动地传递整个消息。如果你写了一个10KB 的消息，那么你将收到一个10KB 的消息。

它不对消息强加任何格式。它们是零字节到千兆字节的二进制大对象。当你想表示你的数据时，可以选择其上的其他一些产品，如谷歌的协议缓冲区、XDR 等。

它能智能地处理网络错误。有时候它会重试，有时它会告诉你某个操作失败。

它可以减少你的能源消耗。少花CPU 多办事意味着使用电脑更少的能源，你可以让你的旧电脑使用更长的时间。

实际上，MQ 做的比这更多。它对你如何开发网络功能的应用程序有颠覆性的影响。从表面上看，这是一个在其上做zmq_msg_recv() 和zmq_msg_send() 的套接字风格的API。但该消息处理循环迅速成为中心循环，而你的应用程序很快就会分解成一组消息处理任务。它是优雅和自然的。而且，它可扩展：每个任务对应一个节点，节点通过任意传输方式互相交谈。在一个进程中的两个节点（节点是一个线程），在一台电脑中的两个节点（节点是一个进程），或一个网络上的两台电脑（节点是一台电脑），所有的处理方式都是相同的，不需要更改应用程序代码。

所以MQ在任何应用程序中以接近零的消耗开展工作。它应该是不需要任何其他依赖就可以链接的库。无须额外的变动部件，所以没有额外的风险。它应该能运行在任何操作系统上，并能用任何编程语言开展工作。