作者回复: 可以啊，这就是我在后面提到的，你可以用 bitmap 取代布隆过滤器。 不过bitmap 之后其实没太大必要接 Redis 了，因为 bitmap 咩有假阳性。也就是说，Bitmap 说有就是有，没有就是没有。

作者回复: 哈哈哈哈，问题 2 可能出乎你的预料，重复请求占比 1% 的话，你只能挡住这 1% 的重复请求。 你可能会奇怪，这不就是寄了吗？但是你要知道，如果你连正常的流量都处理不了，就不用谈别的了。

作者回复: 并没啥问题，就是直接用。

作者回复: 一个是结合前面的一致性哈希负载均衡，这样使用本地的布隆过滤器效果还可以。 如果使用 Redis 的话，确实是难以避免两次 Redis 操作。也可以考虑使用 lua 脚本直接封装。

作者回复: 这里有一个区别。你业务上的成功和系统上成功。 举个例子来说，如果插入唯一索引之后，你的业务逻辑执行失败了，但是这是符合你的系统的预期的，这在这里也叫做业务成功=。=。 也就是说，只要你的业务执行了，根据输入是成功与失败，这里不关心的。 在异步检测系统里面，它只检测初始状态，然后去对比你的业务实际执行情况，执行更新。

作者回复: 看上去就都是阻塞啊，哈哈哈哈，不过底层细节上有一些不同，主要和锁机制有关。

作者回复: 是一种数据结构，有多种实现，可以本地实现，也可以借助 Redis 来实现。

作者回复: 1. 不要用长事务……政治正确但是无用的屁话。你可以考虑切割成几个小事务，然后引入重试机制，寻求最终一致性。你也可以给事务设置超时时间，这样超过时间限制的事务就直接回滚了。 2. 什么锁？是唯一索引那里的锁吗？这里，理论上来说，这个超时时间是你预期别的业务的执行时间。这可以参考后续我分布式锁里讲到的，分布式锁拿锁应该等待多久。 3. 数据库性能这边我没有评估过，但是如果你业务并发很高，重复请求很多的话，确实影响很大。另外一个影响是，第二个消息等待锁的时候，一直拿着这个数据库连接。

作者回复: 要求业务方绕开这个唯一索引重试。相当于，除了没有插入唯一索引这个动作，其它都是一样的。