apache tomcat負載均衡總結

1  proxy、proxy_blancer和mod_jk的比較

• proxy的缺點是，當其中一臺tomcat中止運行的時候，apache仍然會轉發請求過去，致使502網關錯誤。可是隻要服務器再啓動就不存在這個問題。
• mod_jk方式的優勢是，Apache 會自動檢測到中止掉的tomcat，而後再也不發請求過去。
  缺點就是，當中止掉的tomcat服務器再次啓動的時候，Apache檢測不到，仍然不會轉發請求過去。
  
• proxy和mod_jk的共同優勢是.能夠只將Apache置於公網，節省公網IP地址資源。
  能夠經過設置來實現Apache專門負責處理靜態網頁，讓Tomcat專門負責處理jsp和servlet等動態請求。
  共同缺點是：若是前置Apache代理服務器中止運行，全部集羣服務將沒法對外提供。
• proxy和mod_jk對靜態頁面請求的處理，均可以通設置來選取一個儘量優化的效果。
  mod_proxy_balancer和mod_jk都須要修改tomcat的配置文件配合
  <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
• 這三種Tomcat集羣方式對實現最佳負載均衡都有必定不足，mod_proxy_balancer和mod_jk相對好些，mod_jk的設置能力更強些。lbfactor參數來分配請求任務。
• apache自帶mod_proxy功能模塊中目前只能夠實現兩種不一樣的負載均衡集羣實現方式，第一種是分工合做的的形式，經過各臺主機負責不一樣的任務而實 現任務分工。第二種是不一樣的機器在擔任一樣的任務，某臺機器出現故障主機能夠自動檢測到將不會影響到客戶端，而第一種卻不能實現但第一種實現方式的優勢在 於他是主服務器負擔相應沒第二種大由於臺只是提供跳轉指路功能，形象的說他不給你帶路只是告訴你有條路能夠到，但到了那是否能夠看到你見的人他已經不會去管你了。相比之下第二種性能要比第一種會好不少；但他們都有個共同點都是一託N形式來完成任務的因此你的主機性能必定要好

2 session同步

• 對於tomcat的集羣有兩種方式，這個主要是針對session而言的。一種就是sticky模式，即黏性會話模式；另一種就是session複製模式了。

   2.1 sticky模式

• 利用負載均衡器的sticky模式的方式把全部同一session的請求都發送到相同的Tomcat節點。這樣不一樣用戶的請求就被平均分配到集羣 中各個tomcat節點上，實現負載均衡的能力。這樣作的缺點是沒有災難恢復的能力。一旦一個節點發生故障，這個節點上全部的session信息所有丟 失；
• 這種方式實際上是由前端balancer實現的，基本不須要webServer作任何改動（只須要修改jvmRoute="tomcat1"）
• 同一用戶同一session只和一個webServer交互，一旦這個webserver發生故障，本次session將丟失，用戶不能繼續使用

  2.2 複製模式

• 利用Tomcat session複製的機制使得全部session在全部Tomcat節點中保持一致。當一個節點修改一個session數據的時候，該節點會把這個 session的全部內容序列化，而後廣播給全部其它節點。這樣當下一個用戶請求被負載均衡器分配到另一個節點的時候，那個節點上有完備的 session信息能夠用來服務該請求。這種作法的問題是對session哪怕有一點點修改，也要把整個sessions數據所有序列化 （serialize），還要廣播給集羣中全部節點，無論該節點到底需不須要這個session。這樣很容易會形成大量的網絡通訊，致使網絡阻塞。通常採 用這種方式，當Tomcat節點超過4個時候，整個集羣的吞吐量就不能再上升了；
• 此方式是經過tomcat自己提供的功能，只須要修改server.xml文件
  （1）修改Engine節點信息： <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
  （2）去掉<Cluster> <\Cluster> 的註釋符
  （3）web.xml中增長 <distributable/>

   2.3 Terracotta模式

• 另外一種方式就是利用開源軟件Terracotta。Terracotta的基本原理是對於集羣間共享的數據，當在一個節點發生變化的時 候，Terracotta只把變化的部分發送給Terracotta服務器，而後由服務器把它轉發給真正須要這個數據的節點。這樣對網絡的壓力就很是小， 各個節點也沒必要浪費CPU時間和內存進行大量的序列化操做。把這種集羣間數據共享的機制應用在session同步上，至關於對tomcat第二種集羣實現 機制進行了優化，既避免了對數據庫的依賴，又能達到負載均衡和災難恢復的效果。在對比測試中，採用Terracotta搭建Tomcat集羣，節點達到8 個時候，整個集羣的吞吐量還一直是線性增加的。

   2.4 三種模式比較

• sticky模式最大的缺點就是不支持failover，一旦某一個webServer發生故障則此節點上的session就會丟失，所以不建議使用。
• 複製模式能夠保證個別節點發生故障不丟失session，可是複製時須要序列化數據這會影響到系統的性能。
  另外性能隨着服務器增長急劇降低，並且容易引發廣播風暴。經測試當Tomcat節點超過4個時候，整個集羣的吞吐量就不能再上升了。
  須要修改server.xml和web.xml文件
• 使用第三方軟件Terracotta進行session同步，配置對原來的web應用徹底透明，原有程序不用作任何修改。。
  數據不須要序列化，也不佔用webServer的內存，執行效率高。
• terracotta自己支持HA，增長了系統的穩定性。
• Terracotta是開源的，而且能夠集成在不少主流的開源軟件中，如Jetty、Tomcat、Spring、Geronimo和EHCache等。

 以上內容都摘抄至：http://www.cnblogs.com/leader_89/archive/2011/08/01/2109181.html

下面來講寫本身的認識：

我的感受seession複製在一些小應用的範圍仍是可採用的，可是當集羣到必定的數據量這種方案就不可取了。當數據量大時，網絡開銷也會隨着大，同步效率就會隨之下降。

解決方案：

當集羣到了必定的數量後咱們能夠採用統一用cache管理Session的方式

 1，Memcached Session Manager 採用Memecached來統一管理Session，由於Memcached是分佈式的，因此Memcached的量也能夠隨意橫向拓展。（）

2，tomcat-redis-session-manager （採用Redis來維護Session，目前不清楚有哪些人用了這個方案）

3，採用Client Cookie來維護Session，目前不少網站都是採用的這種方案(oschina,iteye,tieba....)

ps:最近本身弄了一個Client Cookie維護Session的列子，準備過幾天發上來和你們交流交流（最近整理好了，地址點這裏）