听到这个需求，第一反应就是，防止薅羊毛最保险的方案不还是在服务端加限制吗?虽然大部分的接口处理我们都是加了loading的，但又不能确保真的是每个接口都加了的，可是如果要一个接口一个接口的排查，那这维护了四五年的系统，成百上千的接口肯定要耗费非常多的精力，根本就是不现实的，所以就只能去做全局处理。
举一个最简单的例子:日常开发中crud在业务系统中普遍存在，在服务端没有做任何处理，客户端没有做 节流、防抖 等限流操作时，同一秒一个用户点了两次新增按钮，导致数据库中存在同样两条数据，其结果可想而知，同理修改、删除同样的道理;
通常我们可以在前端通过防抖和节流来解决短时间内请求重复提交的问题，如果因网络问题、Nginx重试机制、微服务Feign重试机制或者用户故意绕过前端防抖和节流设置，直接频繁发起请求，都会导致系统防重请求失败，甚至导致后台产生多条重复记录，此时我们需要考虑在后台增加防重设置。
简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID，请求的时候携带这个全局 ID 一起请求，后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。
