電商課題VI：分布式Session

@鄭昀匯總與分布式緩衝在高並發和高可用下所要解決問題差不多。 一.圖示：  二.高並發下分布式Session需解決的問題：

• 透明處理儲存介質的容錯移轉
• 動態增刪節點，減小“緩衝顛簸”問題
• 保證資料在各個節點的分布均衡
• Session 序列化和還原序列化

  三.保證“基本可用 Basically Available”的分布式Session方案：Eric A. Brewer 在 1988 年提出的 BASE 策略，即 Basically Available、Soft state、和Eventually consistent。互連網大多數應用更強調可用性，即犧牲高一致性，獲得可用性或可靠性。 

基本可用 Basically Available 的定義：在分布式系統部分損壞的時候，允許部分內容不可用，但是其他部分仍舊可用。因此稱這種系統為“基本可用”。比如，一個資料存放區系統由 五個節點構成。其中一個發生了損壞，這時只有20%的資料不能訪問，其他80%資料仍然可用。那麼就可以稱這種系統為基本可用的。

 基於 memcache 的  Hash模數演算法（hash() mod n，hash() 取使用者ID，n為節點數） 實現的分布式 Session 方案，就屬於基本可用：

第一，如果節點發生故障，該節點上的所有使用者 Session 丟失，系統無法自恢複。第二，如果系統壓力突然增大，需要臨時增加機器節點。按照 Hash模數的演算法，在增加機器節點的這一時刻，大量緩衝無法命中（其實還都存在之前的節點上），導致大範圍的緩衝穿透，壓力會直接打到資料庫上。第三，根據 LRU 緩衝失效演算法，memcache 裡儲存的 key/value 有可能被踢出，使用者 Session 容易丟失。

 針對 Hash模數 的改進辦法是： 四.基於一致性雜湊演算法的 memcache 解決方案1）一致性雜湊幫我們解決的是，當機器節點減少時，快取資料能進行最少重建。2）還能解決 Session 資料的分布均衡問題。3）當機器節點宕機，這部分資料必然丟失。由於節點數目變化，有可能對部分沒有丟失的資料也要重建。 但上面的方案都解決不了“一個節點失敗後，它所儲存的 Session 如何由其他節點擷取以便接替失效節點，實現叢集的容錯（Failover）”。鄭昀先介紹下面幾個概念： 五.Sticky Session、Non-sticky Session和Replicated Sessions

• Sticky Sessions：粘性會話。即同一個會話中的請求必須被轉寄到同一個節點上，除非該節點宕機才轉寄到容錯移轉節點。一個節點宕機，所儲存的 Sessions 完全丟失。通俗的話就是，將使用者“粘”在某一個伺服器節點上。
• Non-Sticky Sessions：非粘性會話。每一次請求都可能轉寄到不同節點。
• Replicated Sessions：把一個節點上的 Sessions 複製到叢集的其他節點上，防止資料丟失，允許失效無縫轉移。如node 0複製到node 5，node 1複製到node 6，以此類推。多數應用伺服器（如 Tomcat ）都支援會話複製機制。

 當使用者數量和叢集數量達到一定規模後，Session 複製就可能成為效能瓶頸。於是人們提出了  從第三方緩衝恢複失效節點資料 的方案，開源產品 Memcached-Session-Manager（下面簡稱MSM）就是基於這個思想。 六.MSM的工作原理MSM 支援 Tomcat 6 和 7，即它主要解決的是 Tomcat 的高可用性。它的特性為：

• 支援 sticky sessions 和 non-ticky sessions 模式。
• 沒有單點故障。
• 能處理 tomcat 容錯移轉
• 能處理 memcache 容錯移轉
• pluggable session serialization
• 允許非同步儲存 session，提高響應速度
• sessions 只有真正被修改時，才會發給 memcache

  6.1.Sticky Session 模式下的工作原理即， Tomcat 的本地 session  為主 session，memcache 中的 session 為備 session。

第一步，所有 Tomcat 節點都需要安裝 MSM；每一個 Tomcat 會有自己的本地 session。第二步，當一個請求執行完畢之後，如果對應的 session 在本地不存在（即這是某一個使用者的第一次請求），則將該 session 複製一份至 memcache 。第三步，當該 session 的下一個請求到達時，會使用 Tomcat 的本地 session。請求處理結束之後，session 的變化會同步更新到 memcache，保證資料一致。第四步，如果當前 Tomcat 節點失效，下一個請求會被路由給其他 Tomcat。這個 Tomcat 發現請求所對應的 session 並不存在，於是它將查詢 memcache，如果查詢到了，則恢複到本地 session。

這樣就完成了容錯處理。  6.2.Non-sticky Session 模式下的工作原理即， Tomcat 的本地 session  為中轉 session，memcache 1 為主 session，memcache 2為備 session。

第一步，收到請求，載入備 session 到本地容器；

備 session 載入失敗，則從主 session 載入；

第二步，請求處理結束之後，session 的變化會同步更新到 memcache 1和 memcache 2，並清除Tomcat 的本地 session 。

 session data 要想存入 memcache，必須能序列化和還原序列化。 七.基於 kryo 的序列化方案所有序列化策略都必須提供下面的特性：

• 序列化：能處理循環參考。
• 序列化/還原序列化：支援對一個共用對象（Shared Object）的引用。
• 還原序列化：支援 private classes 。
• 還原序列化：支援沒有預設建構函式的類。

下面是 MSM Wiki 所列出的表格：

Serialization Strategy  Value for transcoderFactoryClass attribute	Requires  java.io.Serializable	Cyclic Dependencies	Shared objects	Private classes	Classes without default constructor	Different class versions	Copy Collections  before serialization	Custom  Converter	Comment
java serialization(default, bundled with msm)  de.javakaffee.web.msm.JavaSerializationTranscoderFactory	Yes	Yes	Yes	Yes	Yes	No (Though,  if the serialVersionUID is set to 1L,  classes can be deserialized  even if the new class version has new fields)	No	No
msm-kryo-serializer  de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory	No	Yes	Yes	Yes (for Sun JVMs)	Yes (for Sun JVMs)	No (not yet)	Yes	Yes (Converter must extend KryoCustomization, SerializerFactory or UnregisteredClassHandler)	Reflection based, Kryo is used for binary serialization/deserialization
msm-javolution-serializer  de.javakaffee.web.msm.serializer.javolution.JavolutionTranscoderFactory	No	Yes	Yes	Yes (for Sun JVMs)	Yes (for Sun JVMs)	Yes (During deserialization, fields that are not existing in a class are ignored)	Yes	Yes (Converter must extend [apidocs/javolution/xml/CustomXMLFormat.html CustomXMLFormat])	Reflection based, Javolutionis used for actual xml encoding/decoding, it also does the object reference handling

MSM 作者的觀點是：

1. Java serialization 是一個魯棒性非常好、也被廣泛證明了的技術，但 IMHO（恕我直言），它最大問題就是無法處理類的版本：向下相容時新版本如何還原序列化老版本序列化的資料流，如還要向上相容的話老版本如何還原序列化新版本序列化的資料流。為了確認相容性，測試量將是版本數的平方。
2. Kryo 是一個非常快的二進位序列化庫。在 thrift 與 protobuf 的效能 benchmark 中，kryo 也是最快的序列化工具庫之一。他推薦使用 Kryo ，就是因為超凡的效能。

  八.基於 ZooKeeper 叢集的分布式 Session 方案要解決基於 memcache 方案的資料丟失問題，可以引入持久化儲存介質 ZooKeeper（下面簡稱 ZK）。依託於 ZK 的一致性複製（在多個副本間保證資料的強一致性）和容錯能力，結合上面的 MSM 思想，由 ZK 負責 session 資料的儲存，而我們自己實現的 session manager 將負責 session 生命週期的管理。  九.微軟系的解決方案ASP.NET 有自己的分布式 Session 解決方案，Session State Server ，即 web.config 裡指定 sessionState 的 mode 為“StateServer”即可。鄭昀既可以在 web.config 裡指定一個 State Server ：也可以實現 System.Web.IPartitionResolver 的介面，自行決定如何構造 Session State Server 連接字串，從而支援一組 State Servers。鄭昀也可以用 sessionState 的 partitionResolverType 屬性設定即可：微軟的這個解決方案缺點是，Session State 中的序列化和還原序列化對象將成為主要效能消耗之一，最好使用基本類型來儲存所有的 Session State 資料。
參考資源：1） 開原始碼，http://code.google.com/p/memcached-session-manager2） jacktan，2011，基於ZooKeeper的分布式Session實現3） Maarten Balliauw，2008，ASP.NET Session State Partitioning4）timyang，2009，某分布式應用實踐一致性雜湊的一些問題5）構建一個高效無單點故障的分布式session服務7）developerWorks，2010，關於 Java 對象序列化您不知道的 5 件事