两个解决并发问题的案例

两个解决并发问题的案例

最近和zy聊天,有两个关于并发的场景比较有意思,记录下思考的过程。

场景一

A和B在微信里发消息,如果A发的消息顺序是A1,A2,A3,B发的消息顺序是B1,B2,B3。

两个问题:

  1. 如果A2由于网络原因,比A3后到服务器,B收到的消息是什么样的?
  2. 如果都不丢消息,A1和B1同时发出,几乎同时到服务器,再分别传给A和B,那么在聊天窗口的表现是什么?

经过zy的黑盒逆向测试,问题1的答案是B看到A1和A3,在A看到A2发送失败,有个红色叹号,如果点击重发,相当于发出了一个相同内容的A4。

问题2的答案是可能A看到的是A1,B1,B看到的是B1,A1,即在不同人之间的消息,没有严格的顺序,以客户端本地上屏的顺序为主。(在A来说,A1发完就上屏,B1是后来接收到的,就A1在上面,同理B也是)。如果这时打开一个新终端来同步,那么以服务器那份数据为主,按照时间线的顺序拉取。

分析

问题1中,在微信客户端上传消息时,应该给每条消息都加了序列号,按照发送的顺序升序,如果服务器发现序列号回跳缩小了,就丢弃掉,并返回客户端失败。这样做的好处是处理简单,不会造成用户收到一条消息,突然又蹦出一跳消息插在了前面,导致漏看消息,都是追加写。
当然也有另外的实现方式,就是没序号,你发什么服务器收什么,哪条先到就哪条在先,但是会有个新问题,用户本想发的是A1,A2,因为人的语言是有顺序的,但是看到的是A2,A1,有些语境乱掉的会引起歧义。

在丢消息和乱消息两者,选择了可以丢。

问题2也是,可以做到以服务器为准,纠正客户端的表现,做到强一致,但是微信认为这不是个问题,两个人同时发的哪个先哪个后不影响理解内容,以每个手机上屏时间为准。但是在同步新消息时,以服务器为准,因为此时根本没有冲突。

如果单纯从技术角度解决这两个问题,也有很直接的方法。对于问题一,发现漏了序号,服务器再下发一小消息,让客户端重传,然后等待重传成功再发给接收方,但这种方法复杂,出问题也不易调试,在产品需求上得不偿失。对于问题二,建立个全局id,每条消息都分个先后,对于全局id的一致和出错恢复的影响,要投入巨大精力来实现,能解决的还是个很少发生的场景问题,甚至真发生了,也不算个问题。

场景二

用户从其他渠道拿到兑换码,然后在小米官网输入兑换码,兑换奖品,每个码只能用一次,每个用户一天只能兑换2次奖品。此时会有问题。兑换码标记失效,和给用户发奖,是两个动作,会有并发问题。两个动作的先后顺序,哪个先哪个后。是否要用事务。

也是两个问题:
1. 两个用户A和B用同一个兑换码同时兑换,怎么处理?
2. 一个用户同时用两个兑换码兑换,发现当天只能有一次兑换机会时,两个码都失效吗,会多扣一个码吗?

分析

方法一最简单方法,用事务,每次兑换前开启事务,兑换后结束事务。优点:代码简单。缺点:事务太重,在互联网高并发的场景中,性能不高。

方法二先扣兑奖次数,再失效兑换码。这种情况在两个用户用同一个码并发时,会判断都有兑换次数,都扣,但失效兑换码时,只有一个人成功,失败的那个人被多扣了一次抽奖机会。

方法三先失效兑换码,再扣抽奖次数。两个用户用同一个码时,后用的提示码已用过,没问题。一个用户用两个码并发时,先把两个码都失效,再根据兑奖次数,只有一个兑换码成功兑换了奖品,多扣了一个兑换码。

最后选择的方法三,因为两个用户用同一个码是存在的,但是一个用户同时用两个码的概率比较小,用户要输入码再点确定才行。还有如果给用户多扣了一个兑换码的情况,只有用户当天没有兑换次数的时候才出现,不会对用户造成更大的损失。后台根据告警,用修复脚本把多扣的券找出来恢复,用户第二天还能用。

总结

并没有什么银弹,设计的那种方案的好坏,要结合具体需求,详细分析,深入思考需求的特点,在实现复杂度和满足需求找到平衡。


转载请注明来源:两个解决并发问题的案例
欢迎收听公众号

发表评论

电子邮件地址不会被公开。 必填项已用*标注