消息队列

------------恢复内容开始------------

1.说一下你都在什么场景用到了消息队列

　　消息队列：异步、削峰、解耦

2使用mq的好处

1）解耦与复用

系统A要发送一个消息到多个系统，如果此时每增加一个系统，系统A都需要通过修改源码来增加接口，此时耦合非常高，但是如果中间使用消息队列的话，系统只需要发送一次到消息队列，别的系统就能复用该信息，当增加或删除系统调用接口的时候，不需要额外的更新代码。

2）异步

用户调用一个接口的时候，可能该接口调用了别的方法。例如：用户注册的时候，后台可能需要调用：查询数据库，插入数据库，发送邮件，发送用户指南等等...

但是用户可能并不需要后台将所有的任务执行完毕，那么此时在初入数据口后面加入mq队列，用户就能很快得到注册成功的响应而去做一些别的事情。mq的机制又能保证最终的一致性，所以使用起来很安全很稳定。

客户响应时间缩短---mq的机制又能保证最终的一致性，所以使用起来很安全很稳定

异步，那我用线程，线程池去做不是一样的么？

为什么使用消息队列而不用线程

　　原因：

　　　　每次添加一个后续业务接口，你都需要调用调用一个接口然后重新发布系统，并且写在一起耦合性高，排查问题麻烦，所以和线程相比的话，mq的异步处理能更好的解耦

 

 

 

 

3）消峰

何为消峰，就是当系统压力过大的时候，让系统压力减小。如何做？

加入数据库的读写每秒3000，在高峰期，系统的访问达到了每秒10000。此时由于加入了消息队列，所以不会出现激增的访问导致系统奔溃。
（注意，晓峰并不会让用户的等待时间减少，所以一般会跟异步搭配来使用）

使用mq的缺点

1）增加了复杂度，降低了可用性 

消息重复消费、消息丢失、消息的顺序消费等等

本来系统之间直接通行调用接口就行了，但是引入了mq导致系统的复杂度大大增加，并且如果mq挂掉了，那么系统之间的通信就中断了，导致整个系统的全部挂掉。

2）一致性问题

A系统处理完了发送到消息对流后直接返回成功了，用户以为你这个请求就成功了；但是问题是，其他系统消费该消息后，如果当中有一个系统出现了问题，导致数据丢失。最后就会发生数据不一致等问题。

这就需要异常处理机制：保证事务一致性：分布式事务：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。

------------恢复内容结束------------