《從單機到集群會話的管理之集群模式一》中講到的全節點復制的網絡流量隨節點數量增加呈平方趨勢增長，也正是因為這個因素導致無法構建較大規模的集群，為了使集群節點能更加大，首要解決的就是數據復制時流量增長的問題，下面將介紹另外一種會話管理方式，每個會話只會有一個備份，它使會話備份的網絡流量隨節點數量的增加呈線性趨勢增長，大大減少了網絡流量和邏輯操作，可構建較大的集群。 下面看看這種方式具體的工作機制，集群一般是通過負載均衡對外提供整體服務，所有節點被隱藏在后端組成一個整體。前面各種模式的實現都無需負載均衡協助，所以圖中都把負載均衡省略了。最常見的負載方式是前面用apache拖所有節點，它支持將類似“326257DA6DB76F8D2E38F2C4540D1DEA.tomcat1”的會話id進行分解，定位到tomcat集群中以tomcat1命名的節點上（這種方式稱為Session?Stick，由apache?jk模塊實現）。每個會話存在一個原件和一個備份，且備份與原件不會保存在同一個節點上，如下圖，例如當客戶端發起請求后通過負載均衡被分發到tomcat1實例節點上，生成一個包含.tomcat1后綴的會話標識，并且tomcat1節點根據一定策略選出此次會話對象備份的節點，然后將包含了{會話id，備份ip}的信息發送給tomcat2、tomcat3、tomcat4，如圖中虛線所示，這樣每個節點都有一個會話id、備份ip列表，即每個節點都有每個會話的備份ip地址。 完成上面一步后就是將會話內容備份到備份節點上，假如tomcat1的s1、s2兩個會話的備份地址為tomcat2，則把會話對象備份到tomcat2中，類似的有tomcat2把s3會話備份到tomcat4，tomcat4把s4、s5兩個對話備份到tomcat3，這樣集群中所有的會話都已經有了一份備份。當tomcat1一直不出故障，由于Session?Stick技術客戶端將一直訪問到tomcat1節點上，保證一直能獲取到會話。而當tomcat1出故障了，這時tomcat也提供了一個failover機制，apache感知到后端集群tomcat1節點被移除了，這時它會把請求隨機分配到其他任意節點上，接下去會有兩種情況： ①剛好分到了備份節點tomcat2上，此時仍能獲取到s1會話，除此之外，tomcat2還要另外做的事是將這個s1會話標記為原件且繼續選取一個備份地址備份s1會話，這樣一來又有了備份。 ②假如分到了非備份節點tomcat3，此時肯定找不到s1會話，于是它將向集群所有節點發問，“請問誰有s1會話的備份ip地址信息？”，因為只有tomcat2有s1的備份地址信息，它接收到詢問后應答告知tomcat3節點s1會話的備份在tomcat2，根據這個信息就能查到s1會話了，并且tomcat3在自己本地生成s1會話并標為原件，tomcat2上的副本不變，這樣一來同樣能找到s1會話，正常完整整個請求處理。 ? 《從單機到集群會話的管理》系列文章從單機到集群分析了web服務器的會話管理的不同模型，包含了單機非持久化、單機文件持久化、單機數據庫（緩存）持久化、集群數據庫（緩存）、集群全節點復制、集群原件副本備份等等。分析了不同模型的工作原理及優點不足，深入理解各種會話管理模式對于實際項目的會話方案選型有很大的幫助。