网站备案 不关站,石家庄最近新闻事件,大连建设主管部门官方网站,海口cms建站系统一、前言
我前几天建了一个java讨论的qq群#xff08;920868614#xff09;#xff0c;拉了几个人在讨论。这几天和群友聊的时候#xff0c;有个群友提了一个面试问题#xff0c;大家回答的时候有个群友(简哥#xff0c;他qq昵称就叫简哥)提出了一个不同寻常的论点…一、前言
我前几天建了一个java讨论的qq群920868614拉了几个人在讨论。这几天和群友聊的时候有个群友提了一个面试问题大家回答的时候有个群友(简哥他qq昵称就叫简哥)提出了一个不同寻常的论点然后就讨论了一上午的讨论。
本人技术有限无法评判对错只能总结下群友(简哥)和其他群友的观点发上来。
二、问题
面试官如何解决消息队列重复消费的
群友通过幂等、数据库消息表、状态机...
简哥正常使用不会重复消费 直接反问他他是怎么用的代码是怎么写的
我消息队列我都没用过哎那是啥 三、辩论
简哥观点上的冲突引发了讨论群友使用质疑简哥质疑群友的质疑。因为是qq群聊天的形式。群友问答比较散图不好截聊着聊着还会偏题。 所以我大体整理下几个关键问答。 群友正常使用也有问题比如发送消息后消息队列接收成功但是回告的时候出现网络波动宕机。 导致客户端没有正确接收客户端重发消息自然会产生重复的消息。
简哥每条消息都会有一个id或发送时间你都重发了这个肯定是不一样的。内容不一样那怎么能说是重复消息只能说这两条消息高度相似。 群友可消费端接收这两条消息比如订单扣库存场景不就重复扣库存了嘛。
简哥那是你没做幂等这和消息队列没关系就算你用接口调也会重复扣。 群友这种减库存的怎么加幂等
简哥 方法其实挺多的。比如单据减库存 在库存前面加个库存流水表。 单据先生成流水流水去减库存。减的时候判断单据的流水是否存在。 怎么实现都行无非就是考虑怎么适合自己系统的。 群友那消费的时候因为宕机或者负载重设出现部分消息没有接收到消息确认通知导致重新发送一次消息这总是重复了吧。
简哥那你这么说的话确实是重复了。 但我个人建议系统不是那种百万级别并发的时候不要去考虑这种情况。一般来讲这种情况的解决方案也可以用上面说的幂等和合理的业务设计去解决。
简哥但如果系统并发太大的话比如还是我上面说的幂等判断他的单条链路就变成判断流水不存在- 新增流水- 扣减库存。在执行过程中未提交事务这时候有条重复的消息进来流水不存在就可以绕过幂等。 导致库存重复扣。 群友 加锁呀库存金额这种比较重要一般不都是加锁的。redis的分布式锁。
简哥可以是可以但是到这种体量的时候redis也不可靠redis分布式锁是互斥的会极大的影响并发。最重要的是库存容易乱序因为redis的分布式锁是无序的。 群友 换数据库加乐观锁是不是可以解决 update 后面跟where条件的那个。
简哥还记得我们的前提嘛现在是百万并发的大型系统。但凡大点的系统性能瓶颈都在数据库上。因为这个完全是把压力转嫁给了数据库。 这样搞长事务会非常多尤其是库存这种核心表。
群友 所以要保证顺序消费的话那其实不管用什么性能都上不去。 所以扣库存这种业务逻辑本身要保证顺序只能一个一个消费了简哥那也不是看业务场景。 有些保证不能超卖有些无所谓顺序。 有些仓库是卖螺丝的小配件基本都是称重的他录了数量但基本不在乎。有些卖手机的少一台都是问题。
群友 简哥总之就是看业务看需求。 要是普通用用不会有什么重复消费之类的情况。顶多就是消费端上个幂等兜底就行了。但是面试官要是问下去问清楚他们是什么架构什么场景的针对性的去回答就好了。 四、结语
其实聊到这里的时候就没几个能接上话了话题也差不多终结了。 我也不知道他们说得对不对但我感觉字多的有道理。我下次面试也这么试试。 面试官: 如何解决消息队列重复消费的
我正常使用不会重复消费你怎么用的代码怎么写的
面试官: ???
这样想想还挺带感~
