MQ消息队列系列（1）为什么使用MQ

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

2.松耦合

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也提供消息的请求/回复模式支持。