併發更新的坑指在併發更新快取的時候，會出現併發更新的異常問題。導致與預期結果不一致，有的甚至會導致應用短時間不可用。
常見實現方式如下：（對應下面case1和case2）
獲取access-token，如果存在則呼叫介面
實現方式二：（對應下面case3）
case3：無限遞迴獲取token
（1）取舊token，訪問介面，發現token過期；
（2）併發請求，取舊token，訪問介面，也發現token過期；
（3）去申請新token1；
（3）併發申請新token2(此時token1會過期)；
（4）把token1放入快取，同時使用token1訪問介面(此時token1已經過期)，發現token1過期，可能會遞迴申請新token3(此時token2過期)；
（5）把token2放入快取，同時使用token2訪問介面(此時token2已經過期)，發現token2過期，可能會遞迴申請新token4(此時token3過期)；
併發更新導致了資料更新異常，順序的**邏輯被併發的更新打亂了。
分布式鎖
參考主流的分布式鎖方案，比如redis分布式鎖，或者zookeeper分布式鎖，在更新前上鎖，更新後釋放鎖。
同步併發更新 進化為 單執行緒非同步更新
a. 線上s1和s2只從快取讀取token
b. 更新token非同步，asy-master定期更新token，避免併發更新
c. 使用shadow-master保證token更新高可用，asy-master掛了，asy-backup頂上
高併發請求的快取設計策略
1.為何需要快取?在高併發請求時，為何我們頻繁提到快取技術?最直接的原因是，目前磁碟io和網路io相對於記憶體io的成百上千倍的效能劣勢。做個簡單計算，如果我們需要某個資料，該資料從資料庫磁碟讀出來需要0.1s，從交換機傳過來需要0.05s，那麼每個請求完成最少0.15s 當然，事實上磁碟和網路io...
高併發系統設計（三）快取 未完
廣義上講，凡是位於速度相差較大的兩種硬體之間，用於協調兩者資料傳輸速度差異的結構，均可稱之為快取 是一種常見的空間換時間的效能優化手段 快取區是用於彌補高速裝置和低速裝置通訊時的速度差。一塊臨時儲存資料的區域，這些資料後面會一次性傳輸到其他裝置上 系統複雜度 資料不一致 運維 記憶體有限，比較適合讀...
Redis 快取的坑
這幾天一直在做redis 快取，中間遇到很多錯誤，把網上的部落格都看一大半了，甚至開始懷疑是springboot 框架有問題出毛病了 對，就是他的錯，誰讓他報我的錯？他先動得手 後來發現是自己太蠢了，寫下來記錄記錄這個差點讓我放棄人生的蠢動作。redis快取的序列化器 網上看了很多的關於序列化的部落...