面试题：接口幂等性是甚么？如何设计？

amnesia

接口幂等-幂等性-接口的幂等性-散布式幂等性-如何包管幂等-幂等性完成计划-去重表-下单幂等-领取幂等-扣还库存幂等
甚么是接口幂等？
在计算机中编程中，一个幂等操作的特征是其恣意屡次履行所发生的影响均与第一次履行的影响相反。
接口的幂等性实际上就是接口可反复调用，在调用方屡次调用的状况下，接口终究失掉的后果是统一的。有些接口能够自然的完成幂等性，好比查问接口，关于查问来讲，你查问一次和两次，关于零碎来讲，没有任何影响，查出的后果也是同样。
为何接口需求幂等性设计
该问题同等于 为何会反复调用？
前端反复提交表单
在填写一些表格时分，用户填写实现提交，得多时分会因网络颠簸没有及时对用户做出提交胜利响应，导致用户以为没有胜利提交，而后始终点提交按钮，这时候就会产生反复提交表单申请。
黑客歹意攻打
例如在完成用户投票这类功用时，假如黑客针对一个用户进行反复提交投票，这样会致使接口接纳到用户反复提交的投票信息，这样会使投票后果与事实重大不符。
接口超时反复提交
大部份RPC框架[好比Dubbo]，为了避免网络颠簸超时等酿成的申请失败，都会添减轻试机制，致使一个申请提交屡次。
动静反复消费
当使用 MQ 动静两头件时分，假如Consumer消费超时或者producer发送了动静但因为网络缘故未收到ACK致使动静重发，都会致使反复消费。
哪些接口需求幂等？
幂等性的完成与判别需求损耗一定的资源，因此不该该给每个接口都减少幂等性判别，要按照实际的业务状况和操作类型来进行区别。例如，咱们在进行查问操作和删除操作时就无须进行幂等性判别。
查问操作查一次和查屡次的后果都是统一的，因此咱们无须进行幂等性判别。删除操作也是同样，删除一次和删除屡次都是把相干的数据进行删除（这里的删除指的是前提删除而不是删除一切数据），因此也无须进行幂等性判别。
所以究竟哪些接口需求幂等？对于这个问题需求从详细业务登程，然而也有法则可循如下表：



如何完成幂等 前端阻拦
前端阻拦是指经过 Web 站点的页面进行申请阻拦，好比在用户点击完“提交”按钮后，咱们能够把按钮设置为不成用或者暗藏形态，防止用户反复点击。
该办法能够解决用户误操作提交两次表单所发生的反复提交问题。但前端阻拦有一个致命的问题，假如是懂行的顺序员或者黑客能够间接绕过页面的 JS 履行，间接摹拟申请后真个接口，这样的话，咱们前真个这些阻拦就不克不及失效了。因此除了前端阻拦一部份正常的误操作以外，后真个验证必不成少。
数据库独一索引完成
数据库独一索引完成计划个别只能合用于履行拔出曾经操作的进程。



详细流程步骤：
建设一张去重表，其中某个字段需求建设独一索引客户端去申请办事端，办事端会将这次申请的一些信息拔出曾经这张去重表中由于表中某个字段带有独一索引，假如拔出曾经胜利，证实表中没有这次申请的信息，则履行后续的业务逻辑假如拔出曾经失败，则代表曾经履行过以后申请，间接前往数据库乐观锁完成数据库乐观锁计划个别只能合用于履行更新操作的进程，咱们能够提前在对应的数据表中多添加一个字段，充任以后数据的版本标识。
这样每次对该数据库该表的这条数据履行更新时，都会将该版本标识作为一个前提，值为上次待更新数据中的版本标识的值。
详细流程步骤：
客户端带着version字段申请办事端办事端履行update的时分需求给version+1，而且需求加version的更新前提如下SQLupdate t set stock = stock - 1 , version = version + 1 where id = #{id} and version = #{version} 数据库灰心锁完成


详细流程步骤：
客户端经过业务id，拜候办事端先查数据库是不是存在该业务id，查库的时分需求加X锁假如存在则阐明是反复申请，不存在则进行业务逻辑处置JVM锁完成JVM 锁完成是指经过 JVM 提供的内置锁如 Lock 或者是 synchronized 来完成幂等性。使用 JVM 锁来完成幂等性的个别流程为：首先经过 Lock 对代码段进行加锁操作，而后再判别此定单是不是曾经被处置过，假如未处置则开启事务履行定单处置，处置实现之后提交事务并释放锁，履行流程如下图所示：



JVM 锁存在的最大问题在于，它只能运用于单机环境，由于 Lock 自身为单机锁，所以它就不顺应于散布式多机环境。
散布式锁完成
散布式锁完成解决JVM锁完成单机锁局限问题。



详细流程步骤：
客户端先申请办事端，会拿到一个能代表这次申请业务的独一字段将该字段以 SETNX 的形式存入 redis 中，并按照业务设置相应的超不时间假如设置胜利，证实这是第一次申请，则履行后续的业务逻辑假如设置失败，则代表曾经履行过以后申请，间接前往Token完成


详细流程步骤：
客户端会先发送一个申请去获得 token，办事端会生成一个全局独一的 ID 作为 token 保留在 redis 中，同时把这个 ID 前往给客户端客户端第二次调用业务申请的时分必需携带这个 token办事端会校验这个 token，假如校验胜利，则履行业务，并删除 redis 中的 token假如校验失败，阐明 redis 中曾经没有对应的 token，则表现反复操作，间接前往指定的后果给客户端留意：
对 redis 中是不是存在 token 以及删除的代码逻辑倡议用 Lua 脚本完成，包管原子性全局独一 ID 能够用百度的 uid-generator、美团的 Leaf 去生成总结 幂等性非但能够包管顺序正常履行，还能够根绝一些渣滓数据以及有效申请对零碎资源的损耗。保举使用散布式锁来完成，这样的解决计划更为通用。
原文链接：http://mp.weixin.qq.com/s/xU1gvO4fPyLp5uWqWX50SQ