现在这个时代大家可能最关心的就是钱了，那么有没有想过你银行转账给你没有一次是转多的，要么失败，要么成功，为什么不能失误一下多转一笔呢？醒醒吧年轻人，别做梦了，做银行的能那么傻x吗？
今天我们就来谈一谈为什么银行转账不能多给我转一笔？关乎到钱的问题，小伙伴们打起精神！！！
要想要理解上述的疑惑，不得不提的一个概念就是幂等性，至于什么是幂等性，如何通过代码实现幂等性，下面将会详细讲述。
什么是幂等性
所谓幂等性通俗的将就是一次请求和多次请求同一个资源产生相同的副作用。用数学语言表达就是f(x)=f(f(x))。
维基百科的幂等性定义如下：
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。
幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的，更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
为什么需要幂等性
在系统高并发的环境下，很有可能因为网络，阻塞等等问题导致客户端或者调用方并不能及时的收到服务端的反馈甚至是调用超时的问题。总之，就是请求方调用了你的服务，但是没有收到任何的信息，完全懵逼的状态。比如订单的问题，可能会遇到如下的几个问题：
1. 创建订单时，第一次调用服务超时，再次调用是否产生两笔订单？
2. 订单创建成功去减库存时，第一次减库存超时，是否会多扣一次？
3. 订单支付时，服务端扣钱成功，但是接口反馈超时，此时再次调用支付，是否会多扣一笔呢？
作为消费者，前两种能接受，第三种情况就MMP了，哈哈哈！！！这种情况一般有如下两种解决方式：
1. 服务方提供一个查询操作是否成功的api，第一次超时之后，调用方调用查询接口，如果查到了就走成功的流程，失败了就走失败的流程。
2. 另一种就是服务方需要使用幂等的方式保证一次和多次的请求结果一致。
HTTP的幂等性
GET：只是获取资源，对资源本身没有任何副作用，天然的幂等性。
HEAD：本质上和GET一样，获取头信息，主要是探活的作用，具有幂等性。
OPTIONS：获取当前URL所支持的方法，因此也是具有幂等性的。
DELETE：用于删除资源，有副作用，但是它应该满足幂等性，比如根据id删除某一个资源，调用方可以调用N次而不用担心引起的错误（根据业务需求而变）。
PUT：用于更新资源，有副作用，但是它应该满足幂等性，比如根据id更新数据，调用多次和N次的作用是相同的（根据业务需求而变）。
POST：用于添加资源，多次提交很可能产生副作用，比如订单提交，多次提交很可能产生多笔订单。
幂等性的实现方式
对于客户端交互的接口，可以在前端拦截一部分，例如防止表单重复提交，按钮置灰，隐藏，不可点击等方式。但是前端进行拦截器显然是针对普通用户，懂点技术的都可以模拟请求调用接口，所以后端幂等性很重要。
后端的幂等性如何实现？将会从以下几个方面介绍。
1. 数据库去重表
在往数据库中插入数据的时候，利用数据库唯一索引特性，保证数据唯一。比如订单的流水号，也可以是多个字段的组合。
实现比较简单，读者可以自己实现看看，这里不再提供demo了。
2. 状态机
很多业务中多有多个状态，比如订单的状态有提交、待支付、已支付、取消、退款等等状态。后端可以根据不同的状态去保证幂等性，比如在退款的时候，一定要保证这笔订单是已支付的状态。
业务中常常出现，读者可以自己实现看看，不再提供demo。
3. TOKEN机制
针对客户端连续点击或者调用方的超时重试等情况，例如提交订单，此种操作就可以用Token的机制实现防止重复提交。
TOKEN机制如何实现？简单的说就是调用方在调用接口的时候先向后端请求一个全局ID（TOKEN），请求的时候携带这个全局ID一起请求，后端需要对这个全局ID校验来保证幂等操作，流程如下图：
主要的流程步骤如下：
1. 客户端先发送获取token的请求，服务端会生成一个全局唯一的ID保存在redis中，同时把这个ID返回给客户端。
2. 客户端调用业务请求的时候必须携带这个token，一般放在请求头上。
3. 服务端会校验这个Token，如果校验成功，则执行业务。
4. 如果校验失败，则表示重复操作，直接返回指定的结果给客户端。
通过以上的流程分析，唯一的重点就是这个全局唯一ID如何生成，在分布式服务中往往都会有一个生成全局ID的服务来保证ID的唯一性，但是工程量和实现难度比较大，UUID的数据量相对有些大，此处陈某选择的是雪花算法生成全局唯一ID
