網際網路一致性架構設計 -- session一致性
session是什麼
伺服器為每個使用者建立乙個會話，儲存使用者的相關資訊，以便多次請求能夠定位到同乙個上下文。
web開發中，web-server可以自動為同乙個瀏覽器的訪問使用者自動建立session，提供資料儲存功能。最常見的，會把使用者的登入資訊、使用者資訊儲存在session中，以保持登入狀態。
什麼是session一致性問題
當只有一台web-server提供服務時，每次http短連線請求，都能夠正確路由到儲存session的對應web-server。
架構變遷
此時的web-server是無法保證高可用的，採用「冗餘+故障轉移」的多台web-server來保證高可用時，每次http短連線請求就不一定能路由到正確的session了。
假設使用者包含登入資訊的session都記錄在第一台web-server上，反向**如果將請求路由到另一台web-server上，可能就找不到相關資訊，而導致使用者需要重新登入。
在web-server高可用時，如何保證session路由的一致性？
保證session一致性的方法
session同步法
多個web-server之間相互同步session，這樣每個web-server之間都包含全部的session。
優點
缺點
客戶端儲存法
服務端儲存所有使用者的session，記憶體占用較大，可以將session儲存到瀏覽器cookie中，每個端只要儲存乙個使用者的資料了。
優點
缺點
反向**hash一致性
web-server為了保證高可用，有多台冗餘，反向**層能不能做一些事情，讓同乙個使用者的請求保證落在一台web-server上。
方案一：四層**hash
反向**層使用使用者ip來做hash，以保證同乙個ip的請求落在同乙個web-server上。
方案二：七層**hash
反向**使用http協議中的某些業務屬性來做hash，例如sid，city_id，user_id等，能夠更加靈活的實施hash策略，以保證同乙個瀏覽器使用者的請求落在同乙個web-server上。
優點
缺點
後端統一儲存
將session儲存在web-server後端的儲存層，資料庫或者快取。
優點
缺點
建議
1. 對於db儲存還是cache，個人推薦後者：session讀取的頻率會很高，資料庫壓力會比較大。如果有session高可用需求，cache可以做高可用，但大部分情況下session可以丟失，一般也不需要考慮高可用。
2. web層、service層無狀態是大規模分布式系統設計原則之一，session屬於狀態，不宜放在web層。
網際網路一致性架構設計 DB雙主一致性
網際網路一致性架構設計 db雙主一致性 mysql資料庫集群常使用一主多從，主從同步，讀寫分離的方式來擴充資料庫的讀效能，保證讀庫的高可用，但此時寫庫仍然是單點。解決方法 在乙個mysql資料庫集群中可以設定兩個主庫，並設定雙向同步，以冗餘寫庫的方式來保證寫庫的高可用。需求分析 資料冗餘會引發資料的...
網際網路一致性架構設計 DB和Cache一致性
網際網路一致性架構設計 db和cache一致性 需求分析 下面兩種情況會出現髒資料 單庫情況下 服務層的併發讀寫，快取與資料庫的操作交叉進行，這種情況雖然少見，但理論上是存在的，後發起的請求b在先發起的請求a中間完成了。1.請求a發起乙個寫操作，第一步淘汰了cache，然後這個請求因為各種原因在服務...
關於網際網路「一致性」架構設計的一切
前篇 都收到好評 本文再做總結，體系化介紹網際網路一致性架構技術。一 session一致性 文章 session一致性，架構設計，實踐 內容 二 資料庫主從一致性 文章 資料庫主從一致性，架構設計，實踐 內容 三 資料庫雙主一致性 文章 資料庫雙主一致性，架構設計，實踐 內容 四 資料庫與快取一致性...