常规手段

  1. 数据库唯一索引

    1. 本地事务一起（把唯一索引和业务操作组合在一起，做成一个事务）直接用。
      1. rc是读别人已经提交数据可以多次多不同，rr就保证度一样了，更新的时候会直接加锁的
    2. 非本地事务——丢消息 丢数据 定时任务扫表处理常规操作，很常见（公司一个业务多语言多服务，一个业务上下文操作很多地方调用很多接触，出问题丢数据各种，几乎都是通过扫表来保证，或者用户视角前端自动化操作手动提供刷新调用接口）

      1. 腾讯公开课

        image.png

  2. 状态判断

  3. 布隆过滤器

    1. 不存在必然不存在
    2. 存在可能不存在，根据数据量调整布隆过滤器大小来减少（假阳性）

  4. Redis

组合方案 隆过滤器(布谷鸟过滤器」 bit array) + Redis + 唯一索引

字层层削流。从目标上来说，就是确保到达数据

高并发幂等

首先，一个请求过来的时候，我们会利用布隆过滤器来判断它有没有被处理过。如果布隆过滤器说没有处理过，那么就确实没有被处理过，可以直接处理。如果布隆过滤器说处理过（可能是假阳性），那么就要执行下一步。 第二步就是利用 Redis 存储近期处理过的 key。如果 Redis 里面有这个 key，说明它的确被处理过了，直接返回，否则进入第三步。这一步的关键就是 key 的过期时间应该是多长。 第三步则是利用唯一索引，如果唯一索引冲突了，那么就代表已经处理过了。这个唯一索引一般就是业务的唯一索引，并不需要额外创建一个索引。

业务成功先修改mysql，来兜底，其他的随意

Rediskey的过期时间需要业务语意时间保证

redis简化情况也可以去掉，布隆过滤器也可以用redisson实现——分布式（布隆过滤器还是存储运行后的结果，存储到本地guava有实现）

基于布隆过滤器快速匹配敏感词、关键词、品牌词

image.png

其他的本地就要一致性哈希负载均衡了 本地过滤器

image.png