面试官：去重和幂等的理解掌握多少？

- 日理万妓 2024-04-07 11:45 48阅读 0赞

**面试官**：**要不你来讲讲你最近在看的点呗？可以拉出来一起讨论下**

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

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

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

**候选者**：我说下我个人的理解，我也不知道对不对

**候选者**：「去重」是对请求或者消息在「一定时间内」进行去重「N次」

**候选者**：「幂等」则是保证请求或消息在「任意时间内」进行处理，都需要保证它的结果是一致的

**候选者**：不论是「去重」还是「幂等」，都需要对有一个「唯一 Key」，并且有地方对唯一Key进行「存储」

**![e47ac265dc46414db7952209b23571ce.png][]候选者**：以项目举例，我维护的「消息管理平台」是有「去重」的功能的：「5分钟相同内容消息去重」「1小时内模板去重」「一天内渠道达到N次阈值去重」…

**候选者**：再次强调下「幂等」和「去重」的本质：「唯一Key」+「存储」

**面试官**：**那你是怎么做的呢**

**候选者**：不同的业务场景，唯一Key是不一样的，由业务决定

**候选者**：存储选择挺多的，比如「本地缓存」/「Redis」/「MySQL」/「HBase」等等，具体选取什么，也跟业务有关

**候选者**：比如说，在「消息管理平台」这个场景下，我存储选择的「Redis」（读写性能优越），Redis也有「过期时间」方便解决「一定时间内」的问题

**候选者**：而唯一Key，自然就是根据不同的业务构建不同的。

**候选者**：比如说「5分钟相同内容消息去重」，我直接MD5请求参数作为唯一Key。「1小时模板去重」则是「模板ID+userId」作为唯一Key，「一天内渠道去重」则是「渠道ID+userId」作为唯一Key…

![1a68e2e840cf4887961ff31bb4c112df.png][]

**面试官**：**既然提到了「去重」了，你听过布隆过滤器吗？**

**候选者**：自然是知道的啦

**面试官**：**来讲讲布隆过滤器吧，你为什么不用呢？**

**候选者**：布隆过滤器的底层数据结构可以理解为bitmap，bitmap也可以简单理解为是一个数组，元素只存储0和1，所以它占用的空间相对较小

**候选者**：当一个元素要存入bitmap时，其实是要去看存储到bitmap的哪个位置，这时一般用的就是哈希算法，存进去的位置标记为1

**候选者**：标记为1的位置表示存在，标记为0的位置标示不存在

![aee077b4c41b47fd9fd37fc9c7940fb4.png][]

**候选者**：布隆过滤器是可以以较低的空间占用来判断元素是否存在进而用于去重，但是它也有对应的缺点

**候选者**：只要使用哈希算法离不开「哈希冲突」，导致有存在「误判」的情况

**候选者**：在布隆过滤器中，如果元素判定为存在，那该元素「未必」真实存在。如果元素判定为不存在，那就肯定是不存在

**候选者**：这应该不用我多解释了吧？（结合「哈希算法」和「标记为1的位置表示存在，标记为0的位置标示不存在」这两者就能得出上面结论）

**候选者**：布隆过滤器也不能「删除」元素（也是哈希算法的局限性，在布隆过滤器中是不能准确定位一个元素的）

![79fa92a719ad425aadb2ebe1e6096bfa.png][]

**候选者**：如果要用的话，布隆过滤器的实现可以直接上Guava已经实现好的，不过这个是单机的

**候选者**：而分布式下的布隆过滤器，一般现在会用Redis，但也不是没个公司都会部署布隆过滤器的Redis版（还是有局限，像我以前公司就没有）

**候选者**：所以，目前我负责的项目都是没有用布隆过滤器的（：

![531ea97f1a9a4cacafa148125827a155.png][]

**候选者**：如果「去重」开销比较大，可以考虑建立「多层过滤」的逻辑

**候选者**：比如，先看看『本地缓存』能不能过滤一部分，剩下「强校验」交由『远程存储』（常见的Redis或者DB）进行二次过滤

**面试官**：嗯，那我就想起你上一次回答Kafka的时候了

**面试官**：当时你说在处理订单时实现了at least one + 幂等

**面试官**：幂等处理时：前置过滤使用的是Redis，强一致校验时使用的是DB唯一索引，也是为了提高性能，对吧？

**面试官**：唯一Key 好像就是 「订单编号 + 订单状态」

**候选者**：**面试官**你记性真的好！

**候选者**：一般我们需要对数据强一致性校验，就直接上MySQL（DB），毕竟有事务的支持

**候选者**：「本地缓存」如果业务适合，那可以作为一个「前置」判断

**候选者**：Redis高性能读写，前置判断和后置均可（：

**候选者**：而HBase则一般用于庞大数据量的场景下（Redis内存太贵，DB不够灵活也不适合单表存大量数据）

![714b2bd992f345fb85aeb5dd0df0557d.png][]

**候选者**：至于幂等，一般的存储还是「Redis」和「数据库」

**候选者**：最最最最常见的就是数据库「唯一索引」来实现幂等（我所负责的好几个项目都是用这个）

**候选者**：构建「唯一Key」是业务相关的事了（：一般是用自己的业务ID进行拼接，生成一个”有意义”的唯一Key

**候选者**：当然，也有用「Redis」和「MySQL」实现分布式锁来实现幂等的（：

**候选者**：但Redis分布式锁是不能完全保证安全的，而MySQL实现分布式锁（乐观锁和悲观锁还是看业务吧，我是没用到过的）

**候选者**：网上有很多实现「幂等」的方案，本质上都是围绕着「存储」和「唯一Key」做了些变种，然后取了个名字…

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

**面试官**：嗯…了解了

[e47ac265dc46414db7952209b23571ce.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/cf1d0fa2d2054408b01996baff82a8cf.png
[1a68e2e840cf4887961ff31bb4c112df.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/fa3672f65b1d4cc4852217e209cadfe3.png
[aee077b4c41b47fd9fd37fc9c7940fb4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/8ca61a4237de46bf927d8c37257608e9.png
[79fa92a719ad425aadb2ebe1e6096bfa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/dfc83a1c59254176815ee8bc541cc515.png
[531ea97f1a9a4cacafa148125827a155.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/619c1b45341e440db3d18ab23ea966d6.png
[714b2bd992f345fb85aeb5dd0df0557d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/07/9309e45335af4a27b21fc8418e7fc1f6.png