如何使用MQ？

好记忆不如烂笔头，能记下点东西，就记下点，有时间拿出来看看，也会发觉不一样的感受。

目录

一、消息的选型：

二、消息的使用：

三、消息获取

四、异常信息:

​五、消息的弊端：

 六、具体使用：

---

今天来聊一聊消息，都知道在系统中使用消息，其目的无非是：异步，削峰，解耦。

换言之，我们在系统中引入MQ，其目的是为了解决现有系统中可能遇到的：异步操作，系统耦合或是大流量、高并发削峰的场景。

消息的好处无非就是这些，可以帮助我们解决系统的这些问题，那么我们来聊聊消息使用时候该注意些什么？

一、消息的选型

ActiveMQ,RabbitMQ,RocketMQ,Kafka，ZeroMQ 等，其中的kafka，发送接收消息只是人家的兼职，它主业是做流式处理。其各类型，参数，性能对比之下，选择的最优之选是RocketMQ。

（RocketMQ >RabbitMQ >Kafka >ZeroMQ >ActiveMQ）想了解更多详细，去度娘，谷妈搜索。

二、消息的使用

1.给每一条消息，设置一个全局唯一的messageId,确保消息是唯一的;

2.消息消费成功之后,将消息messageId 和消息本身以K-V 的形式存储在中间介质（redis，数据库）中，为什么不是本地缓存，因为本地缓存在分布式的时候，就无法保证获取信息；

3.在消息消费过程中，使用全局的分布式锁（redis实现，redisson实现）将业务代码块全部锁起来，在业务处理完成值，再在finally中释放锁。

4.业务操作完成之后，告诉MQ，该消息已被消费，无需在保存，可将该消息信息从MQ中移除。

注意一点：在复杂的业务操作中，比如方法A有事务标识，操作表table，方法A中又调用了方法B，方法B也有事务标识；在方法A中发布了消息M，在监听L中监听消息M并操作表table操作...

这其中,都需要操作数据库，因为事务的传递性，会存在：方法B的事务是依赖方法A的，在整个方法A的事务没有commit之前,监听L在操作表table的时候，是没有数据的，这是为什么呐？

因为在A中，消息发布之后，L就去消费了，就去查库了，可是因为事务还没有提交，所以查询不到数据。

那么怎么解决这样的问题呐？

方案1：延迟队列发送，或延迟队列消费;

方案2：想办法将操作表的业务都集中在B中,并且确保在A中的消息M发出之前，事务提交；

三、消息获取

1.使用监听器，定时去监听队列，只要是发到该队列上的信息，都会被消费；

2.主动拉取消费，可以写一个任务，定时的去某个指定的对列中去拉取消息信息，然后去消费；

四、异常信息

1.消息始终无法被消费，将其放入到死性队列中去；

2.在写一个监听或者是拉取的实现，将放入死性队列中的消息信息拿出来消费;

3.拿出消息之后，告诉死性队列，消息已消费，可以在MQ中进行移除。

​五、消息的弊端

1、系统可用性降低：系统引入的外部依赖越多，越容易挂掉，可能开始，你就是一个系统调用几个系统的接口，被调用的系统好好的，没啥问题，如果加个了MQ进来，MQ可能会挂掉，一旦MQ挂了，整套系统崩溃了，就会出大问题，虽然可以使用分布式消息部署，但是还是不保险。

2、系统复杂性提高：强行使用MQ，消息可能会重复消费，消息也有可能会丢失，消息传递的顺序性也可能会乱序，问题一大堆。

3、一致性问题：一个系统处理完了直接返回成功了，就会以为这请求处理是成功的；但是实际上是，另外的系统那里，可能某几个系统写库成功了，结果有个系统写库失败了，容易导致数据不一致。

 六、具体使用

        虽然使用MQ可以帮住我们处理很多问题，但是同样也会有很多的弊端，那么在使用的时候，一定要记住：不要习惯性的都去使用MQ，就像使用索引可以加快查询速度，但是并不是索引越多就越好是一个道理。

         在使用MQ的时候，一定要有个度，控制住风险。

更多干货，尽在公众号：码出精彩 codingba