注意以下幾點(diǎn)：（目前只想到這些）
1、往session里邊放的東東要實(shí)現序列化的接口（session復制用）
2、因為session要復制，所以session里邊的東西要盡可能的少，否則可能集群性能還不如單機
3、集群下沒(méi)有真正單例的實(shí)現，所以不要用單態(tài)模式來(lái)保存集群內所有服務(wù)器都需要的狀態(tài)，比如程序的某個(gè)全局變量，可以考慮用jndi來(lái)實(shí)
現。不過(guò)相信好的程序這么做的并不多。
4、同步問(wèn)題也要注意~比如不要試圖用加同步來(lái)實(shí)現取得最大id這樣的操作，可以通過(guò)保存到數據庫的手段來(lái)解決這個(gè)問(wèn)題
5.特別要注意緩存的情況，大部分開(kāi)源的緩存實(shí)現是不支持集群的。這時(shí)候要全面考慮你需要的緩存情況再定奪。比較省事的辦法是不用緩存
（緩存的作用不是任何時(shí)候都很大，比如客戶(hù)查詢(xún)話(huà)費祥單記錄，越加緩存越壞事）。如果對數據實(shí)時(shí)性要求不算高那也好說(shuō)，定期的重建緩
存就是了。如果都不行，只有使用jboss cache等支持集群的cache實(shí)現?；蛘卟捎媚承┥虡I(yè)性的實(shí)現。
------------------------
weblogic的分發(fā)是怎么實(shí)現的：
1、實(shí)現請求的分發(fā)，可以靠硬件（高層交換機），也可以靠weblogic自己。一般的是新建一個(gè)proxy分發(fā)域，然后其中部署一個(gè)proxy應用，利
用weblogic.servlet.proxy.HttpClusterServlet將請求分發(fā)到不同的server。
2、分發(fā)的過(guò)程是這樣的（不管是交換機還是weblogic）:
數個(gè)請求發(fā)過(guò)來(lái)，先判斷一下請求的ip地址，將ip地址相同的發(fā)送到同一臺server,不同的ip根據分發(fā)策略分發(fā)到不同的server.
如果一臺server不可用，請求將不會(huì )發(fā)送至這一臺server.原本發(fā)送至這臺不可用server的請求將被發(fā)送至此server session復制目的地
server.(到底是哪一臺看相應的復制策略)。這樣，客戶(hù)端session也就不會(huì )失效，這一過(guò)程對客戶(hù)是透明的。呵呵，不知道這樣算不算是
failover
------------------------
Web只是EJb的一種客戶(hù)端，RMI/XML-RPC/Web Service/Corba都是EJB企業(yè)應用服務(wù)器的客戶(hù)端。
------------------------
Session Replication 絕對不是為負載平衡用的。絕大多數情況下，負載平衡器都有一個(gè)基本特性叫做“Session Affinity”。也就是說(shuō)，同
一個(gè)SESSION，即使在負載平衡的情況下，也是由同一個(gè)節點(diǎn)來(lái)提供服務(wù)的。這是性能優(yōu)化的必然要求。
這首先要從SESSION REPLICATION的機制說(shuō)起來(lái)。SESSION 復制發(fā)生的時(shí)間順訊可能有兩種：1。每次請求都復制。2。定時(shí)復制。第一種情況可
以基本保障節點(diǎn)之間SESSION狀態(tài)在絕大多數情況下是同步的，但是這樣做的潛在性能代價(jià)非常高。
以上說(shuō)明，從應用層面上看，“任何時(shí)間主從節點(diǎn)狀態(tài)都同步”的要求是基本上不可能達到的。直接邏輯結論就是，主服務(wù)節點(diǎn)的重新導向不
能在任意時(shí)間發(fā)生。這就是為什么要有SESSION AFFINITY。
AFFINITY在系統軟件是一個(gè)普遍應用的優(yōu)化技術(shù)。多CPU操作系統，比如WINDOWS,UNIX,LINUX，相應地有“PROCESS AFFINITY,THREAD AFFINITY
”的概念，基本上出于同樣的原理。CPU的L1 CACHE，在這里就對應于我們的SESSION STATE。為了不造成頻繁的緩存沖洗，OS就要保證PROCESS
被綁定在一個(gè)CPU上。
SESSION AFFINITY實(shí)現的方式，取決于不同的應用服務(wù)器是不同的。軟件負載平衡器一般是應用服務(wù)器的一個(gè)WEB SERVER插件。這個(gè)插件里就
內建了SESSION AFFINITY邏輯。硬件負載平衡器也支持SESSION AFFINITY，當然這需要一些配置。詳見(jiàn)（http://e-
docs.bea.com/wls/docs81/cluster/load_balancing.html#1044135）
------------------------
綜上，負載平衡在絕大多數情況下，只發(fā)生在建立SESSION之前。一旦SESSION建立，那么SESSION AFFINITY會(huì )保障同一SESSION綁定在一個(gè)節點(diǎn)
上。而SESSION REPLICATION的目的，是在發(fā)生FAIL-OVER的情況下，會(huì )話(huà)狀態(tài)不會(huì )丟失，也就是BANQ說(shuō)的“用戶(hù)沒(méi)有感覺(jué)”。
要對每次請求都做負載平衡，有兩種選擇：1。你完全不計較性能，通過(guò)配置保證每個(gè)請求都做狀態(tài)復制。這不是每款應用服務(wù)器都支持的。這
方面沒(méi)有什么JSR標準。2。你的應用完全是“應用服務(wù)器無(wú)會(huì )話(huà)狀態(tài)”的。也就是說(shuō)，所有的會(huì )話(huà)狀態(tài)存在數據庫或者客戶(hù)端。這種架構并不
適用于所有的應用。商業(yè)企業(yè)應用大多數都有相當數量的會(huì )話(huà)狀態(tài)和CONTEXT狀態(tài)，采用數據庫狀態(tài)會(huì )帶來(lái)頻繁的數據庫操作，而客戶(hù)端狀態(tài)首
先未必能夠容納那么多數據，即使能夠容納，每次請求都要附帶大量狀態(tài)數據，會(huì )對網(wǎng)絡(luò )傳輸造成壓力。
------------------------
1。所謂狀態(tài)恢復，就是通過(guò)狀態(tài)復制實(shí)現的。狀態(tài)復制不一定要在兩個(gè)節點(diǎn)之間。比如WEBSPHERE，就是把狀態(tài)復制到數據庫。在WEBSPHERE里
，狀態(tài)復制有兩種方式，通過(guò)內存復制（類(lèi)似WEBLOGIC），或者通過(guò)數據庫永久化。無(wú)論那種方式，對于應用而言都是透明的，目的都是在
FAIL-OVER情況下實(shí)現透明的狀態(tài)恢復。
2。EJB的負載平衡，也不是所謂“時(shí)時(shí)刻刻都在發(fā)生”。EJB的負載平衡，同樣有“SESSION AFFINITY”的優(yōu)化，當然這是針對于SFSB。對于
SLSB而言，既然沒(méi)有狀態(tài)，和WEB負載平衡就不具備可比性。
EJB的負載平衡，不但在概念上，甚至在算法上，實(shí)現上，都和WEB集群完全一致。
并且，EJB的負載平衡和 WEB負載平衡相比，作用要小得多。這樣說(shuō)的原因：
第一：絕大多數生產(chǎn)環(huán)境里，EJB的客戶(hù)端是WEB，并且EJB和WEB是共同部署。也就是說(shuō)，如果EJB容器死了，那么WEB容器肯定也死了。EJB的負
載平衡邏輯是建入在STUB里的。既然WEB已經(jīng)死了，那么STUB也就不存在了。談何EJB負載平衡？
第二，LOCAL EJB是沒(méi)有集群功能的。
第三，ENTITY EJB是沒(méi)有集群功能的。
第四，在WEB,EJB共同部署的情況下，即使WEB訪(fǎng)問(wèn)EJB是通過(guò)REMOTE INTERFACE, 應用服務(wù)器也會(huì )做優(yōu)化，把訪(fǎng)問(wèn)當作類(lèi)似LOCAL INTERFACE的
方式處理（目的是為了省略不必要的對象序列化）。這樣獲得的STUB有目的地關(guān)閉了集群邏輯。原因在一中已經(jīng)描述。
所以，EJB的集群，只在下面的情況下才會(huì )發(fā)生：
REMOTE SESSION BEAN（STATEFUL或者STATELESS）, 并且客戶(hù)端不部署在同一JVM里。即使在這樣的情況下，EJB開(kāi)發(fā)者還要保證EJB方法是
IDEMPOTENT的。
EJB集群。WEB集群二者的實(shí)現，在代碼層面都是用同樣的代碼，何來(lái)一者簡(jiǎn)陋另一者高級？
----------------------
1。從負載平衡的實(shí)現機制角度講，沒(méi)有人說(shuō)WEB負載平衡算法只有ROUND ROBIN一種?；贑PU負載的平衡算法，也就是BANQ稱(chēng)作“EJB集群的智
能”，同樣也適用于WEB負載平衡。這一點(diǎn)上EJB集群和WEB集群毫無(wú)區別。
BANQ所謂“EJB集群的智能”，有兩個(gè)要求：CPU負荷檢測，和請求重定向。這兩個(gè)要求，WEB容器都可以輕松實(shí)現。有什么理由認為EJB容器可
以做到這些而WEB容器不能？請問(wèn)BANQ，這兩點(diǎn)中哪一點(diǎn)是WEB容器不可實(shí)現的？
2。從CPU負載分布模式看， BANQ描述的WEB集群情況下大負荷請求重復定向給同一節點(diǎn)的問(wèn)題，同樣也適用于EJB集群。BANQ描述的WEB負載分
配所可能出現的問(wèn)題（大負荷請求重復發(fā)向同一節點(diǎn)），其根本假設是WEB請求的CPU負荷模式很不均勻。請問(wèn)，同樣的假設難道不適用于EJB?
難道EJB的CPU負荷模式莫名其妙地會(huì )比WEB請求更均勻？另外，這種情況，是計算機科學(xué)中負載平衡方面的經(jīng)典病理情況，有多種方法解決。最
簡(jiǎn)單的就是所有服務(wù)器都支持的隨機平衡算法。更重要的，隨機平衡算法也是WEB和EJB集群都支持的算法。
負載平衡不是什么EJB獨有的特殊算法。EJB負載平衡算法基本上都是計算機科學(xué)里大家耳熟能詳的東西。EJB和WEB在負載平衡方面，無(wú)論機理
還是算法，都是一致的。BANQ似乎認為EJB集群的優(yōu)勢在于EJB集群能夠根據CPU負荷進(jìn)行重新負荷分配而WEB集群不具備這個(gè)功能。這是完全而
徹底的誤解。
3。從生產(chǎn)環(huán)境的現實(shí)角度看，這種“基于CPU負荷重新分配負載”的行為，雖然實(shí)現起來(lái)并不難，卻沒(méi)有多少實(shí)用價(jià)值。理論分析，模擬數據
和生產(chǎn)實(shí)踐都表明，ROUND ROBIN，RANDOM, 和根據負荷的“自適應反饋算法”，在性能方面沒(méi)有很大區別。這是 相關(guān)數據在多數操作系統或
者計算機網(wǎng)絡(luò )教科書(shū)里都有描述。這聽(tīng)起來(lái)似乎有些奇怪，但不過(guò)是“大數定理”的必然結果。
4。從現實(shí)商業(yè)服務(wù)器支持角度看：BANQ描述的“根據CPU重新分配負荷”的行為，至少在WEBLOGIC, WEBSPHERE兩者都不支持。Weblogic和
WebSphere只支持 Round Robin, 加權 Round Robin和隨機 這三種算法（Web集群和EJB集群都一樣?。?。 JBoss支持一種“First Available”
的算法，但實(shí)質(zhì)上是隨機算法。
當然，WebLogic允許用戶(hù)自己開(kāi)發(fā)和定制負載分配算法，但是未見(jiàn)有記錄表明用戶(hù)通過(guò)自定義負載分配算法提高了性能的。否則，IBM，BEA，
JBOSS會(huì )只支持這三種算法么？
并且，對于 WEBLOGIC 和 WEBSPHERE, 缺省狀況下即使是 REMOTE EJB ， 在JNDI解析時(shí)也會(huì )被“本地優(yōu)先”，根本不會(huì )做負載平衡。
再者，一旦會(huì )話(huà)建立，后續請求會(huì )由于“Session Affinity”優(yōu)化而綁定在同一節點(diǎn)，也不會(huì )做負載平衡。
----------------
JNDI查詢(xún)的是HOME INTERFACE STUB。FAILOVER邏輯，在WEBLOGIC和JBOSS上，是建入在智能REMOTE STUB里的，在WEBSPHERE上是建入在代理服
務(wù)器上，JES是建入在IIOP運行庫里, 和JNDI都壓根不搭界。
JNDI是不會(huì )根據集群運行狀況而返回一個(gè)不同的STUB的。
EJB的最初設計思想是“地點(diǎn)透明”（SESSION BEAN，也可以說(shuō)是分布計算吧），和關(guān)系數據對象化（ENTITY BEAN），根本不是由“集群”驅
動(dòng)的。
1。從負載平衡的實(shí)現機制角度講，沒(méi)有人說(shuō)WEB負載平衡算法只有ROUND ROBIN一種?；贑PU負載的平衡算法，也就是BANQ稱(chēng)作“EJB集群的智
能”，同樣也適用于WEB負載平衡。這一點(diǎn)上EJB集群和WEB集群毫無(wú)區別。
BANQ所謂“EJB集群的智能”，有兩個(gè)要求：CPU負荷檢測，和請求重定向。這兩個(gè)要求，WEB容器都可以輕松實(shí)現。有什么理由認為EJB容器可
以做到這些而WEB容器不能？請問(wèn)BANQ，這兩點(diǎn)中哪一點(diǎn)是WEB容器不可實(shí)現的？
2。從CPU負載分布模式看， BANQ描述的WEB集群情況下大負荷請求重復定向給同一節點(diǎn)的問(wèn)題，同樣也適用于EJB集群。BANQ描述的WEB負載分
配所可能出現的問(wèn)題（大負荷請求重復發(fā)向同一節點(diǎn)），其根本假設是WEB請求的CPU負荷模式很不均勻。請問(wèn)，同樣的假設難道不適用于EJB?
難道EJB的CPU負荷模式莫名其妙地會(huì )比WEB請求更均勻？另外，這種情況，是計算機科學(xué)中負載平衡方面的經(jīng)典病理情況，有多種方法解決。最
簡(jiǎn)單的就是所有服務(wù)器都支持的隨機平衡算法。更重要的，隨機平衡算法也是WEB和EJB集群都支持的算法。
負載平衡不是什么EJB獨有的特殊算法。EJB負載平衡算法基本上都是計算機科學(xué)里大家耳熟能詳的東西。EJB和WEB在負載平衡方面，無(wú)論機理
還是算法，都是一致的。BANQ似乎認為EJB集群的優(yōu)勢在于EJB集群能夠根據CPU負荷進(jìn)行重新負荷分配而WEB集群不具備這個(gè)功能。這是完全而
徹底的誤解。
3。從生產(chǎn)環(huán)境的現實(shí)角度看，這種“基于CPU負荷重新分配負載”的行為，雖然實(shí)現起來(lái)并不難，卻沒(méi)有多少實(shí)用價(jià)值。理論分析，模擬數據
和生產(chǎn)實(shí)踐都表明，ROUND ROBIN，RANDOM, 和根據負荷的“自適應反饋算法”，在性能方面沒(méi)有很大區別。這是 相關(guān)數據在多數操作系統或
者計算機網(wǎng)絡(luò )教科書(shū)里都有描述。這聽(tīng)起來(lái)似乎有些奇怪，但不過(guò)是“大數定理”的必然結果。
4。從現實(shí)商業(yè)服務(wù)器支持角度看：BANQ描述的“根據CPU重新分配負荷”的行為，至少在WEBLOGIC, WEBSPHERE兩者都不支持。Weblogic和
WebSphere只支持 Round Robin, 加權 Round Robin和隨機 這三種算法（Web集群和EJB集群都一樣?。?。 JBoss支持一種“First Available”
的算法，但實(shí)質(zhì)上是隨機算法。
當然，WebLogic允許用戶(hù)自己開(kāi)發(fā)和定制負載分配算法，但是未見(jiàn)有記錄表明用戶(hù)通過(guò)自定義負載分配算法提高了性能的。否則，IBM，BEA，
JBOSS會(huì )只支持這三種算法么？
并且，對于 WEBLOGIC 和 WEBSPHERE, 缺省狀況下即使是 REMOTE EJB ， 在JNDI解析時(shí)也會(huì )被“本地優(yōu)先”，根本不會(huì )做負載平衡。
再者，一旦會(huì )話(huà)建立，后續請求會(huì )由于“Session Affinity”優(yōu)化而綁定在同一節點(diǎn)，也不會(huì )做負載平衡。
--------------------------------------------------------------------------------------
http://www.jdon.com/jive/thread.jsp?forum=46&thread=23302&start=0&msRange=15
致謝: Kyle Yin ;彭晨陽(yáng)(網(wǎng)名: 板橋里人)
http://www.jdon.com/
注:以上文章觀(guān)點(diǎn),搜集而成,僅代表個(gè)人理解,歡迎討論學(xué)習!
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=574106
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1774446
