翻車了,被讀者找出 BUG

大家好呀，我是小樓。

本文是上篇文章《使用增強版 singleflight 合并事件推送，效果炸裂！》的續(xù)集，沒看過前文必須要先看完才能看本文，實在不想看，拉到文章末尾，給我點個贊再退出吧~Doge

上篇文章發(fā)出后，有一位讀者朋友給我發(fā)私信，寫了一大段話：

一開始，沒太看懂，于是就細問了一下

在看了解釋之后，感覺好像有點懂了，再三思考后，確認了，這里面有 BUG。

理想狀態(tài)

為了描述簡單，這里我用字母本身表示事件發(fā)生，如? A ，用字母加一撇表示事件開始執(zhí)行，如? A' ，用字母加兩撇表示事件執(zhí)行結(jié)束后的狀態(tài)，如? D'' 。

如下表示我們之前思考的理想狀態(tài)：A 事件到來便執(zhí)行，在執(zhí)行結(jié)束前又先后來了 B、C、D 三個事件，先 Hold 住，待 A 執(zhí)行完成后，B、C、D 同時進入 sigleflight group 中搶執(zhí)行，最終結(jié)果是 D''，感覺非常完美。

對應到代碼上是這樣：

case 1

但這位讀者提出了一個疑問，如果在 B、C、D 執(zhí)行的時候又來一個 E 事件，那這個 E 事件將會重走 A 事件的路，如果這個 E 事件執(zhí)行的比較快，先于 B、C、D 事件完成，那不就有問題了？

E 事件最后到，我們期望的結(jié)果應該是 E''，但按這個推理，最終結(jié)果是 D''，顯然不符合預期。

case 2

同理，如果在 E 事件執(zhí)行期間累積了 F、G 事件，且 F、G 也比較爭氣，在 B、C、D 完成之前完成了：

期望的是 G''，但最終結(jié)果是 D''。

線上有問題嗎？

這兩個場景確實很難測試到，如果不幸遇到，還是有風險的。我們復盤了自己的系統(tǒng)，發(fā)現(xiàn)我們的系統(tǒng)是可以解這個問題的。

我們的系統(tǒng)會針對推送下去不一致的數(shù)據(jù)進行定期補償，具體怎么做的呢？

在推送之前，針對同一種推送，也就是相同的 key 生成（存在則更新）同一條記錄，該記錄包含兩個時間 t1、t2，推送的開始時間 tn（精確到納秒）記錄到 t1，推送完成后將 tn 記錄到 t2，這兩次記錄在一個方法中，偽代碼是這樣：

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

    

如果 t1 = t2 則說明推送沒有問題，如果 t1 != t2 則說明這條推送需要補償，每 10s 掃描一次需要補償?shù)氖录M行重新下發(fā)推送

我們以 case 1 為例，按照時間順序

• A 執(zhí)行完成時，t1= ta，t2 = ta
• D 開始執(zhí)行，t1 = td
• E 開始執(zhí)行，t1 = te，E 執(zhí)行結(jié)束 t2 = te
• D 執(zhí)行結(jié)束，t1 = te，t2 = td
• 10 s 后發(fā)現(xiàn) t1 != t2，于是觸發(fā)重新下發(fā)邏輯，重新推送最新數(shù)據(jù)為 E''

最后

還好我們線上系統(tǒng)有一層保護機制，否則可能要出事。如果在 singleflight 層面去解決這個問題，暫時我還沒有想到很好的辦法，如果讀者朋友們有好的方法，歡迎私信我。

不得不說讀者朋友們當中還是有不少讀了我的文章，而且認真思考了的，在此表示感謝，也歡迎大家指出文章中的錯誤。

最后感謝能抽空看到這里，如果你能點贊、在看、分享，我會更加感激不盡~

---

• 搜索關(guān)注微信公眾號"捉蟲大師"，后端技術(shù)分享，架構(gòu)設計、性能優(yōu)化、源碼閱讀、問題排查、踩坑實踐
• 進技術(shù)交流群加微信 MrRoshi