《緩存，究竟是淘汰，還是修改?》發出后，有朋友提到，高并發的情況下，緩存的更新可能存在問題，今天簡單聊聊這個話題。

[[235679]]

業務場景：

• 調用第三方服務，例如微信，一般會分配一個token，每次訪問接口需要帶上這個token;
• 這個token是有有效期的，當token過期時，需要去重新認證申請;
• 也可以在token過期前重新申請，但此時舊token會失效。

常見實現方式，如圖：

• 把token放在緩存中，每次帶上token去調用接口;
• 如果token過期，需要去申請新token;
• 申請完新token，需要把新token更新到緩存里。

高并發下可能存在的問題，如圖：

• 取舊token，訪問接口，發現token過期;
• 并發請求，取舊token，訪問接口，也發現token過期;
• 去申請新token1;
• 并發申請新token2(此時token1會過期);
• 把token1放入緩存，同時使用token1訪問接口(此時token1已經過期)，發現token1過期，可能會遞歸申請新token3(此時token2過期);
• 把token2放入緩存，同時使用token2訪問接口(此時token2已經過期)，發現token2過期，可能會遞歸申請新token4(此時token3過期);
• …

額，高并發請求導致相互失效。

常見解決方案，如圖：

• 線上s1和s2只從緩存讀取token
• 更新token異步，asy-Master定期更新token，避免并發更新
• 使用shadow-master保證token更新高可用，asy-Master掛了，asy-Backup頂上

潛在缺點：

• s1/s2/asy-master直接調用同一個緩存實例，如果緩存實例變更，可能需要同步變更，導致耦合。

潛在優化：

• asy-Master利用多線程，實現在s1/s2里，保證高可用;
• redis里用一個時間戳表示token的更新時間，更新token時，查看token的時間戳，如果token剛更新過，并發的請求便不再更新。

文字雖短，希望問題描述清楚了，希望大家有收獲。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文