參考資料:
Shared Nothing Architecture與PHP的童話
Shared Nothing Architecture
?? 以往集群架構都采用Session共享模式進行設計，而后PHP等方面提出了SNA架構，主張Session不共享。SNA架構思想，無論對企業應用還是大型互聯網站，極大提高了web應用的吞吐量和性能。
?? 一般SNA架構以集成分布式Cache例如 memcached 的方案居多，此處姑且稱為 Cache模式。
?? 我結合公司電信項目的情況，以及思考，總結另一種方案，供參考。
?? SNA思想的關鍵就是每個集群內web server實例不互相共享session，Cache模式主張session數據都放到分布式緩存中，意味著，邏輯上集群內還是要共享session信息；這種考慮源于負載均衡時，同一個IP發來的兩個請求，可能走到不同的 Web Server上。
?? 因此，只要同一IP的兩個請求轉發到同一個 Web? server實例，那么就可以不需要全局的 session信息緩存。
?? 1) 我所在的移動項目下，采用 F5硬件負載均衡器，使用IP記憶機制實現了這一點。因此，各 web server實例的session無需共享，仍然保存在自己的session內存中，節省了網絡開銷和Cache命中查找時間。
?? F5很貴，因此對于網站一般負擔不起，但可以采用軟件負載來做到這一點。
?? 切分模式的SNA架構：
?? 2) IP Memory(IP記憶)：負載服務器記錄 客戶端IP -> ServerID 的關系，模擬F5；
?? 3) (Dispatch by Rule)按規則轉發：IP記憶需要維護一張路由table， 因此，需要消耗一定內存，以及映射關系查找的時間；
????? 我們將客戶端的所有IP看作一個集合 IP Set，按固定規則將其平均分配集群的server實例上去，這樣就可以節省路由table的開銷。 關鍵是分配算法，可以考慮的有：
????? 2.1) 簡單數值法： IP各節加總 = X, 假定集群實例個數為 N，編號1-N， 那么每次請求選擇的目標server id = X mod N。
????? 2.2) hash值法： 有的系統可能想基于 userid 進行請求分配， 那么可以采用 X = hashCode(userid), serverID = X mod N;
????? 具體情況下， 可以靈活選擇使用那個數據項判斷請求分配的邏輯。這個思想參考了? memcached 的集群管理思想。
???
?? 4) stickySession方式。
????? 一般apache等采用這種方式做負載均衡。但必須結合 jvmRoute。 第一次被分配的 web server必須返回一個 jvmRoute在response中，并由 apache 送到客戶端瀏覽器，第二次請求發起時，request信息中將包含 JSESSIONID 和 對應的 jvmRoute， apache根據次找到對應的 server，完成 stickySession機制。
結論： 切分模式的SNA架構，基于規則進行請求轉發，可以省去分布式Cache的使用，更進一步的提升系統吞吐量和響應性。
Shared Nothing Architecture與PHP的童話
Shared Nothing Architecture
?? 以往集群架構都采用Session共享模式進行設計，而后PHP等方面提出了SNA架構，主張Session不共享。SNA架構思想，無論對企業應用還是大型互聯網站，極大提高了web應用的吞吐量和性能。
?? 一般SNA架構以集成分布式Cache例如 memcached 的方案居多，此處姑且稱為 Cache模式。
?? 我結合公司電信項目的情況，以及思考，總結另一種方案，供參考。
?? SNA思想的關鍵就是每個集群內web server實例不互相共享session，Cache模式主張session數據都放到分布式緩存中，意味著，邏輯上集群內還是要共享session信息；這種考慮源于負載均衡時，同一個IP發來的兩個請求，可能走到不同的 Web Server上。
?? 因此，只要同一IP的兩個請求轉發到同一個 Web? server實例，那么就可以不需要全局的 session信息緩存。
?? 1) 我所在的移動項目下，采用 F5硬件負載均衡器，使用IP記憶機制實現了這一點。因此，各 web server實例的session無需共享，仍然保存在自己的session內存中，節省了網絡開銷和Cache命中查找時間。
?? F5很貴，因此對于網站一般負擔不起，但可以采用軟件負載來做到這一點。
?? 切分模式的SNA架構：
?? 2) IP Memory(IP記憶)：負載服務器記錄 客戶端IP -> ServerID 的關系，模擬F5；
?? 3) (Dispatch by Rule)按規則轉發：IP記憶需要維護一張路由table， 因此，需要消耗一定內存，以及映射關系查找的時間；
????? 我們將客戶端的所有IP看作一個集合 IP Set，按固定規則將其平均分配集群的server實例上去，這樣就可以節省路由table的開銷。 關鍵是分配算法，可以考慮的有：
????? 2.1) 簡單數值法： IP各節加總 = X, 假定集群實例個數為 N，編號1-N， 那么每次請求選擇的目標server id = X mod N。
????? 2.2) hash值法： 有的系統可能想基于 userid 進行請求分配， 那么可以采用 X = hashCode(userid), serverID = X mod N;
????? 具體情況下， 可以靈活選擇使用那個數據項判斷請求分配的邏輯。這個思想參考了? memcached 的集群管理思想。
???
?? 4) stickySession方式。
????? 一般apache等采用這種方式做負載均衡。但必須結合 jvmRoute。 第一次被分配的 web server必須返回一個 jvmRoute在response中，并由 apache 送到客戶端瀏覽器，第二次請求發起時，request信息中將包含 JSESSIONID 和 對應的 jvmRoute， apache根據次找到對應的 server，完成 stickySession機制。
結論： 切分模式的SNA架構，基于規則進行請求轉發，可以省去分布式Cache的使用，更進一步的提升系統吞吐量和響應性。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
