使用消息队列进行限流（下） - 避免重复消费与消息积压问题

在公众号回复课程,免费获取JAVA全栈课程

做者 | 颜群java

公众号 | 大数据和人工智能技术git

前两篇请戳：
web

使用消息队列进行限流（上）
面试

使用消息队列进行限流（中） - 如何避免消息丢失
算法

本文解决最后两个问题：在使用MQ发送消息的过程当中，数据库

1.如何避免消息被重复消费编程

2.如何处理消息积压问题
服务器

如何避免消息被重复消费

在使用MQ的过程当中，各类异常状况均可能形成消息被重复消费。微信

例如不少类型的MQ都使用了offset（偏移量）记录每一个消息的序号，用于保证消息的顺序传输或者在出现灾难时可以从指定序号的消息恢复传输。网络

但试想如下场景：假设消息的处理逻辑是“先消费消息，再更新offset”，那么当消息刚刚被消费完毕但尚未来得及更新offset时就出现故障宕机，MQ就会在恢复启动时再次消费刚刚已经被消费过的消息，即出现了重复消费的状况。所以，不管是采用了哪一种协议的MQ，都须要思考如何避免消息被重复消费的问题。

实际上不只仅是MQ，在分布式系统的各个服务之间在相互调用时也须要解决“重复消费”的问题。例如在分布式秒杀系统中，若是“订单服务”成功调用了“支付服务”（即已经支付成功），但“支付服务”在做出响应时因为网络等缘由未能成功的响应“订单服务”，就会形成“订单服务”没法更新支付状态，最终就可能致使用户误觉得支付无效而从新再发起一次新的支付请求，从而致使用户重复消费的状况，如图所示。

可见这种“重复消费”问题广泛存在于各个分布式项目当中，所以必须妥善解决。好消息是，解决的思路也是通用的——能够借助“幂等性原则”解决。

幂等性原则是对调用服务次数的一种限制，即不管对某个服务提供的接口调用屡次或是一次，其结果都是相同的。

若是从功能的角度看来，任何一个操做都是CRUD中的一种。但对于“重复消费”这个问题而言，咱们只须要研究“增长”和“修改”两种操做，即“查询”和“删除”是不须要考虑幂等性的，由于“重复查”和“重复删”对逻辑而言是没有任何影响的。

“幂等性”是一个原则，它的具体实现方式也是五花八门。咱们本次主要介绍如何实现“增长”操做的幂等性，其核心思路主要有两种：使用数据库主键或去重表，以下所示。

根据数据库主键实现幂等性
核心就是利用主键(或惟一约束)的“惟一性”来保证插入数据的惟一。例如，在用户下单时，能够在“订单服务”中生成一个“订单id”，而后用此“订单id”的值再做为“支付服务”的“支付id”值。若是出现了重复支付，就会违反主键的惟一约束，从而避免重复消费的场景。固然，本段介绍的“直接用订单id做为支付id”只是为了说明这种使用主键实现幂等性的原理，在实际开发时，咱们也能够对这两个id进行一些映射处理，或者使用联合主键也是一种很好的实现策略。
根据去重表实现幂等性
可使用集合或者Redis构建一张“去重表”，表中存放的是全局惟一的id值。当用户每次发起请求时，先查看“去重表”中是否已有这次支付操做的id值，若是已有则直接返回“成功”；若是没有，就说明尚未进行实际的支付操做，此时就进行支付操做，并在支付成功后将id值写入“去重表”中，防止重复消费。
以上两种思路可以实现大部分“增长”操做的幂等性。对于“修改”操做，你们能够参考版本控制软件（如svn、git）中防止提交冲突的CAS算法。例如在svn中，当A用户修改并提交了数据后，B用户是没法直接提交的，不然就会出现冲突。这种版本控制的思路，就能够拿来实现“修改”操做的幂等性，即当第一次修改数据后，以后若是再次修改，就应该给予错误提示。