共计 1975 个字符，预计需要花费 5 分钟才能阅读完成。
面试官 ： 要不你来讲讲你最近在看的点呗？能够拉进去一起探讨下
候选者：最近在看「去重」和「幂等」相干的内容
面试官 ： 那你就先来聊聊你对「去重」和「幂等」的了解吧
候选者：我认为「幂等」和「去重」它们很像，我也说不出他们之间的严格区别
候选者：我说下我集体的了解，我也不晓得对不对
候选者：「去重」是对申请或者音讯在「肯定工夫内」进行去重「N 次」
候选者：「幂等」则是保障申请或音讯在「任意工夫内」进行解决，都须要保障它的后果是统一的
候选者：不论是「去重」还是「幂等」，都须要对有一个「惟一 Key」，并且有中央对惟一 Key 进行「存储」
候选者：以我的项目举例，我保护的「音讯治理平台」是有「去重」的性能的：「5 分钟雷同内容音讯去重」「1 小时内模板去重」「一天内渠道达到 N 次阈值去重」…
候选者：再次强调下「幂等」和「去重」的实质：「惟一 Key」+「存储」
面试官 ： 那你是怎么做的呢
候选者：不同的业务场景，惟一 Key 是不一样的，由业务决定
候选者：存储抉择挺多的，比方「本地缓存」/「Redis」/「MySQL」/「HBase」等等，具体选取什么，也跟业务无关
候选者：比如说，在「音讯治理平台」这个场景下，我存储抉择的「Redis」（读写性能优越），Redis 也有「过期工夫」不便解决「肯定工夫内」的问题
候选者：而惟一 Key，天然就是依据不同的业务构建不同的。
候选者：比如说「5 分钟雷同内容音讯去重」，我间接 MD5 申请参数作为惟一 Key。「1 小时模板去重」则是「模板 ID+userId」作为惟一 Key，「一天内渠道去重」则是「渠道 ID+userId」作为惟一 Key…
面试官 ： 既然提到了「去重」了，你听过布隆过滤器吗？
候选者：天然是晓得的啦
面试官 ： 来讲讲布隆过滤器吧，你为什么不必呢？
候选者：布隆过滤器的底层数据结构能够了解为 bitmap，bitmap 也能够简略了解为是一个数组，元素只存储 0 和 1，所以它占用的空间绝对较小
候选者：当一个元素要存入 bitmap 时，其实是要去看存储到 bitmap 的哪个地位，这时个别用的就是哈希算法，存进去的地位标记为 1
候选者：标记为 1 的地位示意存在，标记为 0 的地位标示不存在
候选者：布隆过滤器是能够以较低的空间占用来判断元素是否存在进而用于去重，然而它也有对应的毛病
候选者：只有应用哈希算法离不开「哈希抵触」，导致有存在「误判」的状况
候选者：在布隆过滤器中，如果元素断定为存在，那该元素「未必」实在存在。如果元素断定为不存在，那就必定是不存在
候选者：这应该不必我多解释了吧？（联合「哈希算法」和「标记为 1 的地位示意存在，标记为 0 的地位标示不存在」这两者就能得出下面论断）
候选者：布隆过滤器也不能「删除」元素（也是哈希算法的局限性，在布隆过滤器中是不能精确定位一个元素的）
候选者：如果要用的话，布隆过滤器的实现能够间接上 Guava 曾经实现好的，不过这个是单机的
候选者：而分布式下的布隆过滤器，个别当初会用 Redis，但也不是没个公司都会部署布隆过滤器的 Redis 版（还是有局限，像我以前公司就没有）
候选者：所以，目前我负责的我的项目都是没有用布隆过滤器的（：
候选者：如果「去重」开销比拟大，能够思考建设「多层过滤」的逻辑
候选者：比方，先看看『本地缓存』能不能过滤一部分，剩下「强校验」交由『近程存储』（常见的 Redis 或者 DB）进行二次过滤
面试官：嗯，那我就想起你上一次答复 Kafka 的时候了
面试官：过后你说在解决订单时实现了 at least one + 幂等
面试官：幂等解决时：前置过滤应用的是 Redis，强统一校验时应用的是 DB 惟一索引，也是为了进步性能，对吧？
面试官：惟一 Key 如同就是「订单编号 + 订单状态」
候选者 ： 面试官 你忘性真的好！
候选者：个别咱们须要对数据强一致性校验，就间接上 MySQL（DB），毕竟有事务的反对
候选者：「本地缓存」如果业务适宜，那能够作为一个「前置」判断
候选者：Redis 高性能读写，前置判断和后置均可（：
候选者：而 HBase 则个别用于宏大数据量的场景下（Redis 内存太贵，DB 不够灵便也不适宜单表存大量数据）
候选者：至于幂等，个别的存储还是「Redis」和「数据库」
候选者：最最最最常见的就是数据库「惟一索引」来实现幂等（我所负责的好几个我的项目都是用这个）
候选者：构建「惟一 Key」是业务相干的事了（：个别是用本人的业务 ID 进行拼接，生成一个”有意义”的惟一 Key
候选者：当然，也有用「Redis」和「MySQL」实现分布式锁来实现幂等的（：
候选者：但 Redis 分布式锁是不能齐全保障平安的，而 MySQL 实现分布式锁（乐观锁和乐观锁还是看业务吧，我是没用到过的）
候选者：网上有很多实现「幂等」的计划，实质上都是围绕着「存储」和「惟一 Key」做了些变种，而后取了个名字…
候选者：总的来说，换汤不换药（：
面试官：嗯…理解了
