幂等性问题

最新推荐文章于 2025-05-14 10:51:03 发布

永远的18岁记忆

最新推荐文章于 2025-05-14 10:51:03 发布

阅读量8.8k

点赞数 1

分类专栏： java 文章标签：幂等性

java 专栏收录该内容

18 篇文章

订阅专栏

所谓幂等，简单地说，就是对接口的多次调用所产生的结果和调用一次是一致的。扩展一下，这里的接口，可以理解为对外发布的HTTP接口或者Thrift接口，也可以是接收消息的内部接口，甚至是一个内部方法或操作。

数学上的定义：f(f(x)) = f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中，我把它简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的，在实际应用中一般针对于接口进行幂等性设计。举个栗子，在系统中，调用方A调用系统B的接口进行用户的扣费操作时，由于网络不稳定，A重试了N次该请求，那么不管B是否接收到多少次请求，都应该保证只会扣除该用户一次费用。

那么我们为什么需要接口具有幂等性呢？设想一下以下情形：

在App中下订单的时候，点击确认之后，没反应，就又点击了几次。在这种情况下，如果无法保证该接口的幂等性，那么将会出现重复下单问题。
在接收消息的时候，消息推送重复。如果处理消息的接口无法保证幂等，那么重复消费消息产生的影响可能会非常大。

在分布式环境中，网络环境更加复杂，因前端操作抖动、网络故障、消息重复、响应速度慢等原因，对接口的重复调用概率会比集中式环境下更大，尤其是重复消息在分布式环境中很难避免。Tyler Treat也在《You Cannot Have Exactly-Once Delivery》一文中提到：

Within the context of a distributed system, you cannot have exactly-once message delivery.

分布式环境中，有些接口是天然保证幂等性的，如查询操作。有些对数据的修改是一个常量，并且无其他记录和操作，那也可以说是具有幂等性的。其他情况下，所有涉及对数据的修改、状态的变更就都有必要防止重复性操作的发生。通过间接的实现接口的幂等性来防止重复操作所带来的影响，成为了一种有效的解决方案。

GTIS

GTIS就是这样的一个解决方案。它是一个轻量的重复操作关卡系统，它能够确保在分布式环境中操作的唯一性。我们可以用它来间接保证每个操作的幂等性。它具有如下特点：

高效：低延时，单个方法平均响应时间在2ms内，几乎不会对业务造成影响；
可靠：提供降级策略，以应对外部存储引擎故障所造成的影响；提供应用鉴权，提供集群配置自定义，降低不同业务之间的干扰；
简单：接入简捷方便，学习成本低。只需简单的配置，在代码中进行两个方法的调用即可完成所有的接入工作；
灵活：提供多种接口参数、使用策略，以满足不同的业务需求。

实现原理

基本原理

GTIS的实现思路是将每一个不同的业务操作赋予其唯一性。这个唯一性是通过对不同操作所对应的唯一的内容特性生成一个唯一的全局ID来实现的。基本原则为：相同的操作生成相同的全局ID；不同的操作生成不同的全局ID。

生成的全局ID需要存储在外部存储引擎中，数据库、Redis亦或是Tair等均可实现。考虑到Tair天生分布式和持久化的优势，目前的GTIS存储在Tair中。其相应的key和value如下：

key：将对于不同的业务，采用APP_KEY+业务操作内容特性生成一个唯一标识trans_contents。然后对唯一标识进行加密生成全局ID作为Key。
value：current_timestamp + trans_contents，current_timestamp用于标识当前的操作线程。

判断是否重复，主要利用Tair的SETNX方法，如果原来没有值则set且返回成功，如果已经有值则返回失败。

内部流程

GTIS的内部实现流程为：

业务方在业务操作之前，生成一个能够唯一标识该操作的transContents，传入GTIS；
GTIS根据传入的transContents，用MD5生成全局ID；
GTIS将全局ID作为key，current_timestamp+transContents作为value放入Tair进行setNx，将结果返回给业务方；
业务方根据返回结果确定能否开始进行业务操作；
若能，开始进行操作；若不能，则结束当前操作；
业务方将操作结果和请求结果传入GTIS，系统进行一次请求结果的检验；
若该次操作成功，GTIS根据key取出value值，跟传入的返回结果进行比对，如果两者相等，则将该全局ID的过期时间改为较长时间；
GTIS返回最终结果。

实现难点

GTIS的实现难点在于如何保证其判断重复的可靠性。由于分布式环境的复杂度和业务操作的不确定性，在上一章节分布式锁的实现中考虑的网络断开或主机宕机等问题，同样需要在GTIS中设法解决。这里列出几个典型的场景：

如果操作执行失败，理想的情况应该是另一个相同的操作可以立即进行。因此，需要对业务方的操作结果进行判断，如果操作失败，那么就需要立即删除该全局ID；
如果操作超时或主机宕机，当前的操作无法告知GTIS操作是否成功。那么我们必须引入超时机制，一旦长时间获取不到业务方的操作反馈，那么也需要该全局ID失效；
结合上两个场景，既然全局ID会失效并且可能会被删除，那就需要保证删除的不是另一个相同操作的全局ID。这就需要将特殊的标识记录下来，并由此来判断。这里所用的标识为当前时间戳。

可以看到，解决这些问题的思路，也和上一章节中的实现有很多类似的地方。除此以外，还有更多的场景需要考虑和解决，所有分支流程如下:

图片描述

使用说明

使用时，业务方只需要在操作的前后调用GTIS的前置方法和后置方法，如下图所示。如果前置方法返回可进行操作，则说明此时无重复操作，可以进行。否则则直接结束操作。

图片描述

使用方需要考虑的主要是下面两个参数：

空间全局性：业务方输入的能够标志操作唯一性的内容特性，可以是唯一性的String类型的ID，也可以是map、POJO等形式。如订单ID等
时间全局性：确定在多长时间内不允许重复，1小时内还是一个月内亦或是永久。

此外，GTIS还提供了不同的故障处理策略和重试机制，以此来降低外部存储引擎异常对系统造成的影响。

目前，GTIS已经持续迭代了7个版本，距离第一个版本有近1年之久，先后在美团点评多个项目中稳定运行。

结语

在分布式环境中，操作互斥性问题和幂等性问题非常普遍。经过分析，我们找出了解决这两个问题的基本思路和实现原理，给出了具体的解决方案。

针对操作互斥性问题，常见的做法便是通过分布式锁来处理对共享资源的抢占。分布式锁的实现，很大程度借鉴了多线程和多进程环境中的互斥锁的实现原理。只要满足一些存储方面的基本条件，并且能够解决如网络断开等异常情况，那么就可以实现一个分布式锁。目前已经有基于Zookeeper和Redis等存储引擎的比较典型的分布式锁实现。但是由于单存储引擎的局限，我们开发了基于ZooKeeper和Tair的多引擎分布式锁Cerberus，它具有使用灵活方便等诸多优点，还提供了完善的一键降级方案。

针对操作幂等性问题，我们可以通过防止重复操作来间接的实现接口的幂等性。GTIS提供了一套可靠的解决方法：依赖于存储引擎，通过对不同操作所对应的唯一的内容特性生成一个唯一的全局ID来防止操作重复。

目前Cerberus分布式锁、GTIS都已应用在生产环境并平稳运行。两者提供的解决方案已经能够解决大多数分布式环境中的操作互斥性和幂等性的问题。值得一提的是，分布式锁和GTIS都不是万能的，它们对外部存储系统的强依赖使得在环境不那么稳定的情况下，对可靠性会造成一定的影响。在并发量过高的情况下，如果不能很好的控制锁的粒度，那么使用分布式锁也是不太合适的。总的来说，分布式环境下的业务场景纷繁复杂，要解决互斥性和幂等性问题还需要结合当前系统架构、业务需求和未来演进综合考虑。Cerberus分布式锁和GTIS也会持续不断地迭代更新，提供更多的引擎选择、更高效可靠的实现方式、更简捷的接入流程，以期满足更复杂的使用场景和业务需求。