面试官：要不你来讲讲你最近在看的点呗？能够拉进去一起探讨下

候选者：最近在看「去重」和「幂等」相干的内容

面试官：那你就先来聊聊你对「去重」和「幂等」的了解吧

候选者：我认为「幂等」和「去重」它们很像，我也说不出他们之间的严格区别

候选者：我说下我集体的了解，我也不晓得对不对

候选者：「去重」是对申请或者音讯在「肯定工夫内」进行去重「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」做了些变种，而后取了个名字…

候选者：总的来说，换汤不换药（：

面试官：嗯…理解了

欢送关注我的微信公众号【Java3y】来聊聊Java面试，对线面试官系列继续更新中！

【对线面试官-挪动端】系列 一周两篇继续更新中！
【对线面试官-电脑端】系列 一周两篇继续更新中！

原创不易！！求三连！！