小茵：聊聊你对【去重】和【幂等】的理解吧
小奥：我认为【幂等】和【去重】他们很像，我也说不出他们的严格区别
小奥：我说下我个人的理解，我也不知道对不对
小奥：【去重】是对请求或者消息在【一定时间内】进行去重【N次】
小奥：【幂等】则是保证请求或消息在【任意时间内】进行处理，都需要保证他的结果是一致的
小奥：不论是【去重】还是【幂等】，都需要对一个有【唯一Key】，并且有地方对唯一Key进行【存储】
image.png
小奥：以项目举例，我维护的「消息管理平台」是有「去重」的功能的：「5分钟相同内容消息去重」「1小时内模板去重」「一天内渠道达到N次阈值去重」…
小奥：再次强调下「幂等」和「去重」的本质：「唯一Key」+「存储」
小茵：那你是怎么做的呢
小奥：不同的业务场景，唯一Key是不一样的，由业务决定
小奥：存储选择挺多的，比如「本地缓存」/「Redis」/「MySQL」/「HBase」等等，具体选取什么，也跟业务有关
小奥：比如说，在「消息管理平台」这个场景下，我存储选择的「Redis」（读写性能优越），Redis也有「过期时间」方便解决「一定时间内」的问题
小奥：而唯一Key，自然就是根据不同的业务构建不同的。
小奥：比如说「5分钟相同内容消息去重」，我直接MD5请求参数作为唯一Key。「1小时模板去重」则是「模板ID+userId」作为唯一Key，「一天内渠道去重」则是「渠道ID+userId」作为唯一Key…
image.png
小茵：既然提到了「去重」了，你听过布隆过滤器吗？
小奥：自然是知道的啦
小茵：来讲讲布隆过滤器吧，你为什么不用呢？
小奥：布隆过滤器的底层数据结构可以理解为bitmap，bitmap也可以简单理解为是一个数组，元素只存储0和1，所以它占用的空间相对较小
小奥：当一个元素要存入bitmap时，其实是要去看存储到bitmap的哪个位置，这时一般用的就是哈希算法，存进去的位置标记为1
小奥：标记为1的位置表示存在，标记为0的位置标示不存在
image.png
小奥：布隆过滤器是可以以较低的空间占用来判断元素是否存在进而用于去重，但是它也有对应的缺点
小奥：只要使用哈希算法离不开「哈希冲突」，导致有存在「误判」的情况
小奥：在布隆过滤器中，如果元素判定为存在，那该元素「未必」真实存在。如果元素判定为不存在，那就肯定是不存在
小奥：这应该不用我多解释了吧？（结合「哈希算法」和「标记为1的位置表示存在，标记为0的位置标示不存在」这两者就能得出上面结论）
小奥：布隆过滤器也不能「删除」元素（也是哈希算法的局限性，在布隆过滤器中是不能准确定位一个元素的）
image.png
小奥：如果要用的话，布隆过滤器的实现可以直接上Guava已经实现好的，不过这个是单机的
小奥：而分布式下的布隆过滤器，一般现在会用Redis，但也不是没个公司都会部署布隆过滤器的Redis版（还是有局限）
image.png
小奥：如果「去重」开销比较大，可以考虑建立「多层过滤」的逻辑
小奥：比如，先看看『本地缓存』能不能过滤一部分，剩下「强校验」交由『远程存储』（常见的Redis或者DB）进行二次过滤
小茵：嗯，那我就想起你上一次回答Kafka的时候了
小茵：当时你说在处理订单时实现了at least one + 幂等
小茵：幂等处理时：前置过滤使用的是Redis，强一致校验时使用的是DB唯一索引，也是为了提高性能，对吧？
小茵：唯一Key 好像就是 「订单编号 + 订单状态」
小奥：一般我们需要对数据强一致性校验，就直接上MySQL（DB），毕竟有事务的支持
小奥：「本地缓存」如果业务适合，那可以作为一个「前置」判断
小奥：Redis高性能读写，前置判断和后置均可（：
小奥：而HBase则一般用于庞大数据量的场景下（Redis内存太贵，DB不够灵活也不适合单表存大量数据）
image.png
小奥：至于幂等，一般的存储还是「Redis」和「数据库」
小奥：最最最最常见的就是数据库「唯一索引」来实现幂等（我所负责的好几个项目都是用这个）
小奥：构建「唯一Key」是业务相关的事了（：一般是用自己的业务ID进行拼接，生成一个”有意义”的唯一Key
小奥：当然，也有用「Redis」和「MySQL」实现分布式锁来实现幂等的（：
小奥：但Redis分布式锁是不能完全保证安全的，而MySQL实现分布式锁（乐观锁和悲观锁还是看业务吧，我是没用到过的）
小奥：网上有很多实现「幂等」的方案，本质上都是围绕着「存储」和「唯一Key」做了些变种，然后取了个名字…
小奥：总的来说，换汤不换药（：
小茵：恩...了解了
网友评论