消息中间件，常见的有activemq，oracle aq，ibm websphere mq,rabbitmq，阿里的rocketmq等等把，不一而足，这么多的mq为什么要出现呢？大家有没有思考过？或者是了解过。
其实，最最初，是这样的：
拿上面这个图举例来说，a系统需要不停的给b系统推送数据，假设每秒推送100条大的json串，而b系统需要对每一条json串进行校验、解析之后再入库等等其他操作，假设b系统每秒能处理10条json串，那么两秒过后，在b系统这里将会堆积180条json串未被处理，再简单点说，如果你的json串都存储在一个叫做List<String>的集合中，那么我们试着想一下，一分钟过后、一个小时过后、一天过后，这个集合会占用多少内存？这样肯定就会有oom（内存溢出OutOfMemoryError）发生，因此，人们就想出来使用消息中间件这么一种东西来解决这种问题：
如此一来，消息都堆积在mq之中，b系统只需要按着自己的处理频率去有节奏的读取消息并处理就行了。
上面就是mq（message queue消息队列）出现的背景以及原始是解决什么样的问题的，当然，现在mq的应用领域已经大大的被人们扩展了，经常应用于多个系统之间交互数据。
当前，springboot，rmi，dubbo，http等涉及到rpc远程调用的中间技术已经大行其道，但是面对规模愈来愈大的分布式系统这些rpc调用也展露出了它的问题：
01.同步通信：当客户端发出调用请求之后，必须等待服务端处理完成之后才能获取到结果
02.客户端和服务端耦合性较强：客户端的调用必须依赖服务端的正常运行
03.点对点通信
面向消息的中间件（message oritented middleware，mom）较好的解决了上面的问题，为什么如此说呢？
mon工作流程：发送者将消息发送到消息服务器，消息服务器把这些消息放在各自的队列中，客户端来使用的话，只需要从消息服务器的队列中来取得消息就行了。这种情况下，发送和接受是异步的，二者的声明周期也没必要完全一样，而且可以一条消息被n个客户端来消费。
java里面的消息服务（jms）定义了一套接口规范，实现了这套接口规范的mom就是所谓的“消息中间件”了，这类东西有很多，比如Apache的activemq，以及阿里巴巴的metaMQ(3.X改为rocketmq，不过已经闭源了)，ibm的ibm webshpere mq，微软的msmq以及其他的诸如rabbitmq以及大数据领域的apache的kafka等。
