消息中间件利用高效可靠的消息传递机制进行异步的数据传输，并基于数据通信进行分布式系统的集成。通过提供消息队列模型和消息传递机制，可以在分布式环境下扩展进程间的通信。ActiveMQ、RabbitMQ、ZeroMQ

 

 

消息中间件的作用

解耦：

 

冗余〈存储)：有些情况下处理数据的过程会失败，造成数据丢失，可使用消息中间件进行数据持久化；

 

扩展性:消息中间件解耦了应用的处理过程，所以提高消息入队和处理的效率是很容易的，只要另外增加处理过程即可，不需要改变代码，也不需要调节参数。

 

削峰: 在访问量剧增的情况下，程序不会因为突发的超负荷请求而崩溃。

 

可恢复性: 当系统一部分组件失效时，不会影响到整个系，消息中间件降低了进程间的耦合度，所以即使 个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后进行处理。

 

顺序保证: 在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持 定程度上的顺序性。

 

缓冲: 在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过 个缓冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速 该缓冲层有助于控制和优化数据流经过系统的速度。

 

异步通信: 在很多时候应用不想也不需要立即处理消息 消息中间件提供了异步处理机制，允许应用把 些消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理

 

2.2 什么是消息中间件

消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。对于消息中间件，常见的角色大致也就有Producer（生产者）、Consumer（消费者）

 

对于消息的传递有两种类型：

 

一种是点对点的，即一个生产者和一个消费者一一对应：

 

另一种是发布/ 订阅模式，即一个生产者产生消息并进行发送后，可以由多个消费者进行接收：

 

1.1 为什么会需要消息队列(MQ)？

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

 

消息丢失问题

生产者弄丢了数据：可选择用RabbitMQ事务机制，可以开启confirm模式

 

异步操作RabbitMQ弄丢了数据，创建 queue 的时候将其设置为持久化，发送消息的时候将消息的deliveryMode设置为2

 

消费端弄丢了数据可以利用RabbitMQ的ack机制

 

顺序性

拆分多个 queue，每个 queue 一个 consumer，就是多一些 queue 而已，确实是麻烦点；或者就一个 queue 但是对应一个 consumer，然后这个 consumer 内部用内存队列做排队，然后分发给底层不同的 worker 来处理。

 

RabbitMQ有什么优缺点？

优点：解耦、异步、削峰；

 

缺点：降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低； 增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

 

 

 

如何保证RabbitMQ不被重复消费？

 

 

先说为什么会重复消费：正常情况下，消费者在消费消息的时候，消费完毕后，会发送一个确认消息给消息队列，消息队列就知道该消息被消费了，就会将该消息从消息队列中删除；

 

 

 

但是因为网络传输等等故障，确认信息没有传送到消息队列，导致消息队列不知道自己已经消费过该消息了，再次将消息分发给其他的消费者。

 

 

 

针对以上问题，一个解决思路是：保证消息的唯一性，就算是多次传输，不要让消息的多次消费带来影响；保证消息等幂性；