在早期的時候，很多**由於使用者規模較小，都是採取的單機部署的模式，只用一台伺服器來承載使用者的請求，這時候session是存在同一臺伺服器上，所以能夠很容易實現會話跟蹤和保持。然而隨著使用者規模的擴大，單機部署模式已經無法承載所有使用者的請求了，這時候人們自然而然想到用多台伺服器來處理使用者的請求，使用者的請求會先到達負載均衡，然後再被**到某個具體應用伺服器上進行處理。這時候我們就會遇到乙個問題，每次處理同個使用者的請求的服務可能不同，那怎麼讓它們的session資料保持一致呢？
一般來說有以下四種方案：
我們來乙個乙個了解它們的優劣和使用場景
我們知道cookie總只有乙份的，而且是存在使用者端的，所以我們可以通過cookie來儲存session資訊，這樣不管最後傳送到哪台伺服器處理，我們都能通過cookie取到session資訊。使用這個方案有以下優缺點
優點
缺點
適用場景：資料量小的情況。
也就是粘性session，當使用者訪問負載均衡時，通過某種方法算出該使用者應該訪問的後端伺服器，例如通過hash演算法。這樣保證了每個會話都在同一臺伺服器上。使用這個方案有以下優缺點：
優點
缺點
適用場景：機器數適中、對穩定性要求不是非常苛刻的情況
既然只有一台機器存session容易出現單點問題，那麼我們就所有機器都存session，每台機器間進行session同步，這樣不管訪問到哪台機器都能獲得session。這就是session複製方式，我們給伺服器之間增加了會話資料的同步，通過同步來保證不同伺服器之間的session資料的一致。使用這個方案有以下優缺點：
優點
缺點
適用場景：伺服器比較少且session資料量少
通過單獨的伺服器集群來儲存和管理session資料，例如redis，其他所有的應用伺服器都從這個儲存集群獲取對應的session，從而實現session的共享。
優點
缺點
適用場景：應用伺服器較多、可用性要求較高
每個方案都各有其適用的場景，大家在實際使用過程中需要根據實際情況進行選擇
enjoy it !
如果覺得文章對你有用，可以贊助我喝杯咖啡~
分布式session一致性
在多台後台伺服器的環境下，我們為了確保乙個客戶只和一台伺服器通訊，我們勢必使用長連線。使用什麼方式來實現這種連線呢，常見的有使用nginx自帶的ip hash來做，我想這絕對不是乙個好的辦法，如果前端是cdn，或者說乙個區域網的客戶同時訪問伺服器，導致出現伺服器分配不均衡，以及不能保證每次訪問都粘滯...
分布式SESSION一致性
session是伺服器為客戶端建立的乙個會話，儲存使用者的相關資訊，用以標識使用者身份等。在單伺服器環境下是不需要考慮會話的一致性的問題的，但是在集群環境下就會出現一些問題，假如乙個使用者在登入請求時負載均衡到了a伺服器，a伺服器為其分配了session，下次請求資料時被分配到了b伺服器，此時由於b...
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...