消息中间件利用高效可靠的消息传递机制进行异步的数据传输,并基于数据通信进行分布式系统的集成。通过提供消息队列模型和消息传递机制,可以在分布式环境下扩展进程间的通信。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不被重复消费?
先说为什么会重复消费:正常情况下,消费者在消费消息的时候,消费完毕后,会发送一个确认消息给消息队列,消息队列就知道该消息被消费了,就会将该消息从消息队列中删除;
但是因为网络传输等等故障,确认信息没有传送到消息队列,导致消息队列不知道自己已经消费过该消息了,再次将消息分发给其他的消费者。
针对以上问题,一个解决思路是:保证消息的唯一性,就算是多次传输,不要让消息的多次消费带来影响;保证消息等幂性;