如何解决幂等问题？

如何解决幂等问题？

说幂等底层代码设计前，先把各自问题场景的解决方案说说，主要涵盖分布式锁、Token 令牌以及去重表。
分布式锁和 Token 令牌应用于防重复提交，去重表应对于消息重复防重复消费场景。

1. 分布式锁
   当用户提交请求时，服务器端可以生成一个唯一的标识，例如使用 UUID。
   在处理用户请求之前，服务器尝试获取一个分布式锁。如果成功获取到分布式锁，那么则执行接下来的正常业务逻辑流程。因为锁已经被获取，这样可以确保其他请求无法使用相同的标识，避免重复处理。在请求处理完成后，服务器需要释放分布式锁。

2. Token 令牌
   为了防止重复操作，客户端在第一次调用业务请求之前会发送一个获取 Token 的请求。服务端会生成一个全局唯一的 ID 作为 Token，并将其保存在 Redis 中，同时将该 ID 返回给客户端。
   在客户端进行第二次业务请求时，必须携带这个 Token。
   服务端会验证这个 Token，如果验证成功，则执行业务逻辑并从 Redis 中删除该 Token。
   如果验证失败，说明 Redis 中已经没有对应的 Token，表示重复操作，服务端会直接返回指定的结果给客户端。

3. 去重表
   去重表是指在使用 Redis 或者 MySQL 作为存储时，为了实现幂等性而用于记录已经处理过的请求或操作，以防止重复执行。大部分场景下，大家会使用 Redis 作为去重组件实现。
   去重表只是一个说法，存储到 Redis 的话，其实就是一个 String 的 Key 而已。
   具体来说，当客户端发送请求时，服务端会先查询 Redis 去重表来检查该请求是否已经被处理过。如果在存在对应的记录，表示请求已经执行过，服务端可以直接返回之，而不再执行重复操作。如果在不存在对应的记录，表示请求是新的，服务端会执行相应的业务逻辑，并在处理完成后将请求的唯一标识（如请求 ID 或标识）添加到 Redis 去重表中，以便后续的重复请求可以被正确识别和处理。
   另外，如果消息已经在消费中，抛出异常，消息会触发延迟消费，在消息队列消费失败的场景下即发送到重试队列 RETRY TOPIC。