阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.cnblogs.com/QG-whz/p/10372458.html 「melonstreet」欢迎转载，保留摘要，谢谢！

• 为什么需要保证幂等性
• 唯一ID
  • UUID
  • Snowflake
• 共享存储
• 避免不必要的查询

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

为什么需要保证幂等性

编程中的“幂等性”是指任意多次执行所产生的影响，与一次执行的影响相同。一个拥有幂等性设计的接口，保证无论一次或多次来调用接口，都能够得到相同的结果。接口的幂等性设计在某些场景下是必需的，例如用户下单的场景。

我们知道，服务之间的调用存在三种状态：成功、失败、超时。超时是一种未知的状态：被调服务是否执行成功，这个状态是未知的。上游服务调用下游服务超时时可能会进行重试。对于用户下单的场景的超时重试我们考虑以下问题：

• 是否会导致最终创建了两条一样的订单？
• 是否会扣除两遍库存？
• 是否会重复扣除用户的钱？

如果每一笔订单都携带唯一的序号，下单接口可以借助这个序号，来记录某次下单操作的状态。当下单的状态为成功时，就将重复的执行拦截住，避免出现上述的问题。这种方式是由下游被调方来保证幂等性。

除此之外，订单服务也可以提供查询订单状态的接口，上游在下单之前先进行查询，确认该笔订单并没有成功支付后，再重复进行下单操作。

一般来说，服务本身需要自己保证幂等性，而不应该将幂等性交给上游的调用方来做。

唯一ID

就上面的幂等性下单接口来说，要做到幂等性，就需要借助一个唯一的ID来标志每次交易。唯一ID的分配可以有几种方式：

• 由一个统一的ID分配中心来分配。
• 由上游服务来生成唯一ID，但必须保证不产生冲突的ID。

采用统一的分配中心来分配唯一ID时，业务方每次调用接口都多了一次调用分配中心获取唯一ID的请求。这多了额外的开销。获取唯一ID有一种方式，是借助mysql的自增索引，这其实也是一个ID分配中心。对服务性能有苛刻要求时，可以采用第二种方式，由主调服务本身来生成这个唯一ID。为了保持不会产生重复的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存在说明是重复请求。