分布式服务的幂等性设计

目录

  • 为什么需要保证幂等性
  • 唯一ID
    • UUID
    • Snowflake
  • 共享存储
  • 避免不必要的查询

为什么需要保证幂等性

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

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

  • 是否会导致最终创建了两条一样的订单?
  • 是否会扣除两遍库存?
  • 是否会重复扣除用户的钱?

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

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

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

唯一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存在说明是重复请求。

原文地址:https://www.cnblogs.com/QG-whz/p/10372458.html

时间: 2024-10-08 20:52:06

分布式服务的幂等性设计的相关文章

[分布式服务]海量互联网服务设计之降级设计

目录 降级一致性 缓存的使用 流程异步化 行为聚集化 体验降级 简化流程 分级体验 降级服务要点 上周在 [分布式服务]海量互联网服务设计的有损价值观 这篇文章中提到,与金融行业服务要求的强一致性不同,海量互联网服务要求的是能够扛住更高的qps,服务降级研究的问题是在服务器资源有限的情况下,如何提供更大的访问量,并保证系统稳定运行. 最近我搬了个房子,房东还没来得及上面装宽带,所以在家里我是用手机热点上网的.热点网速有限,看视频的时候,为了视频流程的播放,我将视频从蓝光调整到270P,虽然视频清

分布式服务框架选型:面对Dubbo,阿里巴巴为什么选择了HSF?

转载:http://www.sohu.com/a/141490021_268033 阿里巴巴集团内部使用的分布式服务框架 HSF(High Speed Framework,也有人戏称"好舒服")已经被很多技术爱好者所熟知,目前已经支撑着近 2000 多个应用的运行. 其对应早期的开源项目 Dubbo(因为某些原因,Dubbo 项目在 2012 年年底,阿里巴巴就停止了对此开源项目的更新),则更是在互联网领域有着非常高的知名度和广泛的使用. 本文通过对阿里巴巴 HSF 服务框架的介绍,让

RSF 分布式服务框架设计

是时候设计一个分布式服务框架了.我先将它定名为 Hasor-RSF,"RSF"为 Remote Service Framework 的缩写. RSF的目的是为了提供一种高效的远程服务访问方式,例如"A机器访问在B机器上的一个服务".当然首先它是运行在Java上的,但是我并不希望 Java 成为 RSF的唯一平台. 它应该是分布式的,就是说服务 A 可能会分布在若干台机器内. 当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用.这样做的好处是有助于

服务高可用:幂等性设计

什么是幂等性? 一般在服务调用时,读服务如果调用失败了,会自动按配置次数转移到别的服务上去请求.而写服务就不能重复请求,如果因为超时或者网络故障等原因被调用服务并没有返回成功的响应,服务调用方就认为是失败了,但很有可能的是已经成功了,如果继续重复请求写服务,如转账类的服务,可能会造成严重的后果.所以,写服务失败不能设计成继续发重复请求,被调用服务也要设计幂等性,即使重复请求,也不会造成影响. 知道上面的背景,所以,幂等性就是同样的参数,重复请求相同的服务,必须得到相同的结果. 幂等性设计 举一个

Alibaba开源的分布式服务框架:Dubbo是what?

  Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,      Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.关于注册中心.协议支持.服务监控等内容,详见后面描述.  Webservice也是一种服务框架,但是webservice并不是分布式的服务框

浅谈分布式服务协调技术 Zookeeper

Google的三篇论文影响了很多很多人,也影响了很多很多系统.这三篇论文一直是分布式领域传阅的经典.根据MapReduce,于是我们有了Hadoop:根据GFS,于是我们有了HDFS:根据BigTable,于是我们有了HBase.而在这三篇论文里都提及Google的一个Lock Service -- Chubby,哦,于是我们有了Zookeeper. 随着大数据的火热,Hxx们已经变得耳熟能详,现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼.但实际上对我们这些非大数据开发

微服务架构的设计和实践-培训感悟

这两天(4月8号,9号)我有幸参加了极客邦的培训课程-微服务架构的设计和实践,能够面对面倾听58架构师-孙玄的亲身授课,个人也是感到非常的荣幸.两天的时间,来回于广州和深圳,虽然不能说自己的技术有了一个质的提升,但至少也是一次很好的交流体现,这一趟不白走! 身为一个技术小白(虽然个人也有四年的开发经验,但大多的技术只是知其然而不知其所以然,而且接触面太狭隘),此次学习最明显的感受是,如果你只会写软件代码,了解与某种语言相关的语法,框架以及架构包括技术,那你肯定会"死的很惨".作为软件行

分布式服务框架 Zookeeper -- 管理分布式环境中的数据

安装和配置详解 Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务.状态同步服务.集群管理.分布式应用配置项的管理等.本文将 从使用者角度详细介绍 Zookeeper 的安装和配置文件中各个配置项的意义,以及分析 Zookeeper 的典型的应用场景(配置文件的管理.集群管理.同步锁.Leader 选举.队列管理等),用 Java 实现它们并给出示例代码. 单机模式 单 机安装非常简单,只要获取

分布式服务框架下,如何做到服务化最佳实践?

“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须