MQ--为什么使用它？

MQ，英文全称就是Message Queue的简称，消息队列。

应用场景：高并发环境下，由于来不及同步处理，请求往往会发生堵塞。如果使用mysql数据库作为共享数据库，那么大量的insert和update操作

将会同时到达mysql，直接导致无数的行锁表锁，最后可能堆积过多，导致too many connections错误。通过使用消息队列，可以异步处理请求，

缓解系统的压力。异步请求就像ajax，当我们想局部刷新时，使用异步加载数据就不会影响我们对页面其他功能的使用。

MQ是IBM的产品，算是一个处理消息的中间件，它的优点有：

1.提供了用于应用集成的松耦合的连接方法，因为共享信息的应用不需要知道彼此物理位置（网络地址），消息都通过这个中间件处理；

2.不需要知道彼此间怎样建立通信，因为只要按照MQ的标准进行通信就可以了；

3.不需要同时处于运行状态，像TCP连接，我们使用QQ的时候，我们不在线，下次登录还是能收到消息；

4.不需要在同样的操作系统或网络环境下运行，有统一的标准就能进行信息交换了。

为什么不用数据库：

（原作者为csdn的humanity）

你没仔细想分布式应用是怎么回事，不要只站在编码的角度想问题，要站在系统设计的角度看到每个系统的工作流程和数据流转过程，一个系统运行后，数据从哪儿来，经过什么人或程序的加工后需要去什么地方，处理完毕需要通知谁，出什么报表。

用数据库可以实现，但要知道共用数据库本身也是有局限的。

第一，共用数据库是否现实？对于架设在大型网络上的应用，我们不能假设每台服务器都是我们客户自己家的机器，比如把中国银行数据上报给人民银行，不能假设他们两家把服务器都交给一个人或放在一个机房管理)。

第二，共用数据库，那么是不是一个公司的所有系统上线之后，如果它们需要交换数据就都得把数据放到一个数据库上，如果这家公司真是有很多数据量也有很多系统需要交换数据，你的数据库服务器吃得消吗？如果机器故障的话，所以系统不能运行导致整个公司关门一天不营业？

第三，很多大型机构以前的系统是经过测试和运营考验的，只要它能运行就不能改它们的东西，像中国银行的系统运行了几十年，为了开发一个新的系统为了与外部系统对接把它们都改一下来适合新的需要那是不现实的。

第四，分布式应用就是，你不需要知道别人在干什么，你只管把数据以某种方式发过去，(可选的：然后去等回复状态码或回复数据)，就可以了，注意，数据交换的双方是在以数据为中心(加上一些状态码/控制码的约定)，不需要知道对方的任何无关的细节(比如什么操作系统，是C++还是VB，对于非实时/异步的应用来说对方没开机都没关系，就像你发一条短信不用立即等待回复)。