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

[[235679]]

業(yè)務(wù)場景：

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

常見實現(xiàn)方式，如圖：

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

高并發(fā)下可能存在的問題，如圖：

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

額，高并發(fā)請求導(dǎo)致相互失效。

常見解決方案，如圖：

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

潛在缺點：

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

潛在優(yōu)化：

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

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

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

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