翻车了,被读者找出 BUG
大家好呀,我是小楼。
本文是上篇文章《使用增强版 singleflight 合并事件推送,效果炸裂!》的续集,没看过前文必须要先看完才能看本文,实在不想看,拉到文章末尾,给我点个赞再退出吧~Doge
上篇文章发出后,有一位读者朋友给我发私信,写了一大段话:
一开始,没太看懂,于是就细问了一下
在看了解释之后,感觉好像有点懂了,再三思考后,确认了,这里面有 BUG。
理想状态
为了描述简单,这里我用字母本身表示事件发生,如 A
,用字母加一撇表示事件开始执行,如 A'
,用字母加两撇表示事件执行结束后的状态,如 D''
。
如下表示我们之前思考的理想状态:A 事件到来便执行,在执行结束前又先后来了 B、C、D 三个事件,先 Hold 住,待 A 执行完成后,B、C、D 同时进入 sigleflight group 中抢执行,最终结果是 D'',感觉非常完美。
对应到代码上是这样:
case 1
但这位读者提出了一个疑问,如果在 B、C、D 执行的时候又来一个 E 事件,那这个 E 事件将会重走 A 事件的路,如果这个 E 事件执行的比较快,先于 B、C、D 事件完成,那不就有问题了?
E 事件最后到,我们期望的结果应该是 E'',但按这个推理,最终结果是 D'',显然不符合预期。
case 2
同理,如果在 E 事件执行期间累积了 F、G 事件,且 F、G 也比较争气,在 B、C、D 完成之前完成了:
期望的是 G'',但最终结果是 D''。
线上有问题吗?
这两个场景确实很难测试到,如果不幸遇到,还是有风险的。我们复盘了自己的系统,发现我们的系统是可以解这个问题的。
我们的系统会针对推送下去不一致的数据会定期补偿,具体怎么做的呢?
在推送之前,针对同一种推送,也就是相同的 key 生成(存在则更新)同一条记录,该记录包含两个时间 t1、t2,推送的开始时间 tn(精确到纳秒)记录到 t1,推送完成后将 tn 记录到 t2,这两次记录在一个方法中,伪代码是这样:
如果 t1 = t2 则说明推送没有问题,如果 t1 != t2 则说明这条推送需要补偿,每 10s 扫描一次需要补偿的事件进行重新下发推送
我们以 case 1 为例,按照时间顺序
A 执行完成时,t1= ta,t2 = ta
D 开始执行,t1 = td
E 开始执行,t1 = te,E 执行结束 t2 = te
D 执行结束,t1 = te,t2 = td
10s 后发现 t1 != t2,于是触发重新下发逻辑,重新推送最新数据为 E''
最后
还好我们线上系统有一层保护机制,否则可能要出事。如果在 singleflight 层面去解决这个问题,暂时我还没有想到很好的办法,如果读者朋友们有好的方法,欢迎私信我。
不得不说读者朋友们当中还是有不少读了我的文章,而且认真思考了的,在此表示感谢,也欢迎大家指出文章中的错误。
最后感谢能抽空看到这里,如果你能点赞
、在看
、分享
,我会更加感激不尽~
搜索关注微信公众号"捉虫大师",后端技术分享,架构设计、性能优化、源码阅读、问题排查、踩坑实践
版权声明: 本文为 InfoQ 作者【捉虫大师】的原创文章。
原文链接:【http://xie.infoq.cn/article/c44e458fed618978b57a1080a】。文章转载请联系作者。
评论