如何解决幂等问题？
说幂等底层代码设计前，先把各自问题场景的解决方案说说，主要涵盖分布式锁、Token 令牌以及去重表。
分布式锁和 Token 令牌应用于防重复提交，去重表应对于消息重复防重复消费场景。
-
分布式锁
当用户提交请求时，服务器端可以生成一个唯一的标识，例如使用 UUID。
在处理用户请求之前，服务器尝试获取一个分布式锁。如果成功获取到分布式锁，那么则执行接下来的正常业务逻辑流程。因为锁已经被获取，这样可以确保其他请求无法使用相同的标识，避免重复处理。在请求处理完成后，服务器需要释放分布式锁。 -
Token 令牌
为了防止重复操作，客户端在第一次调用业务请求之前会发送一个获取 Token 的请求。服务端会生成一个全局唯一的 ID 作为 Token，并将其保存在 Redis 中，同时将该 ID 返回给客户端。
在客户端进行第二次业务请求时，必须携带这个 Token。
服务端会验证这个 Token，如果验证成功，则执行业务逻辑并从 Redis 中删除该 Token。
如果验证失败，说明 Redis 中已经没有对应的 Token，表示重复操作，服务端会直接返回指定的结果给客户端。 -
去重表
去重表是指在使用 Redis 或者 MySQL 作为存储时，为了实现幂等性而用于记录已经处理过的请求或操作，以防止重复执行。大部分场景下，大家会使用 Redis 作为去重组件实现。
去重表只是一个说法，存储到 Redis 的话，其实就是一个 String 的 Key 而已。
具体来说，当客户端发送请求时，服务端会先查询 Redis 去重表来检查该请求是否已经被处理过。如果在存在对应的记录，表示请求已经执行过，服务端可以直接返回之，而不再执行重复操作。如果在不存在对应的记录，表示请求是新的，服务端会执行相应的业务逻辑，并在处理完成后将请求的唯一标识（如请求 ID 或标识）添加到 Redis 去重表中，以便后续的重复请求可以被正确识别和处理。
另外，如果消息已经在消费中，抛出异常，消息会触发延迟消费，在消息队列消费失败的场景下即发送到重试队列 RETRY TOPIC。
