当初还是懵懂无知，面试官问我如何实现接口的幂等性，我只能尴尬而不失礼貌的说：“这个我接触的不深”
那天晚上，我打开了我的电脑，怀着百分的敬意，输入了幂等性，点击了搜索。当我打开搜索页面时，我感觉自己受到了冒犯
“接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用”
这不就是重复提交么，嗨，不早说。 我有一大堆解决方案。
歪门邪道版：js点击之后，按钮变灰，不可点击 歪门邪道升级版：js点击之后，按钮不可点击，再给按钮加个倒计时，显得专业不少。那个人直接通过接口访问，不用你的页面。 嗯，这么缺德的么。。。
大巧不工版：祭出重量级选手--数据库，设置唯一字段，每次提交比对版本号，一致就拒绝它这里就涉及到另一个听起来更高端的概念：CAS,比较并替换，如果相同就替换，我们是如果相同就拒绝，是不是有内味了。 数据库的操作也太low了，每次都要比对，你这程序并发一高，必然就崩溃。 好像有点道理啊，别急，我还有杀手锏。
大巧不工升级版：TOKEN，对你想的没错，就是我们平常用的TOKEN，每次请求生成一个唯一值，扔到 session中，一个TOKEN在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。但是，有一句老话说的好，不谈应用场景的技术，都是瞎扯，现在都微服务时代了，每次请求的接口虽然它看起来是一样的，但是提供这个接口的服务可不一定是你上一次点击的服务，我们传统的TOKEN的，局限于一个服务，好像并不能解决不通服务的问题。
这个时候redis出场了，把生成的TOKEN扔到redis中不就可以了么。每次请求的时候把redis的值拿出来比较下，完美。和以前的服务比较下，会发现解决重复提交的思路和方案好像并没有啥变化。
当然还有升升升升级版：使用redis或者其他得第三方服务，整一个分布式锁，要操作得时候，获取锁，操作 完了，释放锁。还记得刚刚说的话吗，不谈应用场景的技术，都是瞎扯，我们来分析下幂等的概念，就会发现，它的重点不是为了防止重复提交，而是为了防止重复提交导致的副作用。
国庆节快到了，你想查下机票，你点了一次查看，网速有点慢，又点了词，这个时候它提示你，请不要重复提交，嗯。。。把这个程序员拖出去祭天。
程序无外乎增删改查，很明显，
查的时候：想查多少次，就查多少次，很显然，它就是自带幂等性的。
删的时候：如果是物理删除，哪应该算是幂等性的吧，毕竟都删除了，其他的删除服务顶多是报报错，抛下异常，小意思了，都是见过世面的程序员，不报几个异常你对的起头上稀少的头发吗？如果是逻辑删除，大家都是修改成指定的值，多修改几次，问题好像也不大。
修改得时候：逻辑删除不就是特殊一点得修改吗，这么一说是不是豁然开朗。但是，修改成一样的值当然没问题了，可是修改成不一样的值，那就有问题了，想一下，你原本想要给这篇文章点个赞的，可是点了好多下。嗯。。。好像也没啥大问题，多赞几下是好事啊！ 可如果换成了付款，今天我想吃豆腐脑，点击付款，心里再想着待会吃甜的还是咸的，不小心点了两次，这个时候你猜，写付款接口的程序员，有没有保证这个接口的幂等性哪？
新增的时候：如果刚刚那个同行，忘了保证幂等性，我给你保证，小目标就真的是小目标了，毕竟我只付了一次钱，可是有这么多记录，我不吃豆腐脑了，找老板退钱，不香吗？
所以说啊，幂等性重点是多次提交带来的危害性，而不是多次提交本身。
