CND cache 引起的小程式使用者資訊錯亂的線上問題彙總
問題描述
在某個小程式中，高頻請求場景下會導致使用者登陸後出現串號的情況，即我自己的賬號登陸顯示別人的資訊，問題嚴重影響到線上的使用者體驗，下面講一下我們這次心酸的排故之旅！
故障現象1：我們通過多個測試號的故障復現進行分析，發現每次出現錯亂賬號的資訊大部分都是同一個人的資訊，而且時間點都集中在晚上功能高頻使用的時間段
故障現象2：通過後臺日志分析，每次出現串號現象之前，串號的人的請求日誌必現，卻在故障發生後，發生的過程中，查不到該使用者相關的請求資訊（奇怪）
故障現象3：通過postman請求使用者資訊介面，同樣出現真機模擬的串號問題問題程式碼
@ApiOperation(value = "獲取當前使用者資訊", httpMethod = "GET")
@GetMapping
public ConsumerUserRepresentation getUserInfo() {
return consumerUserApplicationService.getUserInfo();
}問題思考
根據現象1推測：有可能是高併發引起的介面呼叫資料錯亂
解決方式：在使用者資訊介面上我們新增了併發鎖，嘗試阻止併發請求，但是問題依舊。。。
根據現象2推測：有可能是沒有通過後臺返回資料，而直接查詢快取，但是後臺程式碼並沒有設定快取機制，那麼問題來了，如果是命中快取，快取資料從何而來？？？
根據現象3推測：排除是前端快取原因導致的串號問題解決
通過各種嘗試，排除法，最終我們定位到快取的來源---CDN cache 下面是postman模擬請求的資料對比：X-Cache-Lookup:Hit From MemCache 表示命中CDN節點的記憶體
X-Cache-Lookup:Hit From Disktank 表示命中CDN節點的磁碟
X-Cache-Lookup:Hit From Upstream 表示沒有命中CDN
未命中快取，正常請求
命中快取，取快取資料，資料錯亂
通過postman我們可以看到，正常資料和異常資料的請求頭中標識了是否命中CDN cahce的標籤，通過對比，我們最終判斷出是通過CDN cache取到的快取資料，那麼請求什麼會走cache，什麼時候走cache，什麼時候回源請求介面呢？以下是關於CDN cache的討論，在此不做贅述。附上鍊接如下：
CDN概述
genie88.github.io/2015/11/03/talk-a...
CDN加速原理
www.huaweicloud.com/zhishi/cdn001....
修復
本作品採用《CC 協議》，轉載必須註明作者和本文連結