緩存不一致問題
背景
會員相關有：
- 綜合系統 ：會員的基礎CRUD ，舊系統，慢慢廢棄，不再維護。
- 會員系統 ：從綜合系統裏拆分出來的，有基礎服務，接口服務，數據同步服務，SSO服務等。 每個服務都是單獨的應用。
兩個系統共用同一張表，只是維護的字段不一樣。
email【郵箱】是我們新版本中新支持的功能。綜合系統沒有 email 字段，會員系統裏有 email 字段。
第一次反饋
用戶反饋說： 郵箱收不郵件，去設置中看，郵箱設置會自動消失。重新設置一下就好了。
定位問題
一） 排查數據問題
懷疑是綜合系統中，將 email 字段更新成了默認的空值 。
系統缺少必要的日誌，無法追蹤問題。並且缺少sql日誌. 無法定位具體問題。
觀察了系統監控，沒有異常。 內存，網絡也沒有波動。問題拋給了測試同學，希望能復現出來。
第二次反饋
用戶反饋說：又出現郵箱收不到郵件，還沒來得及重置，但過了大概一個小時，自動好了。
定位問題
一）排查數據庫
此時用戶沒有做更新操作。保護了數據庫現場。
馬上查詢數據庫. 得到以下結果：
- 用戶的 email 是存在的。
- 數據的最後更新時間，還是用戶上次反饋的時間。
數據現場表明 ， 自從上次用戶更新過後，沒再發生過變化 。字段丟失，然後自動恢復顯然不是發生在數據庫上。
此時想到是多服務間的數據不一致性。
二）排查緩存
此時想到是緩存問題。
經過代碼求證。 綜合系統和會員系統是用的兩個緩存key，所以不存在新舊系統的緩存衝突問題。
二） 排查服務
此時又想到是不同服務間的字段不一致，導致緩存不一致的可能性。
由於每個服務都是單獨的應用。對於 email 字段，只有基礎服務，接口服務使用到了。 上線時只升級了這兩個服務，其他服務沒有做相應升級。
也就是說，其他服務在做查詢時，是沒有 email 字段的 ， 那麼在寫緩存時也是沒有的。
到這一步，基本確定是不同服務間的緩存更新，導致的緩存不一致問題。基本符合用戶描述的問題。
於是將步驟同步給測試同學，由測試同學去復現 。
問題癥結
尷了尬的。 居然沒有復現出來。
這時才注意到另一個點。 緩存默認時長是 6 小時 。 用戶有說過大概一個小時後恢復了。
用戶是持續性事件 ，緩存週期是 6 小時 ， 不可能只一個小時就更新了緩存。
輔助工具不給力
一）運維平臺的 緩存查詢功能 ， 由於年久失修， 並且過度設計，已經不能支持會員系統的緩存查詢 。
二）線上的緩存服務器只開放給運維人員 ， 開發負責人都沒權限 的。 關鍵運維還沒人值班，大晚上也找不到人 。
第三次反饋
用戶反饋說：郵件又不生效了， 此時設置界面也沒有郵箱了 。 給我些時間定位問題，他先不重置。
大晚上的 。 正在找不到問題點時 ， 用戶竟然還在線 ， 並且還在關注問題 。 （中國好用戶）
馬上去查詢數據庫 ，得到以下結果：
- 用戶的 email 字段還是存在的
- 數據的最後更新時間，還是用戶第一次反饋的時間。
由此可以確定 。MD，就是緩存的問題 。
至此的定位結果
- 確認是緩存不一致問題 。
- 理論上應該是服務間數據不一致導致的緩存不一致。
- 無法復現
- 無法解釋一小時自動恢復
缺少必要的支持，問題只能先暫停一下。 跟用戶溝通好後 ， 決定明天如果還找不到根源，就先把會員系統的其他所有服務都升級一把。
緩存平臺，由於運維人員維護不力 ，必須得催促一下。 太影響工作了。
後記
也就是第二天了 。
先找運維要來了緩存服務器權限 ， 由於沒有現場， 想來問題肯定不止影響一個用戶。去數據庫裏找了幾個活躍用戶， 果然試也沒幾個就找到了問題的用戶。
找到了問題緩存 。 是由於數據同步服務，在查詢數據時，寫緩存導致把原緩存覆蓋了。
理論上會員基本的CRUD都應該由基礎服務來提供接口操作 ， 但由於開發人員的不規範開發 ， 在數據同步服務直接操作了數據庫和緩存 。
問題解決
升級了數據同步服務， 問題就解決了。
但沒有完美解決 ， 後續很大概率還會出現服務升級不同步， 及開發不規範導致的緩存不一致問題。 需求從技術層面解決服務間緩存不一致的問題。
解決緩存不一致
解決思路：
- 對緩存添加版本號
- 版本號是在打包時生成 ，減少人工成本。
- 當 緩存版本 》= 當前服務版本，ok，沒問題，緩存是最新的
- 當 緩存版本 《 當前服務版本 ， 有問題。緩存舊，不適合當前服務使用。 那麼淘汰緩存 ，重新生成。
好了， 有活幹了， 對緩存的封裝，要趕快做起來了。
最後
神奇的一小時 ，還是沒解出來 。 還有 MD，測試沒復現是 測試的同學步驟錯了。。。