交易订单的重复提交虽然通常不会直接影响现金流和商品流，但依然会给网站运营方带来损害，如消耗系统资源、影响正常用户订单生成、制造恶意用户发起纠纷的机会等。倘若订单对象是虚拟商品，也有可能造成实际损失。订单重复提交的检查工作本应该由网站自身实现，而 iFlow 业务安全加固平台则可以为未实现这项功能的网站提供防护。
不单是互金系统交易时会生产此问题，凡涉及表单提交都会遇到，这里以某互金系统为例说明交易防重的过程设计。下图是交易防重设计的示图：
所谓幂等性设计，就是说，一次和多次请求某一个资源应该具有同样的副作用。用数学的语言来表达就是：f(x) = f(f(x))。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/linzhiqiang0316/article/details/83217451
重复提交看似是一个小儿科的问题，但却存在好几种变种用法。在面试中回答的好，说不定会有意想不到的收获！现把这 8 种解决方案分享给大家！
前几天，说要用curator的读写锁写一个分布式防重复提交的工具包。然后今天作者就探索一下，在上次文章的末尾，作者说当时的这种方式解决不了大量表单使用相同的防重复提交token上送。也就是比如网站的首页要加载很多请求，然后这些请求还都适用相同的token，所以说这些使用相同token的请求只能通过一个。其他都可能被视为重复的表单。但是作者后边想了想感觉这种情况还是比较少。很多时候表单都是单个提交的。所以我们先不考虑那种情况，因为如果考虑那种情况会比较复杂。这里我们还是以单个表单作为示例写一个注解来做这件事情。
在提交后执行页面重定向，这就是所谓的Post-Redirect-Get (PRG)模式。简言之，当用户提交了表单后，你去执行一个客户端的重定向，转到提交成功信息页面。这能避免用户按F5导致的重复提交，而其也不会出现浏览器表单重复提交的警告，也能消除按浏览器前进和后退按导致的同样问题。
在我们编程中常见幂等 1)select查询天然幂等 2)delete删除也是幂等,删除同一个多次效果一样 3)update直接更新某个值的,幂等 4)update更新累加操作的,非幂等 5)insert非幂等操作,每次新增一条
Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。
导读 文章转载自幂等性如何实现？带你了解一波！！！ 现在这个时代大家可能最关心的就是钱了，那么有没有想过你银行转账给你没有一次是转多的，要么失败，要么成功，为什么不能失误一下多转一笔呢？醒醒吧年轻人，别做梦了，做银行的能那么傻x吗？ 今天我们就来谈一谈为什么银行转账不能多给我转一笔？关乎到钱的问题，小伙伴们打起精神！！！ 要想要理解上述的疑惑，不得不提的一个概念就是幂等性，至于什么是幂等性，如何通过代码实现幂等性，下面将会详细讲述。 什么是幂等性 所谓幂等性通俗的将就是一次请求和多次请求同一个资源产生相同
还记得上次的文章提到技术经理离职了，目前为止，我在代理技术经理的工作，包括评审，周会等，最头疼的是要面对老板开周会，自己一个人面对需求的评审，技术设计，发版，解决方案，线上问题排查，疑难问题解决方案设计，这让我应接不暇。
在业务上有很多需要防止重复提交的场景，例如大部分的创建方法要求同样的数据不能创建两次。对于此种业务处理一般可以分为前端处理和后端处理。前端可以在点击后将按钮置灰1s，做防抖处理，1s后才可以再次调用接口。后端这里需要在业务上做处理，我们在做入库操作时，需要校验：
对于防止重复提交，最简单也最不安全的做法相信大家也都经历过，前端在一个请求发送后立即禁用掉按钮，这里咱们来讨论一下后端对防止重复提交的处理方式。 主要针对非分布式环境下防止重复提交与分布式环境下的防止重复提交。一般分布式环境下也可以通过网关路由的方式将同一个用户的请求路由到一个实例上处理。
上一篇文章中我们大概了解了Curator做读写锁的原理和过程。根据了解，我们可以使用curator的读写锁来做一个分布式防重复提交的策略。为什么采用curator来做这个事情的原因是curator提供的读写锁能够跨线程和jvm进行加锁。如果不加锁，那么因为网络抖动或者线程切换，谁都不知道防重复提交的token标志是否被其他请求修改。因此这块必然要采用加锁的方式。通过锁的创建和删除来保持多个重复请求的有序性，在保证有序性之后，我们就可以按照逻辑对token进行修改，这样其他线程就能够判断自身是否为重复请求。除此之外，在加锁的时候我们采用临时znode，在会话结束之后就可以自动销毁。因此可以避免zk服务端被累计打满的情况。当然这块的会话时间是可以根据业务需求设置的。对于放重复提交的一般规则来说，我无非就是将session提取出来，而session则是和用户绑定的，因此这块我们将userId作为放重复提交的判断标志，将token表示该用户下次提交的表单的有效token，因此同一时刻，只允许同一用户提交一个表单，否则就会因为抢占token，而导致后一表单提交被认定为重复的提交（这块需要优化，下一个版本再优化！）。
说来惭愧，前几天做项目的时候，出现个低级错误。在公司后台做表单提交，一是自己员工用，二是 html 自己来写的，没有验证表单重复提交，结果出错了。写出来记录下以便提醒自己，时刻不能疏忽。
今天本来应该学习netty基础传输的相关内容，但是由于对基础知识掌握的不足，出现学习的瓶颈，先学习一下幂等性压压惊，晚上再梳理一下netty的相关内容，认认真真学习，争取明晚可以完成netty基础传输相关内容，今晚就看一下幂等性吧！
幂等性原本是数学上的概念，用在接口上就可以理解为：同一个接口，多次发出同一个请求，必须保证操作只执行一次。调用接口发生异常并且重复尝试时，总是会造成系统所无法承受的损失，所以必须阻止这种现象的发生。
接口幂等性通常指对于相同的请求，无论调用多少次，最终的结果都应该是一致的。在Spring Boot中实现接口幂等性可以采取以下几种方案：
作为一个软件开发者，绝不能奢望你的用户会规规矩矩地使用你的软件，他们一般都是缺乏耐心，“胡作非为”的。比如当他点击提交表单时，服务器处理比较慢， 页面上没有任何反应，他会迫不及待地再点击几次，这样就会产生重复数据或者报错，或者他会刷新一下再次提交。所以，你必须保证你的软件足够地健壮，尽可能地考虑各种用例，增加限制，抵御使用者的摧残。 对于如何处理重复提交，一般教科书上都有点明，不外乎是在js代码中增加限制或者通过session来处理。关于js代码限制，就是当用户第一次提交后，将提交按钮设置为“disable
博主负责的项目报了一个问题，用户操作回退失效。我们的设计里，操作回退是回到操作前的状态。经过查看日志发现，用户之前的操作做了两次，也就是说提交操作的接口被调用了两次，导致之用户上一次的状态和这一次的状态是一样的，所以操作回退是没有问题的，问题出在了操作的接口被调用了两次。
应用情景 经典使用情景：js的一些事件，比如：onresize、scroll、mousemove、mousehover等； 还比如：手抖、手误、服务器没有响应之前的重复点击； 这些都是没有意义的，重复的无效的操作，设置对整个系统的影响还可能是致命的，所以我们要对重复点击的事件进行相应的处理！ 节流函数 所谓的节流函数顾名思义，就是某个时刻限制函数的重复调用。 同样节流函数也是为了解决函数重复提交的问题，而防止重复提交的方法，不止节流函数一种实现。 方法汇总 本文整理了我在工作实践当中，觉的防止js重复提交，
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
百度MIP数据提交工具推送 V1.3 增加判断重复提交问题 增加校验通过后推送 V1.2 增加sitemap地图方式，筛选URL 增加接口地址记录功能 V1.1 修改为将TXT拖入软件,判断URL V1.0 简单的mip数据提交功能 功能说明 自动记录推送成功数据，以免重复推送 保存MIP接口信息，减少每次输入 支持sitemap XML 地图数据方式 推送时自动校验是否符合MIP规则 MIP数据提交
摘要 幂等概念来自数学，表示N次变换和1次变换的结果是相同的。这里讨论在某些场景下，客户端在调用服务没有达到预期结果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数。
又是一个风和日丽美好的一天，小猫戴着耳机，安逸地听着音乐，撸着代码，这种没有会议的日子真的是巴适得板。
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。例如：
一、背景 我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如： 1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。 2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱； 3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的； 4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。 等等很多重要的情况，这些逻辑都需要幂等的特性来支持。 二、幂等性概念 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 我的理解：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的 三、技术方案 1. 查询操作 查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作 2. 删除操作 删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个) 3.唯一索引，防止新增脏数据 比如：支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录 要点： 唯一索引或唯一组合索引来防止新增数据存在脏数据 （当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可） 4. token机制，防止页面重复提交 业务要求： 页面的数据只能被点击提交一次 发生原因： 由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交 解决办法： 集群环境：采用token加redis（redis单线程的，处理需要排队） 单JVM环境：采用token加redis或token加jvm内存 处理流程： 1. 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间 2. 提交后后台校验token，同时删除token，生成新的token返回 token特点： 要申请，一次有效性，可以限流 注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用 5. 悲观锁 获取数据的时候加锁获取 select * from table_xxx where id='xxx' for update; 注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的 悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用 6. 乐观锁 乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。 乐观锁的实现方式多种多样可以通过version或者其他状态条件： 1. 通过版本号实现 update table_xxx set name=#name#,version=version+1 where version=#version# 如下图(来自网上)：
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如：
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。 ---- 在上周发布的 TienChin 项目视频中，我和大家一共梳理了六种幂等性解决方案，接口幂等性处理算是一个非常常见的需求了，我们在很多项目中其实都会遇到。今天我们来看看两种比较简单的实现思路。 1. 接口幂等性实现方案梳理 其实接口幂等性的实现方案还是蛮多的，我这里和小伙伴们
在提交后执行页面重定向，这就是所谓的Post-Redirect-Get (PRG)模式。
表单提交时候我们应该控制提交按钮，不能点击多次进行数据的重复提交。要不然就会有冗余的重复的数据在系统中，造成系统出现数据垃圾。jQuery很简单的就可以实现对表单提交按钮控制，下面就是相关的例子和代码。
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如： 1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。 2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱； 3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的； 4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。 等等很多重要的情况，这些逻辑都需要幂等的特性来支持。 二、幂等性概念 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 我的理解：幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的 三、技术方案 1. 查询操作 查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作 2. 删除操作 删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个) 3.唯一索引，防止新增脏数据 比如：支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录 要点： 唯一索引或唯一组合索引来防止新增数据存在脏数据 （当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可） 4. token机制，防止页面重复提交 业务要求： 页面的数据只能被点击提交一次 发生原因： 由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交 解决办法： 集群环境：采用token加redis（redis单线程的，处理需要排队） 单JVM环境：采用token加redis或token加jvm内存 处理流程： 1. 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间 2. 提交后后台校验token，同时删除token，生成新的token返回 token特点： 要申请，一次有效性，可以限流 注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用 5. 悲观锁 获取数据的时候加锁获取 select * from table_xxx where id='xxx' for update; 注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的 悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用 6. 乐观锁 乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。 乐观锁的实现方式多种多样可以通过version或者其他状态条件： 1. 通过版本号实现 update table_xxx set name=#name#,version=version+1 where version=#version# 如下图(来自网上)：
* 实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。 例如： 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果。 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱； 发送消息，也应该只发一次，同样的短信发给用户，用户会崩溃； 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题。 等等很多重要的情况，这些逻辑都需要幂等的特性来支持。 下面说说幂等性概念： 幂等（idempotent、idemp
我们实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。例如1. 前端重复提交选中的数据，应该后台只产生对应这个数据的一个反应结果；2. 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱；3. 发送消息，也应该只发一次，同样的短信发给用户，用户会哭的；4. 创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题等等很多重要的情况都需要幂等的特性来支持。
2 . 我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统bug重发，也应该只扣一次钱；
正确传递请求头 - 键：Content-Type 值：application/json
前后端分离的开发方式，我们以接口为标准来进行推动，定义好接口，各自开发自己的功能，最后进行联调整合。无论是开发原生的APP还是webapp还是PC端的软件,只要是前后端分离的模式，就避免不了调用后端提供的接口来进行业务交互。
说明：Java生鲜电商平台-生鲜电商高并发下的接口幂等性实现与代码讲解，实际系统中有很多操作，是不管做多少次，都应该产生一样的效果或返回一样的结果。例如：
公司测试提了一个项目后台在IE浏览器下（360，firefox就没问题）出现数据重复的问题，调试了好久终于发现问题所在，也不知道是谁写的代码，醉醉的。。。。
属性配置 在 application.properites 资源文件中添加 redis 相关的配置项
前言 今天去了一家国内领先的可视化智能硬件公司面试。面试的我是技术总监。为人和蔼，和他交谈中，我还有一股紧张。面试中，能感觉他功力深厚，同时也学到了很多东西。个人感觉，我对自己的面试结果不是很满意。技术总监问的问题比较深入，也是我平时比较疏忽的知识点。 ---- 关于Int类型的理解 面试官问我int类型占几个字节。我是这样说的: "占4个字节，在内存中占32位。可能不同的操作系统占的字节不一样。" 我真的是强行装逼，给自己挖坑。面试官说："为什么不一样"。 然后我说："我记得博客上面是这样说的。"
表单提交时需要校验数据是否已存在，如果已存在需要防止重复提交，做法比较简单，不再赘述。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
