弹力设计篇之幂等性.pdfVIP

44|弹力设计篇之“幂等性设计”

2018-03-01

44|弹力设计篇之“幂等性设计”

朗读人：柴巍11′09′′|5.11M

所谓幂等性设计，就是说，一次和多次请求某一个资源应该具有同样的副作用。用数学的语言来表

达就是：f(x)=f(f(x))。

比如，求绝对值的函数，abs(x)=abs(abs(x))。

为什么我们需要这样的操作？说白了，就是在我们把系统解耦后，服务间的调用可能会有三个

状态，一个是成功（Success），一个是失败（Failed），一个是超时（Timeout）。前两者都是明

确的状态，而超时则是完全不知道是什么状态。

比如，超时是网络传输丢包的问题，可能是请求时就没有请求到，也有可能是请求到了，返回

结果时没有返回到等情况。于是我们完不知道下游系统是否收到了请求，而收到了请求是否处理

了，成功/失败的状态在返回时是否遇到了网络问题。总之，请求方完全不知道是怎么回事。

举几个例子:

订单创建接口，第一次调用超时了，然后调用试了一次。是否会多创建一笔订单？

订单创建时，我们需要去扣减库存，这时接口发生了超时，调用试了一次。是否会多扣一次

库存？

当这笔订单开始支付，在支付请求发出，在服务端发生了扣钱操作，接口响应超时了，调用

试了一次。是否会多扣一次钱？

因为系统超时，而调用户试一下，会给我们的系统带来不一致的副作用。

在这种情况下，一般有两种处理方式。

一种是需要下游系统提供相应的查询接口。上游系统在timeout后去查询一下。如果查到了，就

表明已经做了，成功了就不用做了，失败了就走失败流程。

另一种是通过幂等性的方式。也就是说，把这个查询操作交给下游系统，我上游系统重试，

下游系统保证一次和多次的请求结果是一样的。

对于第式，需要对方提供一个查询接口来做配合。而第二种方式则需要下游的系统提供支持

幂等性的接口。

全局ID

要做到幂等性的接口，需要有一个唯一的标识，来标志是同一笔。而这个ID由

分配是一件比较头疼的事。因为这个标识要能做到全局唯一。

如果由一个系统来分配，那么每一次都需要找那个系统来。这样增加了程序的性能开

销。如果由上游系统来分配，则可能会导致可能会出现分配ID重复了的问题。因为上游系统可能

会是一个集群，它们同时承担相同的工作。

为了不产生分配，我们需要使用一个不会的算法，比如使用UUID这样非常小的算

法。但UUID的问题是，它的字符串占用的空间比较大，索引的效率非常低，生成的ID太过于随

机，完全不是人读的，而且没有递增，如果要按前后顺序排序的话，基本不可能。

在全局唯一ID的算法中，这里介绍一个的开源项目Snowflake。它是一个分布式ID的生成

算法。其思想是，产生一个long型的ID，其中：

41bits作为毫秒数。大概可以用69.7年。

10bits作为机器编号（5bits是数据，5bits的机器ID），支持1024个实例。

12bits作为毫秒内的序列号。一毫秒可以生成4096个序号。

其他的像Redis或MongoDB的全局ID生和这个算法大同小异。我在这里就不多说了。你可

以根据实际情况加上业务的编号。

处理流程

对于幂等性的处理流程来说，说白了就是要过滤一下已经收到的。要做到这个事，我们需要一

个来记录收到的。

于是，当收到请求的时候，我们就会到这个中去查询。如果查找到了，那么就不再做查询

了，并把上次做的结果返回。如果没有查到，那么我们就记录下来。

但是，上面这个流程有个问题。因为绝大多数请求应该都不会是重新发过来的，所以让100%的请

求都到这个里去查一下，这会导致处