99%的人都能看懂的MQ补偿机制

爱被打了一巴掌 2022-09-12 05:52 278阅读 0赞

### 补偿机制的意义 ###

假设有这样子一种场景：客户端请求 ---->空间结构微服务 ---->业主档案微服务 ---->房源微服务。这种调用链非常普遍。那么为什么需要考虑补偿机制呢？

一次跨机器的通信可能会经过DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。

但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。那么当某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。

### 事务补偿 ###

事务补偿则代表着整个事务进行回滚和失败，则最终结果会失败。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16]

### 重试 ###

重试和补偿不太一张，重试有一定机会处理成功。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 1]

### 基于RabbitMQ的自动补偿机制 ###

在RabbitMQ里，如果消费者在处理消息时，业务逻辑出现异常，默认会执行补偿机制（也就是消息重试机制）。如果业务逻辑出现异常，是不会消费消息的。

我们先在消费者处理消息的地方模拟一个异常：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
生产者发送消息给消费者，会发现控制台一直在打印错误日志，也就是说，消费者一直在重试消费（补偿）：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
接下来我们去RabbitMQ控制台看一下消息是否被成功消费，从控制台可以看出，我们是的消息是没有被成功消费的：  
![在这里插入图片描述][f33496ecd0584b18a27ae5e3c7fc2d82.png]  
那么RabbitMQ消费者的补偿原理是怎样的呢？

*  @RabbitListener 底层使用了AOP进行拦截，如果程序没有抛异常，自动提交事务。
 *  如果AOP使用异常通知拦截获取异常信息的话，自动实现补偿机制，该消息会缓存到RabbitMQ服务端进行缓存，一直重试到不抛异常为准。

其实在application.yml配置文件可以配置重试的次数与时间的，如重试5次，每次3秒：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_14_color_FFFFFF_t_70_g_se_x_16]  
加好配置之后，再次运行程序，发现重试了5次，3秒重试一次，而且RabbitMQ控制的消息也消费了。

### 基于人工补偿机制 ###

上面说到了基于MQ的补偿机制，但其实思想也是重试机制，但是重试机制也有可能最终失败，所以针对这种场景我们还是需要人工干预，保证我们的MQ消费成功。

*  创建一个MQ消费记录表  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 4]
 *  MQ消费伪代码  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 5]
 *  最后引入定时任务，去MQ消费记录表找到消费失败的消息体进行补偿，保证最终一致性。

### 如何合理选择重试机制 ###

下面有两种情况：

*  情况一：消费者获取到消息后，调用第三方接口，但接口暂时无法访问，是否需要重试? （需要重试机制）
 *  情况二：消费者获取到消息后，抛出数据转换异常，是否需要重试?（不需要重试机制）。

对于情况一是需要重试机制的，因为第三方API接口无法访问可能是多种原因造成的，比如网络延时等。而情况二不需要重试机制，因为异常的代码是一直都会有异常的，只能通过下一次发布版本解决。

### 总结 ###

引入MQ确实有利于系统解耦，但同时也增加了系统架构的复杂和运维成本。在分布式系统中使用MQ，并且想好补偿方案是非常重要的，对于数据一致性要求较高的不建议引入MQ，对数据一致性要求不高的系统中我们可以通过MQ解耦，并通过补偿机制保证我们数据的最终一致性是一个不错的选择。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/f209713f19eb4449afaeb182902c29c3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/b06ec456beef4d65b5fc4f8789412d4b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/52f05349ab0748e8a50a370e39a43e24.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/0f0ab7ad6f9f4e5b9e13eb70a143a5d7.png
[f33496ecd0584b18a27ae5e3c7fc2d82.png]: /images/20220828/70e82887296145e8897560d12c17a98a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/503eb8018ae14dad899c869ced1a0549.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/305c6ce0a8ac43e2b8eb116c62f403e5.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA56iL6ZOt56iL6ZOt5L2g5b-r5oiQ5ZCN_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/c836c2d0c11f4801a915780603721072.png