session一致性的要求是如何產(chǎn)生的？會話一致性問題的原因是：當(dāng)服務(wù)部署到多個服務(wù)器（如a、B服務(wù)器同時部署啟動）時，當(dāng)前端通過nginx等負(fù)載均衡中間件第一次請求后臺。如果nginx通過輪換訓(xùn)練請

session一致性的要求是如何產(chǎn)生的？

會話一致性問題的原因是：當(dāng)服務(wù)部署到多個服務(wù)器（如a、B服務(wù)器同時部署啟動）時，當(dāng)前端通過nginx等負(fù)載均衡中間件第一次請求后臺。如果nginx通過輪換訓(xùn)練請求服務(wù)器（即，如果第一個請求訪問服務(wù)器a，下一個請求將訪問服務(wù)器B），那么下次您訪問服務(wù)器a時，您可以在保存密碼后訪問服務(wù)器a。此時，會話將保存在服務(wù)器a上。下次訪問服務(wù)器B時，可以通過nginx polling訪問服務(wù)器B。此時，您發(fā)現(xiàn)在服務(wù)器B上找不到與用戶登錄對應(yīng)的會話信息，因此需要請求用戶重新登錄（實(shí)際使用nginx）用戶登錄信息的會話保存在服務(wù)器a上。在這種情況下，如果會話不同，則需要考慮使會話保持一致。這就是會話一致性的問題！具體的解決方案有很多，比如MySQL數(shù)據(jù)庫和redis緩存數(shù)據(jù)庫。我在這里不詳細(xì)說明。具體的解決方案可以在其他相關(guān)的博客中找到。理論上，如果你得到一個cookie，你就可以模仿一個用戶。根據(jù)以下具體分析：

此“身份密碼”由服務(wù)器生成并放置在客戶端瀏覽器的cookie中。服務(wù)器將有一個與之對應(yīng)的會話，會話ID也存儲在cookie中。

如上所述，服務(wù)器的會話ID存儲在客戶端的cookie中，以便其他用戶在cookie中獲得會話ID后，可以模擬原始用戶啟動請求。

這似乎不合理

！但是，這是cookies和會話的機(jī)制。我們說過當(dāng)cookie被禁用后，session可能無法正常工作，但是我們可以通過get將sessionid傳遞給服務(wù)器，因此如果sessionid以明文形式傳輸，則存在安全風(fēng)險。

由于cookie存儲在客戶機(jī)中并且不安全，因此當(dāng)我們將用戶數(shù)據(jù)存儲在cookie中時，我們將對其進(jìn)行加密。例如，它將驗(yàn)證用戶的IP、終端身份等，即使其他用戶偽造Cookie，也無法驗(yàn)證。