网站建设都有什么技术支持黑帽seo365t技术

1、什么是幂等性

幂等（idempotence），这个词源自数学，幂等性是数学中的一个概念，常见于抽象代数中。表达的是N次变换与1次变换的结果相同。简单来说，就是如果方法调用一次和调用多次产生的效果是相同的，它就具有幂等性。幂等函数或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数，这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

1.1 HTTP维度

HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的响应。

1.1.1 GET方法

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的，具备幂等性。比如：GET https://www.wkcto.com/course/100方法不会改变资源的状态，不论调用1次还是N次都没有副作用。需要注意的是，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。

1.1.2 DELETE方法

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等，具备幂等性。比如：DELETE https://www.wkcto.com/article/detail/10，调用一次和N次对系统产生的副作用是相同的，即删除id为10的帖子，因此调用者可以多次调用或刷新页面而不必担心引起错误。

1.1.3 POST方法

HTTP POST所对应的URI为资源的接收者，不具备幂等性。比如：POST https://www.wkcto.com/article的语义是发表一篇文章，两次相同的POST请求会在服务器端创建两份相同的资源，所以POST方法不具备幂等性。

1.1.4 PUT方法

HTTP PUT所对应的URI是要创建或更新的资源，具备幂等性。比如PUT https://www.wkcto.com/article/5321的语义是创建或更新ID为5321的文章，对同一URI进行多次PUT和一次PUT的结果是相同的，因此PUT方法具备幂等性。

2、产生幂等性问题的场景

幂等性问题在分布式、微服务架构中随处可见：

1. 因网络波动，可能会引起重复请求；
2. 用户重复操作，在使用产品时可能会无意地触发多次下单多次交易，甚至没有响应而有意触发多笔交易；
3. 应用使用了失败或超时重试机制（如Nginx重试、RPC重试或业务层重试等）
4. 第三方平台的接口（如支付成功回调接口），因为异常导致多次异步回调；
5. 中间件/应用服务根据自身特性，也有可能进行重试；
6. 用户双击提交按钮；
7. 页面重复刷新；
8. 使用浏览器后退按钮重复之前的操作，导致重复提交表单；

3、幂等在哪一层实现

DAO

4、如何保证幂等性

4.1 前端实现（不可靠）

4.1.1 按钮只可操作一次

一般是提交后把按钮置灰或loading状态，可以使用一些js组件来实现，消除用户因为重复点击而产生的副作用，比如添加操作，由于点击两次而产生两条记录。

4.1.2 Token机制

进入页面时申请一个token，分别存储在session和表单隐藏域中，提交表单时，判断表单中的token与session中的token是否都存在且一致，如果存在且一致，说明是第一次提交，清除session里的token，继续操作，否则说明非正常操作。

4.1.3 使用Post/Redirect/Get模式

所谓Post/Redirect/Get（PRG）模式，就是在提交后执行页面重定向。简单来说，当用户提交了表单后，执行一个客户端的重定向，转到提交成功信息页面，这样即避免了用户刷新页面导致重复提交，也能消除按前进和后退导致的重复提交的问题。

缺点：

• 由于服务器响应缓慢，用户刷新提交POST请求造成的重复提交。
• 用户恶意避开客户端预防多次提交手段，进行重复数据提交。

4.2 后端实现

4.2.1 使用唯一索引防止新增脏数据

当数据重复时，插入数据库会抛出异常，以此来保证不会出现脏数据，这是一种简单粗暴的方法。

4.2.2 Token + Redis的幂等方案

分为两个阶段：申请token阶段和业务操作阶段。以支付为例：

• 第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到redis缓存中，为第二阶段作准备；
• 第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查redis中是否存在该token，如果存在，表示第一次发起的支付请求，开始支付逻辑处理，处理完逻辑后删除redis中token。

当重复请求的时候，检查到缓存中的token不存在，表示非法请求。

该方案的不足之处在于需要与系统交互两次。

4.2.3 状态机幂等

针对更新操作，比如业务上需要修改订单状态，订单有待支付、支付中、支付成功、支付失败、订单超时关闭等状态，在设计的时候最好只支持状态的单向改变（不可逆），这样在更新的时候where条件里可以加上status=期望的原来的status，多次调用的话实际上也只会执行一次。

4.2.4 乐观锁实现幂等

如果更新已有数据，可以进行加锁更新，也可以设计表结构时使用乐观锁，通过version做乐观锁，这样即能保证执行效率，又能保证幂等。乐观锁的version版本在更新业务数据时要自增。

以版本号为乐观锁：

1. 查询数据，得到版本号，version = 1；
2. 通过版本号更新，版本号匹配就更新，否则不能更新 UPDATE T_ACCOUNT SET MONEY = MONEY - #money#, VERSION = VERSION + 1 WHERE ID = #id# AND VERSION = 1。

也可以采用update with condition，更新带条件，实现乐观锁，通过version或者其他条件来实现乐观锁。

4.2.5 防重表实现幂等性

新建一张防重表（防止数据重复的表）。使用唯一主键做防重表的唯一索引，比如订单号orderNo，每次请求都根据订单号向防重表中插入一条数据，第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，支付前先向防重表中插入该订单的订单号，插入成功说明可以支付，执行完更新订单状态。后续订单因为表中唯一索引而插入失败，直到第一次的请求操作完成，删除防重表中的数据。可以看出，防重表的作用就是加锁。

这种方案其实也是一种分布式锁的实现方式，与4.2.7的redis和zookeeper实现分布式锁相呼应。

4.2.6 SELECT + INSERT实现幂等性

简单来说，就是插入之前先查询，符合要求再插入。该方案在没有并发的系统中可以解决幂等问题，在单JVM有并发的时候可以通过JVM加锁来保证幂等性，在分布式环境下是无法使用的。

4.2.7 分布式锁实现幂等性

在进入方法时，先去获锁，如果获取到了，就继续后面的流程。如果没有，就等待锁的释放。当执行完方法后，释放锁，当然，锁要设个超时时间，防止意外没有释放到锁。它可以用来解决分布式系统的幂等性。

使用分布式锁类似于防重表，思路相同，都是同一时间只能完成一次支付请求。只是将防重并发放到了缓存中，较为高效。

常用的分布式锁的实现方案是redis和zookeeper等工具。

4.2.8 缓冲队列实现幂等性

将请求快速地接收下来，放入缓冲队列，后续使用异步任务处理队列中的数据，过滤掉重复的请求，此方案的优点是改同步为异步，提高吞量；缺点是不能及时地返回请求结果，需要后续轮询处理结果。

4.2.9 全局唯一号实现幂等性

比如通过source来源 + seq序列号来判断请求是否重复，在并发时只能处理一个请求，其它相同并发请求要么返回请求重复，要么等待前面请求执行完成再执行。