大家好呀，我是小樓。

本文是上篇文章《使用增強版 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，這兩次記錄在一個方法中，偽代碼是這樣：

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
• 10s 後發現 t1 != t2，於是觸發重新下發邏輯，重新推送最新數據為 E''

最後

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

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

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

• 搜索關註微信公眾號"捉蟲大師"，後端技術分享，架構設計、性能優化、源碼閱讀、問題排查、踩坑實踐