翻车了,被读者找出 BUG

捉虫大师

共 1774字,需浏览 4分钟

 ·

2023-05-23 14:33

大家好呀,我是小楼。

本文是上篇文章《使用增强版 singleflight 合并事件推送,效果炸裂!》的续集,没看过前文必须要先看完才能看本文,实在不想看,拉到文章末尾,给我点个赞再退出吧~Doge

上篇文章发出后,有一位读者朋友给我发私信,写了一大段话:

815e59b270c6af183fbda519002e63a6.webp

一开始,没太看懂,于是就细问了一下

423ecd355686ab47aa068b5ee429311f.webp

在看了解释之后,感觉好像有点懂了,再三思考后,确认了,这里面有 BUG。

理想状态

为了描述简单,这里我用字母本身表示事件发生,如  A ,用字母加一撇表示事件开始执行,如  A' ,用字母加两撇表示事件执行结束后的状态,如  D''

如下表示我们之前思考的理想状态:A 事件到来便执行,在执行结束前又先后来了 B、C、D 三个事件,先 Hold 住,待 A 执行完成后,B、C、D 同时进入 sigleflight group 中抢执行,最终结果是 D'',感觉非常完美。

49856eea5d455ec86c8631fefeb955df.webp

对应到代码上是这样:

57ea8ba18834f55f882506b2d588a2fd.webp case 1

但这位读者提出了一个疑问,如果在 B、C、D 执行的时候又来一个 E 事件,那这个 E 事件将会重走 A 事件的路,如果这个 E 事件执行的比较快,先于 B、C、D 事件完成,那不就有问题了?

939a9086b8af6a8d39bb7baa46b25c33.webp

E 事件最后到,我们期望的结果应该是 E'',但按这个推理,最终结果是 D'',显然不符合预期。

case 2

同理,如果在 E 事件执行期间累积了 F、G 事件,且 F、G 也比较争气,在 B、C、D 完成之前完成了:

d466bd1c6419581a0695b01b37ac8a09.webp

期望的是 G'',但最终结果是 D''。

线上有问题吗?

这两个场景确实很难测试到,如果不幸遇到,还是有风险的。我们复盘了自己的系统,发现我们的系统是可以解这个问题的。

我们的系统会针对推送下去不一致的数据进行定期补偿,具体怎么做的呢?

在推送之前,针对同一种推送,也就是相同的 key 生成(存在则更新)同一条记录,该记录包含两个时间 t1、t2,推送的开始时间 tn(精确到纳秒)记录到 t1,推送完成后将 tn 记录到 t2,这两次记录在一个方法中,伪代码是这样:

      
      tn := time.Now().UnixNano()
markT1(key, tn)
push(key)
markT2(key, tn)

如果 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
  • 10 s 后发现 t1 != t2,于是触发重新下发逻辑,重新推送最新数据为 E''
939a9086b8af6a8d39bb7baa46b25c33.webp 最后

还好我们线上系统有一层保护机制,否则可能要出事。如果在 singleflight 层面去解决这个问题,暂时我还没有想到很好的办法,如果读者朋友们有好的方法,欢迎私信我。

不得不说读者朋友们当中还是有不少读了我的文章,而且认真思考了的,在此表示感谢,也欢迎大家指出文章中的错误。

最后感谢能抽空看到这里,如果你能点赞在看分享,我会更加感激不尽~


  • 搜索关注微信公众号"捉虫大师",后端技术分享,架构设计、性能优化、源码阅读、问题排查、踩坑实践
  • 进技术交流群加微信 MrRoshi
浏览 10
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报