分布式session的幾個問題？會話的本質(zhì)是前端存儲一個ID，后端根據(jù)這個ID識別會話并訪問數(shù)據(jù)。僅此而已。至于如何保存ID，你可以把它放在URL后面，放在cookie中，甚至放在header中。R在

分布式session的幾個問題？

會話的本質(zhì)是前端存儲一個ID，后端根據(jù)這個ID識別會話并訪問數(shù)據(jù)。僅此而已。至于如何保存ID，你可以把它放在URL后面，放在cookie中，甚至放在header中。R在我看來，只要使用這種模式，就叫做session，但是ID（token）的實現(xiàn)是不同的。會話的缺點是將數(shù)據(jù)保存在何處。由于需要保存，所以在分發(fā)時必須保證會話的一致性。R至于JWT，說白了就是一根弦。重點是，當(dāng)您轉(zhuǎn)到會話時，服務(wù)器不會保存它，而是直接在字符串中寫入必要的信息。優(yōu)點很明顯，缺點也很明顯。服務(wù)器失去對令牌的控制。如何退出函數(shù)？在服務(wù)器上添加黑名單？這樣既不閑置，又遇到保存的問題，何不直接使用session呢？我認為會話是未來。如果服務(wù)器不保存證書，它將失去對令牌的控制。無論如何，弊大于利。至于會話一致性，統(tǒng)一授權(quán)中心訪問是可以的。這不是問題。R

對于一般的中小型應(yīng)用，會話存儲可以滿足項目的需要。一旦應(yīng)用程序訪問量增加，數(shù)據(jù)庫中會話的頻繁讀寫很容易給系統(tǒng)帶來瓶頸。

是的。

實現(xiàn)會話互通；

，頻繁讀寫會話不會帶來性能壓力；]；

可以記錄每個用戶的會話ID，這樣就可以找到一個注冊用戶的所有會話ID，方便實現(xiàn)登錄功能。