点击上方"云时代架构", 右上角选择“设为星标”
精品技术文章准时送上！
为什么需要保证幂等性
编程中的“幂等性”是指任意多次执行所产生的影响，与一次执行的影响相同。一个拥有幂等性设计的接口，保证无论一次或多次来调用接口，都能够得到相同的结果。接口的幂等性设计在某些场景下是必需的，例如用户下单的场景。 我们知道，服务之间的调用存在三种状态：成功、失败、超时。超时是一种未知的状态：被调服务是否执行成功，这个状态是未知的。上游服务调用下游服务超时时可能会进行重试。对于用户下单的场景的超时重试我们考虑以下问题： 是否会导致最终创建了两条一样的订单？ 是否会扣除两遍库存？ 是否会重复扣除用户的钱？
如果每一笔订单都携带唯一的序号，下单接口可以借助这个序号，来记录某次下单操作的状态。当下单的状态为成功时，就将重复的执行拦截住，避免出现上述的问题。这种方式是由下游被调方来保证幂等性。 除此之外，订单服务也可以提供查询订单状态的接口，上游在下单之前先进行查询，确认该笔订单并没有成功支付后，再重复进行下单操作。 一般来说，服务本身需要自己保证幂等性，而不应该将幂等性交给上游的调用方来做。 唯一ID
就上面的幂等性下单接口来说，要做到幂等性，就需要借助一个唯一的ID来标志每次交易。唯一ID的分配可以有几种方式：
由一个统一的ID分配中心来分配。
由上游服务来生成唯一ID，但必须保证不产生冲突的ID。
采用统一的分配中心来分配唯一ID时，业务方每次调用接口都多了一次调用分配中心获取唯一ID的请求。这多了额外的开销。
获取唯一ID有一种方式，是借助mysql的自增索引，这其实也是一个ID分配中心。对服务性能有苛刻要求时，可以采用第二种方式，由主调服务本身来生成这个唯一ID。关注公众号互联网架构师可以获取MySQL系列教程。
为了保持不会产生重复的ID，可以使用一下几种ID生成方法：
UUID
UUID的全称是Universally Unique Identifier，通用唯一识别码。
具体可以看维基百科的介绍：https://en.wikipedia.org/wiki/Universally_unique_identifier
UUID是一个128bit的数字，用于标志计算机的信息，虽然UUID不能保证绝对不重复，但重复的概率小到可以被忽略。UUID的生成没有什么规律，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。这也就意味着：
128bit，占据了太多的内存空间
生成的ID不是人可以看懂的
无法保证ID的递增，某些场景需要按前后排序 无法满足。
这是一个在线生成UUID的网站：https://www.uuidgenerator.net/ 你可以直观感受一下UUID。
Snowflake
这是Twitter的一个开源项目，它是一个分布式ID的生成算法，它会产生一个long类型的唯一ID，其核心算法是：
时间部分：41bit作为毫秒数，大概可以使用69.7年
机器编号部分：10bit作为机器编号，支持1024个机器实例。
毫秒内的序列号：12bit，一毫米可以生成4096个序列号
网上有各种语言实现的Snowflake算法的实现，有兴趣的阅读一下实现代码。
实际上，redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小异。这是基于redis的分布式ID生成器实现：https://github.com/hengyunabc/redis-id-generator
它的核心思想是：
使用41 bit来存放时间，精确到毫秒，可以使用41年。
使用12 bit来存放逻辑分片ID，最大分片ID是4095
使用10 bit来存放自增长ID，意味着每个节点，每毫秒最多可以生成1024个ID
共享存储
如果我们的幂等性服务是分布式的，那么存储唯一ID也需要采用共享的存储，这样每个服务就是无状态的了。 可以使用mysql来存储，也可以使用k-v存储例如redis。我在自己的业务中就采用了redis来存储唯一key。 避免不必要的查询
并不是所有的请求都是重复的，生产环境下可能99%的请求都不是重复请求。如果每个请求在执行前都要去查询下唯一ID是否存在，可能会带来不必要的性能消耗。 如果你使用mysql来存储唯一ID，那么可以直接进行insert，通过结果来判断是否插入记录成功，如果不成功则证明ID已经存在： insert into ... values ... on DUPLICATE KEY UPDATE ...
而如果使用的是redis，也可以使用redis的setEx，设置成功则证明key不存在，否则key存在说明是重复请求。
来源:https://www.cnblogs.com/QG-whz/
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
SpringBoot框架开发的优秀的项目「值得收藏学习」 实战篇：一个核心系统 3 万多行代码的重构之旅 1.4 w字，25 张图让你彻底掌握分布式事务原理 一个JDK线程池BUG引发的GC机制思考 TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？ Spring Boot 骚操作 —— 多数据源 Service 层封装（MySQL + MongoDB + ES） ES性能优化实战，几十亿数据查询 3 秒返回！
做互联网时代适合的架构：开放、分享、协作
长按二维码即可关注我们
求在看|求转发
点击上方"云时代架构", 右上角选择“设为星标”
精品技术文章准时送上！
为什么需要保证幂等性
是否会导致最终创建了两条一样的订单？ 是否会扣除两遍库存？ 是否会重复扣除用户的钱？
唯一ID
就上面的幂等性下单接口来说，要做到幂等性，就需要借助一个唯一的ID来标志每次交易。唯一ID的分配可以有几种方式：
由一个统一的ID分配中心来分配。
由上游服务来生成唯一ID，但必须保证不产生冲突的ID。
采用统一的分配中心来分配唯一ID时，业务方每次调用接口都多了一次调用分配中心获取唯一ID的请求。这多了额外的开销。
获取唯一ID有一种方式，是借助mysql的自增索引，这其实也是一个ID分配中心。对服务性能有苛刻要求时，可以采用第二种方式，由主调服务本身来生成这个唯一ID。关注公众号互联网架构师可以获取MySQL系列教程。
为了保持不会产生重复的ID，可以使用一下几种ID生成方法：
UUID
UUID的全称是Universally Unique Identifier，通用唯一识别码。
具体可以看维基百科的介绍：https://en.wikipedia.org/wiki/Universally_unique_identifier
UUID是一个128bit的数字，用于标志计算机的信息，虽然UUID不能保证绝对不重复，但重复的概率小到可以被忽略。UUID的生成没有什么规律，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。这也就意味着：
128bit，占据了太多的内存空间
生成的ID不是人可以看懂的
无法保证ID的递增，某些场景需要按前后排序 无法满足。
这是一个在线生成UUID的网站：https://www.uuidgenerator.net/ 你可以直观感受一下UUID。
Snowflake
这是Twitter的一个开源项目，它是一个分布式ID的生成算法，它会产生一个long类型的唯一ID，其核心算法是：
时间部分：41bit作为毫秒数，大概可以使用69.7年
机器编号部分：10bit作为机器编号，支持1024个机器实例。
毫秒内的序列号：12bit，一毫米可以生成4096个序列号
网上有各种语言实现的Snowflake算法的实现，有兴趣的阅读一下实现代码。
实际上，redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小异。这是基于redis的分布式ID生成器实现：https://github.com/hengyunabc/redis-id-generator
它的核心思想是：
使用41 bit来存放时间，精确到毫秒，可以使用41年。
使用12 bit来存放逻辑分片ID，最大分片ID是4095
使用10 bit来存放自增长ID，意味着每个节点，每毫秒最多可以生成1024个ID
共享存储
避免不必要的查询
insert into ... values ... on DUPLICATE KEY UPDATE ...
来源:https://www.cnblogs.com/QG-whz/
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
SpringBoot框架开发的优秀的项目「值得收藏学习」 实战篇：一个核心系统 3 万多行代码的重构之旅 1.4 w字，25 张图让你彻底掌握分布式事务原理 一个JDK线程池BUG引发的GC机制思考 TCP 半连接队列和全连接队列满了会发生什么？又该如何应对？ Spring Boot 骚操作 —— 多数据源 Service 层封装（MySQL + MongoDB + ES） ES性能优化实战，几十亿数据查询 3 秒返回！ 做互联网时代适合的架构：开放、分享、协作
长按二维码即可关注我们
求在看|求转发
