接入層session設計原則： 1、Session—讀寫請求使用的上下文對象，稱之會話。 業務總有狀態的：用戶下單購買、登錄狀態、好友狀態、消息發送情況等； 這些有狀態的信息隨用戶操作變化。 單機環境下： 集群設計： --session複製： 所有接入層伺服器之間同步session數據； 每台接入服 ...
接入層session設計原則：
1、Session—讀寫請求使用的上下文對象，稱之會話。
業務總有狀態的：用戶下單購買、登錄狀態、好友狀態、消息發送情況等；
這些有狀態的信息隨用戶操作變化。
單機環境下：
- 不存在session共用問題；
- 處理簡單；
- session保存在記憶體；
- 高可用不能保證（進程掛掉、宕機、session丟失不可用）。
集群設計：
--session複製：
所有接入層伺服器之間同步session數據；
每台接入伺服器都保存用戶全量的session數據；
用戶只需訪問一臺機器，獲取速度快；
高可用保障：宕機部分機器，沒影響。
問題：
--適用於接入層集群較少，不適量大量上千台接入層伺服器；
--大量session複製，占用伺服器和網路資源；
--存儲全量用戶session，記憶體占用量太大，甚至有可能溢出；
大型設計：
session綁定：
根據用戶請求(UID\Mac\imei等唯一標示)負載均衡到特定接入層服務務器；
部分網站使用；
高可用如何保障：單點問題、複製機制（master-slave）
多機設計：
客戶端保持 session：
--session由服務端生成，存儲到客戶端；
--每次請求攜帶客戶端session；
--服務端若有更新返回給客戶端存儲；
C/S：
--APPS：記錄到Native中；
B/S:
--Web：記錄到Cookie中。
缺點：
Web Cookie記錄信息大小限制（如100KB）；
每次請求都要傳輸session：流量、性能受影響；
用戶關閉、清理掉session，用戶請求不正常；
優點：
方案簡單，支持服務端的無縫伸縮；
方案可用性高；
較多網站使用；
Session高可用集群：
--接入層無狀態化；
--統一的高可用session分散式讀寫伺服器集群；
--狀態分離：
接入層本身無狀態；
session集群有狀態：
分散式緩存（NoSQL—memcached/Redis, RDBMS—Mysql/MongoDB）
接入層安全性：
接入層是客戶端和服務端的Interface；
數據安全重要性不言而喻；
保證數據安全性：連接通道加密、傳輸數據加密。
客戶端與服務端建立安全通道—技術方案：
所有請求數據都加密，提高效率；使用對稱加密演算法；
對稱加密密鑰使用非對稱加密演算法經過兩次協商確定；
安全通道的建立必須滿足：
任何第三方無法偽造伺服器；
在破解客戶端代碼的情況下，即使截獲其他用戶發送的加密請求也無法解密。
使用HTTPS：
數據安全的加密；
不推薦單向加密；使用雙向加密（安全）
客戶端證書
數據加密目的：
解決數據明文的問題；
即使截獲也無法解密；
無法保證數據篡改；
如何保證數據正確性：
數據簽名：雙方約定規則簽名（md5sum、其他）
過程：
- 客戶端按照約定簽名；
- 服務端收到數據，按照規則生成md5sum值；
- 和數據包里md5sum值比較是否一致；
- 一致說明沒問題；不一致則說明被改
高可用接入層最佳實踐：
模塊與數據分離；
session綁定：每個session同步複製；
