RabbitMq

思考问题：为什么要使用消息队列

一个系统需要调用多个系统或者模块，互相之间调用很复杂，维护起来很麻烦。

情景1–未使用队列前

如果现在新增e系统，就需要a系统的开发改系统；
如果现在D不需要A系统调用接口，就需要A系统的开发改系统
……

消息队列优点–解耦

哪个系统需要数据，自己去MQ里消费数据

情景2-未使用队列

这样，系统调用太多接口，影响用户体验

消息队列优点–异步

思考：引入消息队列会存在哪些问题

消息队列存在问题：

• 1 系统可用性降低

系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好，ABCD四个系统好哈的，没啥问题，
现在改为MQ,若MQ挂了怎么办

• 系统复杂性提高

例如：现在使用了MQ,你需要考虑消息是否重复消费？ 怎么处理消息丢失情况？问题大一堆，很痛苦吧

• 系统一致性问题

使用MQ后，BD系统写库成功，结果c系统写库失败，现在怎么办？

RabbitMq可靠性–镜像集群模式

数据丢失怎么办

生产者

• 1 设置channel 设置成confirm的模式
• 2 发送一个消息
• 3 RabbitMq如果接收到了这条消息的话，
  就会回调你系统里一个接口，通知消息已经收到了；
  如果接收消息失败，也通知你消息接收失败，
  此时候你可以进行重推

RabbitMq:

• rabbitmq:持久化磁盘（queue 持久化，发送消息，deliveryMode=2）

消费者：

• auto ack机制，消费到了一条消息

数据丢失处理方案图

关于重复消费

解决方案：每个消息都有一个唯一id，如果已经处理过无需再次处理

其他问题

• 1 ）如果Mq数据挤压怎么办
  解决方案：
  第一步修复consumer故障

  第二步 临时部署多一些consumer应用进行消费

• 2）rabbitmq设置了消息过期时间，导致数据丢失了，怎么办
  解决方案：生产者消息重发
• 3）mq数据挤压，磁盘满了怎么办？
  解决方案：临时写一个程序把消费一个放弃一个；在进行重推消息