大家好呀，我是小樓，
本文是上篇文章《使用增強版 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 層面去解決這個問題，暫時我還沒有想到很好的辦法，如果讀者朋友們有好的方法，歡迎私信我，
不得不說讀者朋友們當中還是有不少讀了我的文章，而且認真思考了的，在此表示感謝，也歡迎大家指出文章中的錯誤，
最后感謝能抽空看到這里，如果你能點贊、在看、分享，我會更加感激不盡~
- 搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/554960.html
標籤：其他
下一篇：返回列表