# 今天發生的問題 今天 RW DB CPU 突然很高，造成系統緩慢，影響用戶。 # 排查了哪些事情 1. DBA 提供了線索，Refresh Token 語法緩慢 2. 觀測 CF（Cloudflare），Refresh Token API 次數沒有很高，不是攻擊 3. 一開始先看 Refresh Token API 是否有問題，經過排查，我發現問題出在驗證登入 Token 的 Middleware 4. 那裡會從 RW DB（Read-Write DB）拿 Token 來比對。我剛好觀測到，站台人數往上，與之前相比多了 3 倍，代表登入的 Request 變多， 每次都去 RW DB 比對 Token 而這裡又有一些小問題，疊加起來造成最後的效能問題。整理後有這些： 1. Token 本身沒有 Index（因為需求 & 功能設計，Token 會很大，欄位設為 Max，無法建 Index） 2. 沒有透過 UserId 去取得 Token 3. 沒有去 ReadOnly DB 取得資料，導致和 Refresh Token 互卡，造成 UserToken Table 忙碌 這些疊加起來，造成 RW DB 效能瓶頸，影響到整個站台。 備註：判斷「次數沒有很高」，是拿之前 DDoS 的量來比較——DDoS 一分鐘會達到百萬次以上，所以判斷不是攻擊。 # 做了哪些改善 1. 馬上先把 Middleware 流量導到 ReadOnly DB，即刻見效——RW DB CPU 緩解，站台恢復正常 後續還會接著調整： 1. 從 Token 取得 UserId，取得 DB Token 的 Where 條件改用 UserId，比對 Token 與 Header 是否一致... ( 後續安全檢查 ) 有了這個之後，我認為暫時不用先放 MemoryCache。因為改動較多（後台有些功能可以踢會員下線），做這個改動影響範圍大，但效益不高。 2. 用 ReadOnly DB -> 後續有改回來喔，真正重要的還是第一點，取出 Token 成本太高，造成效能瓶頸，因為 ReadOnly DB 會有 1 ~ 2 秒同步時間，會導致登入後，Token 沒驗證過，沒驗證過可能會讓前端嘗試 Refresh Token，避免後續更多麻煩，就把它改回去了 3. 後面還是有做 Memory Cache 層，15 秒快取，減緩直接進 DB 的次數 整體成本低，我認為足夠。 # 記取教訓，之後設計登入驗證會這樣做  好險在下班前解決~~~萬幸！