http://kimva.blogbus.com/logs/10795676.html
在使用TUXEDO的過程中，會(huì)遇到一些并發(fā)請求量很大的情況，比如某些帳單處理服務(wù)或者是在營業(yè)下班前的日操作清單服務(wù)。這時(shí)，一些SERVICE會(huì)接收到大量客戶端，甚至長時(shí)間的請求，對(duì)service，甚至整個(gè)系統(tǒng)是嚴(yán)峻的考驗(yàn)。遇到這種情況，單個(gè)的server往往難以應(yīng)付，或者性能不好，我們就想到負(fù)載均衡或者使用TUXEDO的MSSQ（Multi Server, Single Queue）。下面筆者根據(jù)自己在TUXEDO應(yīng)用開發(fā)和管理配置方面的實(shí)踐，結(jié)合實(shí)際系統(tǒng)壓力測試的結(jié)果對(duì)相關(guān)的問題進(jìn)行一些探討。
在沒有負(fù)載均衡的情況下，是由一個(gè)server（可能包含一個(gè)或多個(gè)service）來處理客戶端對(duì)其中service的請求，所有的請求首先放入這個(gè)server的隊(duì)列里面，然后server逐個(gè)取出處理。在UNIX系統(tǒng)上，TUXEDO較多的使用了隊(duì)列，并且也用到了共享內(nèi)存和信號(hào)量，相關(guān)的UNIX系統(tǒng)參數(shù)會(huì)影響到系統(tǒng)的性能，但這個(gè)不在本文討論范圍之內(nèi)，這里假設(shè)已經(jīng)調(diào)到了合適的范圍，具體請查閱TUXEDO關(guān)于IPC的文檔。
現(xiàn)以一個(gè)帳單處理的server為例，負(fù)載均衡前server的ubb配置為：
billpay SRVGRP=GROUP1 SRVID=1
在單個(gè)server不能滿足性能要求的情況下，就考慮采用TUXEDO的負(fù)載均衡方法。
方法一是直接將相關(guān)server啟多份，將上面的配置改為：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
這樣tmboot的時(shí)候，就會(huì)有MIN = 5個(gè)billpay啟動(dòng)，類似下面的情況：
billpay 00001.00001 GROUP1 1 0 0 ( IDLE )
billpay 00001.00002 GROUP1 2 0 0 ( IDLE )
（依此類推，共5個(gè)）
其中第二列是該server的隊(duì)列名，"."前面是GRPNO,后面是SRVID，每個(gè)server有自己的隊(duì)列。相關(guān)的另一個(gè)參數(shù)就是在ubb的*RESOURCES段的LDBAL，表示是否啟動(dòng)Load Balancing，默認(rèn)是"N"（不啟動(dòng)），你可以通過設(shè)置成"Y"來啟動(dòng)。這里需要注意的是，為"N"的時(shí)候并不表示多個(gè)server不能分擔(dān)負(fù)載。主要的差別是為"Y"時(shí)，TUXEDO在接收到請求時(shí)會(huì)按照它的負(fù)載均衡的算法來找到合適的server來處理，而設(shè)置成"N"時(shí)，總是由第一個(gè)可用的server來處理。通過這種方法可以讓多個(gè)server來處理大量并發(fā)的請求，就達(dá)到了改善性能的目的。
方法二是采用MSSQ（Multi Server, Single Queue），顧名思義，就是有多份server，但是只有一個(gè)隊(duì)列（請求隊(duì)列）。具體的配置是：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
RQADDR=" billpay" REPLYQ=Y
啟動(dòng)后的情況如下：
billpay billpay GROUP1 1 0 0 ( IDLE )
billpay billpay GROUP1 2 0 0 ( IDLE )
（依此類推，共5個(gè)）
我們發(fā)現(xiàn)幾個(gè)billpay server都關(guān)聯(lián)相同的名為billpay的隊(duì)列，這就是所謂的Single Queue。
與直接多server相比，多了兩個(gè)參數(shù)，RQADDR是這多個(gè)server共用的隊(duì)列名，是一種邏輯名，可以自己命名，不和別的沖突就可以，REPLYQ是標(biāo)示是否設(shè)置返回隊(duì)列，在使用MSSQ的時(shí)候是強(qiáng)烈建議設(shè)置，因?yàn)檫@樣可以將請求和返回分開，避免多個(gè)server共用隊(duì)列時(shí)造成混亂。相關(guān)的其它參數(shù)這里沒有詳細(xì)列出。
到底兩種方式和沒有負(fù)載均衡時(shí)有什么不同，后面將提供相關(guān)的測試結(jié)果。先分析一下兩種方法。方法一有多個(gè)隊(duì)列可以容納請求，但是這些大量的請求怎樣放入這些隊(duì)列必定有一定的策略，而且根據(jù)LDBAL的設(shè)置會(huì)不同，但是這個(gè)策略本身的運(yùn)算也是一種消耗，因?yàn)槊總€(gè)請求都面臨著這個(gè)選擇。因?yàn)檫@種情況下每個(gè)隊(duì)列是和server對(duì)應(yīng)的，所以隊(duì)列的選擇就意味著選擇了相應(yīng)的那個(gè)server，這樣大量的請求就被分流。雖然有選擇的消耗，但是額外的好處也是顯而易見的，那就是有多個(gè)queue可用，有效避免了請求并發(fā)量很大時(shí)隊(duì)列的溢出，這種情況在實(shí)際的壓力測試中發(fā)生過。使用方法二時(shí)，放入隊(duì)列時(shí)不用做選擇，然后每個(gè)server的任務(wù)就是從隊(duì)列取出請求去處理，考慮到多個(gè)server并發(fā)取隊(duì)列，所以用MSSQ時(shí)其server的數(shù)目不宜太多，官方文檔建議2－12。而且在這種情況下，建議不要設(shè)置LDBAL=Y，因?yàn)镸SSQ本身就是一種基于single queue的負(fù)載均衡的方法，這時(shí)再使用系統(tǒng)的策略已經(jīng)沒有意義。這種方法也有一個(gè)問題，如果相對(duì)于請求數(shù)來說，處理得不夠快，就比第一種方法更容易造成隊(duì)列溢出。
因?yàn)槲覀儫o法知道TUXEDO一些具體的算法和策略，那就用一些具體的測試來比較吧。筆者在一個(gè)和實(shí)際生產(chǎn)系統(tǒng)配置相同的UNIX+ORACLE+TUXEDO8.0系統(tǒng)上做了一下試驗(yàn)，被測服務(wù)是一個(gè)帳單查詢服務(wù)，每次根據(jù)一批ID從數(shù)據(jù)庫查詢出具體的帳單，由于都是實(shí)際數(shù)據(jù)和實(shí)際使用的服務(wù)，有一定的說明力，但是也不排除一些情況造成的誤差。以下是測試的一些結(jié)果，每個(gè)server的實(shí)際運(yùn)行份數(shù)都是10。
一：客戶端數(shù)目為1，循環(huán)調(diào)用100次。
1． 方法一，LDBAL = Y or N。結(jié)果發(fā)現(xiàn)所有的請求都由其中的一個(gè)server處理，其它全部空閑。在此基礎(chǔ)上再進(jìn)行兩次循環(huán)調(diào)用，結(jié)果還是一樣。
2． 用方法二，LDBAL = Y or N。其中兩次測試的情況是：
<1>19，19，2，2，1，18，18，1，1，19
<2>23，8，23，23，23，（其它空閑）
以上數(shù)據(jù)說明了兩種方式的調(diào)度策略是不一樣的，在單客戶端循環(huán)的情況下方法二更合適。
二：客戶端數(shù)目50，每個(gè)循環(huán)80次，統(tǒng)計(jì)總的執(zhí)行時(shí)間。
1． 用single server。兩次測試的處理時(shí)間分別是219s和196s。
2． LDBAL = Y 方法一：三次測試時(shí)間為：63s，79s，69s
3． LDBAL = N 方法一：三次測試時(shí)間為：74s，79s，85s
4． LDBAL = Y 方法二：三次測試時(shí)間為：74s，73s，77s
5． LDBAL = N 方法二：三次測試時(shí)間為：78s，76s，75s
通過以上數(shù)據(jù)可以看出不管用那種方法，使用負(fù)載均衡相比單個(gè)server都可以在大量請求并發(fā)時(shí)得到更好的性能。但是同時(shí)也發(fā)現(xiàn)后四種情況的總時(shí)間差別不大，考慮一些實(shí)際的誤差，很難斷定哪種更好。
通過前面的分析，并查閱相關(guān)的文檔，建議采用的是兩種方式：多個(gè)server，不用MSSQ,設(shè)置LDBAL = Y；用MSSQ，設(shè)置LDBAL = N。當(dāng)然，在使用TUXEDO的應(yīng)用系統(tǒng)中，不能絕對(duì)的說哪一種方式更好，只能是根據(jù)具體的情況來分析，并通過實(shí)際的壓力測試來進(jìn)行選擇，而且這個(gè)和具體server的特點(diǎn)也是有關(guān)的。
以上是一些個(gè)人分析和測試的結(jié)果，算是寫出來和大家探討，也希望大家提出自己的看法并討論。