幂等性的概念用户同一操作请求了一次或者多次，最终的结果应该是一致的，并不会因为多次请求产生副作用；幂等操作的特点是“多次执行所产生的结果与一次执行的结果相同”。比如：

付款操作的时候，请求已经发送给服务端，但是由于网络原因未收到付款结果（实际上已成功），再次操作付款的时候，不应该成功；

在页面做新建操作的时候，手抖连点了新增按钮，那么应该只会创建出一条数据；

查询和删除查询和删除操作，天然具有幂等性；也就是多次执行查询或删除操作的时候，结果和执行一次查询或删除的结果是一样的。

但是要注意，多次执行删除的返回内容可能不同，比如第一次删除成功，后面再执行删除的话，会显示数据不存在。

保证幂等性的方案新增和修改，如果不做幂等性处理，可能就会产生问题（如果修改只是把某些字段更新成固定的值，不会有幂等性问题，但是如果新值要在旧值上做处理做计算，如增加多少、减少多少，那么多次执行的结果就会有差异）；那么保证幂等性有哪些方案呢？（给出我知道的方案，方案有好有坏）

悲观锁：获取数据的时候加锁获取；select * from table where col='xxx' for update; 只能说是一种实现方案，但是不是特别好；

乐观锁：在更新数据那一刻锁表，可以通过条件限制，也可以通过版本号来实现，比如：数据中增加版本号的概念，那么在做数据修改，把当前数据的版本号带上，修改的时候要按照版本号判断数据是否发生过更改。如果没有发生过更改，则执行业务操作，并更新版本号。

分布式锁：在业务系统执行插入或更新操作的时候，先要获取分布式锁，然后做操作，之后释放锁；分布式锁保证在一个时间内，只会有一个线程对数据进行操作；

全局唯一请求ID：每一次的请求，都带有一个全局唯一的请求ID，这个请求ID只要执行过一次就失效了：

状态幂等：如果业务流程中的每个阶段，数据都有不同的状态，那么当数据已经处于下一个状态的时候，这时候又来了上一个状态的变更，是不会执行成功的（其实有些类似于版本号的概念，不过这个状态是有业务含义的）。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。