如何避免重复提交?分布式服务的幂等性设计!

如何避免重复提交?分布式服务的幂等性设计!


如何避免重复提交?分布式服务的幂等性设计!


来源:https://www.cnblogs.com/QG-whz/p/10372458.html
作者:melonstreet

为什么需要保证幂等性

编程中的“幂等性”是指任意多次执行所产生的影响,与一次执行的影响相同。一个拥有幂等性设计的接口,保证无论一次或多次来调用接口,都能够得到相同的结果。接口的幂等性设计在某些场景下是必需的,例如用户下单的场景。

我们知道,服务之间的调用存在三种状态:成功、失败、超时。超时是一种未知的状态:被调服务是否执行成功,这个状态是未知的。上游服务调用下游服务超时时可能会进行重试。对于用户下单的场景的超时重试我们考虑以下问题:

  • 是否会导致最终创建了两条一样的订单?

  • 是否会扣除两遍库存?

  • 是否会重复扣除用户的钱?

如果每一笔订单都携带唯一的序号,下单接口可以借助这个序号,来记录某次下单操作的状态。当下单的状态为成功时,就将重复的执行拦截住,避免出现上述的问题。这种方式是由下游被调方来保证幂等性。

除此之外,订单服务也可以提供查询订单状态的接口,上游在下单之前先进行查询,确认该笔订单并没有成功支付后,再重复进行下单操作。

一般来说,服务本身需要自己保证幂等性,而不应该将幂等性交给上游的调用方来做。

唯一ID

就上面的幂等性下单接口来说,要做到幂等性,就需要借助一个唯一的ID来标志每次交易。唯一ID的分配可以有几种方式:

  • 由一个统一的ID分配中心来分配。

  • 由上游服务来生成唯一ID,但必须保证不产生冲突的ID。

采用统一的分配中心来分配唯一ID时,业务方每次调用接口都多了一次调用分配中心获取唯一ID的请求。这多了额外的开销。获取唯一ID有一种方式,是借助mysql的自增索引,这其实也是一个ID分配中心。对服务性能有苛刻要求时,可以采用第二种方式,由主调服务本身来生成这个唯一ID。为了保持不会产生重复的ID,可以使用一下几种ID生成方法:

UUID

UUID的全称是Universally Unique Identifier,通用唯一识别码。具体可以看维基百科的介绍:https://en.wikipedia.org/wiki/Universally_unique_identifier

UUID是一个128bit的数字,用于标志计算机的信息,虽然UUID不能保证绝对不重复,但重复的概率小到可以被忽略。UUID的生成没有什么规律,为了保证UUID的唯一性,规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素,以及从这些元素生成UUID的算法。这也就意味着:

  • 128bit,占据了太多的内存空间

  • 生成的ID不是人可以看懂的

  • 无法保证ID的递增,某些场景需要按前后排序 无法满足。

这是一个在线生成UUID的网站:https://www.uuidgenerator.net/ 你可以直观感受一下UUID。

Snowflake

这是Twitter的一个开源项目,它是一个分布式ID的生成算法,它会产生一个long类型的唯一ID,其核心算法是:

  • 时间部分:41bit作为毫秒数,大概可以使用69.7年

  • 机器编号部分:10bit作为机器编号,支持1024个机器实例。

  • 毫秒内的序列号:12bit,一毫米可以生成4096个序列号

如何避免重复提交?分布式服务的幂等性设计!

网上有各种语言实现的Snowflake算法的实现,有兴趣的阅读一下实现代码。

实际上,redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小异。这是基于redis的分布式ID生成器实现:https://github.com/hengyunabc/redis-id-generator

它的核心思想是:

  • 使用41 bit来存放时间,精确到毫秒,可以使用41年。

  • 使用12 bit来存放逻辑分片ID,最大分片ID是4095

  • 使用10 bit来存放自增长ID,意味着每个节点,每毫秒最多可以生成1024个ID

共享存储

如果我们的幂等性服务是分布式的,那么存储唯一ID也需要采用共享的存储,这样每个服务就是无状态的了。可以使用mysql来存储,也可以使用k-
v存储例如redis。我在自己的业务中就采用了redis来存储唯一key。

避免不必要的查询

并不是所有的请求都是重复的,生产环境下可能99%的请求都不是重复请求。如果每个请求在执行前都要去查询下唯一ID是否存在,可能会带来不必要的性能消耗。如果你使用mysql来存储唯一ID,那么可以直接进行insert,通过结果来判断是否插入记录成功,如果不成功则证明ID已经存在:

    insert into ... values ... on DUPLICATE KEY UPDATE ...

而如果使用的是redis,也可以使用redis的setEx,设置成功则证明key不存在,否则key存在说明是重复请求。

如何避免重复提交?分布式服务的幂等性设计!

如何避免重复提交?分布式服务的幂等性设计!

原文始发于微信公众号(全栈程序员社区):如何避免重复提交?分布式服务的幂等性设计!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/104489.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号