面试官:幂等性的接口该如何设计? 幂等性设计 今天我们来聊聊接口的幂等性设计,所谓幂等,就是任意多次执行所产生的影响均与一次执行的影响相同。 幂等性接口是指可以使用相同参数重复执行,并能获得相同结果的接口。这里就不展开数学中的定义了,有兴趣的可以自行google。 为什么接口需要幂等呢? 我们都知道,作为接口的调用方,对于接口调用的结果,一般会返回成功、失败和超时。对于成功和失败,都是明确的状态,调用放可以根据结果做相应的处理,但是对于超时,由于不确定是否成功请求了,作为调用方来说,所以一般都会选择重试。而重试就会出现定义中描述的多次执行。 可以从下面这个例子中加深一下理解:创建订单时,需要减库存,如果减库存接口超时了,调用方重新调用一次(无论是否成功的执行了减库存代码),应该要保证不会多减一次库存。 要保证不会多件一次库存,一般有两种做法:接口提供方需要提供相应的查询接口。调用方在超时后去查询一下是否成功。是否多扣一次库存掌握在调用方手里。如果接口是提供给第三方使用的,就会存在一定的风险。接口支持幂等。这样幂等的保证完全掌握在提供方自己手里,完全不用担心。 全局ID 要让接口支持幂等,要怎么做呢,你可能会想到在减库存之前增加一次查询,已经减过的直接返回不就完事了么?这样确实能达到目的,可是会额外多了一次查询,有没有什么更优的方法呢? 要保证减库存操作的唯一性,可以在接口上多加一个参数,这个参数必须全局唯一,数据库设计表的时候这个字段要加上唯一索引,当多次保存相同数据的时候,数据库就会报错,这就证明了接口已经成功调用过,可以直接返回。 那这个全局ID由谁来分配呢? 1.可以创建一个分配中心,由中心统一分配。 优点:分配ID与业务集群解耦。 缺点:需要单独维护分配中心,这个分配中心也必须做成高可用集群,增加维护成本。 2.集成在业务服务集群。 优点:业务服务集群本来就是高可用的,无需提供额外保证。 缺点:分配ID与业务耦合(这其实没什么影响),需要保证业务服务集群生成ID的唯一性。 一般来说,后者是比较好的方案,我们只要提供一个能在集群上生成全局唯一ID的算法即可。 除了保证全局唯一,最好具备以下特点(非必须):递增,起码保证每台机器上的ID递增。(保证数据库性能)明确的规则,ID的各个位都有具体的定义。(方便追溯) 接下来就来说说现阶段常用的全局ID算法。 UUID UUID设计的目的就是让分布式系统中的所有素,都能有唯一的辨识信息,而不需要通过中央控制端来做辨识信息的指定。关于UUID的设计原理可自行Google。 优点:实现简单(大多数编程语言都集成到工具库了),本地生成,性能好,扩展性高,不需要协定。 缺点:无法递增(消耗数据库性能)、UUID过长(消耗存储空间)。 在中小型项目中,UUID会是不错的选择。为什么这么说呢?面对并发度不高的系统,数据库性能一般不会达到瓶颈,所以说UUID是牺牲数据库性能换取其优点的一种选择。 Snowflake Snowflake是Twitter 的开源项目,它生成的ID是64bit的正整数,结构如图: 


2024最新激活全家桶教程,稳定运行到2099年,请移步至置顶文章:https://sigusoft.com/99576.html
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处:https://sigusoft.com/52564.html