專利名稱：金融實時交易系統(tǒng)中的負載均衡模塊的制作方法
CN 102932444 A書明說1/11 頁金融實時交易系統(tǒng)中的負載均衡模塊技術領域
本申請涉及一種金融實時交易系統(tǒng)，特別是涉及位于終端與后臺服務器之間的通訊模塊。
背景技術：
人們在使用銀行卡、預付費卡等金融卡片進行消費交易時，就用到了金融實時交易系統(tǒng)。請參閱圖1，這是金融實時交易系統(tǒng)的簡單原理示意圖，包括
——多個終端10 :用于讀取金融卡片信息，并將包含有金融卡片信息和交易信息的交易請求發(fā)送給后臺服務器50，還接收后臺服務器50返回的交易結果。所述終端10包括刷卡機(也稱POS機)、集成有刷卡功能的收銀機等，
——一個后臺服務器50 :用于接收來自各個終端10的交易請求，根據(jù)金融卡片信息(例如金融卡片的卡號、密碼等)對交易信息(例如交易金額等)進行處理后，將交易結果返回給各個終端10。
在金融實時交易系統(tǒng)中，交易請求、交易結果均為符合IS08583協(xié)議的報文形式。
圖I所示的金融實時交易系統(tǒng)中，終端10的數(shù)量眾多，因而同時發(fā)出的交易請求可能有成千上萬條，這將對后臺服務器50的并行處理能力帶來極大的壓力。為此，實際應用的金融實時交易系統(tǒng)在后臺服務器50的前端設置了通訊模塊20，如圖2所示。新增加的通訊模塊20用于實時接收來自多個終端10的短連接方式傳輸?shù)慕灰渍埱螅⑵湟蚤L連接方式異步發(fā)送給后臺服務器50 ;還接收后臺服務器50以長連接方式異步傳輸?shù)慕灰捉Y果，并將其以短連接方式同時發(fā)送回各個終端10。所述通訊模塊20與終端10之間采用短連接的通訊方式，即每進行一次報文收發(fā)時才進行連接，收發(fā)完畢后立即斷開連接。所述通訊模塊20與后臺服務器50之間采用長連接的通訊方式，即先建立連接再進行報文收發(fā)，在沒有報文收發(fā)時連接也不斷開。
顯然，由通訊模塊20同步、并行地接收各個終端10的交易請求，將其緩存起來后串行、異步地發(fā)送給后臺服務器50，這大大提高了對前臺(終端10)的響應能力，又極大地減輕了對后臺(后臺服務器50)的壓力。同時，通訊模塊20還串行接收后臺服務器50返回的交易結果，并將其并行地返回至各個終端10。
目前，所述的通訊模塊20主要是由一種專門的硬件設備“網(wǎng)控器”(Network Access Controller)來實現(xiàn)的。網(wǎng)控器包括被稱為上聯(lián)卡和下聯(lián)卡的兩塊網(wǎng)卡、總線、諸如網(wǎng)線接口、串行接口、modem接口等的各種接口。其中，下聯(lián)卡與終端10通過撥號網(wǎng)、專線、 局域網(wǎng)等物理連接方式進行報文通訊，上聯(lián)卡與后臺服務器50通過串行接口、modem、局域網(wǎng)等物理連接方式進行報文通訊，下聯(lián)卡與上聯(lián)卡之間通過內(nèi)部總線交換數(shù)據(jù)并受內(nèi)部路由表的控制。
所述通訊模塊20可以是一臺網(wǎng)控器，也可以是級聯(lián)的多臺網(wǎng)控器。例如如圖3所示，終端IOa位于北京市，后臺服務器50位于上海市，終端IOa連接作為北京市節(jié)點的第一網(wǎng)控器21a，該第一網(wǎng)控器21a再連接作為華北區(qū)域節(jié)點的第二網(wǎng)控器21b，該第二網(wǎng)控器421b再連接作為上海市根節(jié)點的第三網(wǎng)控器21c，該第三網(wǎng)控器21c直接連接后臺服務器 50。此時，第一網(wǎng)控器21a與終端IOa之間采用短連接通訊，各網(wǎng)控器之間的級聯(lián)、以及第三網(wǎng)控器21c與后臺服務器50之間均采用長連接通訊。
由網(wǎng)控器21實現(xiàn)的通訊模塊20具有以下缺陷
其一，后臺服務器50是金融機構用于交易結算的，每個金融機構在全球范圍內(nèi)通常只部署一處。隨著金融交易的迅猛發(fā)展，后臺服務器50已逐漸發(fā)展為基于分布式系統(tǒng)的計算機集群。而每臺網(wǎng)控器21都只能連接到一臺后臺服務器50，不支持計算機集群，自然也不具備負載均衡功能。
針對后臺服務器集群，目前只能為每一臺后臺服務器50設置各自獨立的通訊模塊20，并根據(jù)報文的流量和并發(fā)數(shù)為每一通訊模塊20分配終端10。實際應用中，由于報文流量和并發(fā)數(shù)隨時變化，這種人工干預的處理方式不靈活、難以調(diào)整。
其二，網(wǎng)控器21不支持熱機備份功能，只能采用冷機備份的方式。一旦某一臺網(wǎng)控器21出現(xiàn)故障，只能采用人工恢復的方式，成本高，風險大。
其三，每臺網(wǎng)控器21能夠支持的前臺連接數(shù)量是有限的。隨著金融交易的迅猛發(fā)展，高峰時段內(nèi)的同時交易數(shù)量不斷上升，這就需要不斷購置新的網(wǎng)控器21部署到通訊模塊20中，增加了運營和維護成本。發(fā)明內(nèi)容
本申請所要解決的技術問題是提供一種金融實時交易系統(tǒng)中的負載均衡模塊，用于替代現(xiàn)有的金融實時交易系統(tǒng)中處于相同位置的通訊模塊。所述負載均衡模塊可以用于后臺服務器集群環(huán)境，并且支持熱機備份，還便于擴展處理能力，并具有較高的處理性能和較強的穩(wěn)定性。
為解決上述技術問題，本申請金融實時交易系統(tǒng)中的負載均衡模塊位于終端與后臺服務器集群之間；
所述負載均衡模塊包括至少兩臺服務器，每臺負載均衡服務器均具有一塊前臺網(wǎng)卡和一塊后臺網(wǎng)卡，并均采用VRRP協(xié)議(虛擬路由器冗余協(xié)議)；
所述VRRP協(xié)議將所有前臺網(wǎng)卡構成一組，并選出一塊主控前臺網(wǎng)卡，其余的作為備份前臺網(wǎng)卡；還將所有后臺網(wǎng)卡也構成一組，并選出一塊主控后臺網(wǎng)卡，其余的作為備份后臺網(wǎng)卡；
每臺負載均衡服務器均運行有負載均衡程序,該負載均衡程序包括負載均衡進程、多機熱備進程和監(jiān)控進程；所述監(jiān)控進程用于在負載均衡進程和/或多機熱備進程退出時將其重新啟動；所述多機熱備進程監(jiān)控虛擬路由器冗余協(xié)議所選定的主控前臺網(wǎng)卡和主控后臺網(wǎng)卡，并要求兩者必須在同一臺負載均衡服務器上；所述負載均衡進程和多機熱備進程之間還相互同步主控前臺網(wǎng)卡和主控后臺網(wǎng)卡在哪一臺負載均衡服務器上的信息。
進一步地，各臺負載均衡服務器之間為多機熱備關系或多機互備關系；在多機熱備關系下，一組前臺網(wǎng)卡對外僅具有唯一 IP地址和MAC地址，一組后臺網(wǎng)卡對外也僅有唯一 IP地址和MAC地址；在多機互備關系下，一組前臺網(wǎng)卡對外具有X個IP地址和MAC地址，一組后臺網(wǎng)卡對外也有X個IP和MAC地址，X為互備的負載均衡服務器的個數(shù)。
進一步地，所述負載均衡進程以報文作為調(diào)度單位，根據(jù)后臺服務器集群的各個后臺服務器的負荷進行任務調(diào)度；所述負載均衡進程與各個終端之間為短連接通訊方式， 與各個后臺服務器之間為長連接通訊方式。
進一步地，所述負載均衡進程間隔性地向與每一個后臺服務器的長連接發(fā)送用于獲取該條長連接的狀態(tài)的命令，并獲取該條命令所返回的結果，由此判斷每一條長連接是否中斷；
所述命令包括帶有S0_ERR0R選項的getsockopt函數(shù)、帶有TCP_INF0選項的 getsockopt 函數(shù)；
所述結果包括所述S0_ERR0R選項、所述TCP_INF0選項中的RETRANSMIT域；這兩個結果任何一個顯示某一條長連接異常，則所述負載均衡進程判斷該條長連接中斷，并停止向對應的后臺服務器進行任務調(diào)度；否則所述負載均衡進程判斷該條長連接正常。
進一步地，所述負載均衡進程為每一臺后臺服務器僅設置發(fā)送緩沖區(qū)，用于緩存發(fā)給該后臺服務器的報文；(不設置接收緩沖區(qū))當所述負載均衡進程判斷某一條長連接中斷，則將負載均衡服務器中的為相應的后臺服務器設置的發(fā)送緩沖區(qū)中的數(shù)據(jù)丟棄。
進一步地，所述負載均衡服務器采用基于EPOLL的事件驅動算法，EPOLL是Linux 內(nèi)核提供的可擴展I/o事件通知機制；
所述基于EPOLL的事件驅動算法將事件分為三種大類，按優(yōu)先級由高到低排序為實時事件、就緒事件、同步信號調(diào)用事件；
所述就緒事件又分為三種小類，按優(yōu)先級由高到低排序為子進程退出事件、IO 讀寫事件、超時事件；
所述就緒事件在其生存周期從前到后具有注冊、就緒、執(zhí)行、回收四種狀態(tài)。
進一步地，所述超時事件從注冊狀態(tài)經(jīng)過預先設置的時間就轉為就緒狀態(tài)；計算時間時采用CPU時間。
進一步地，所述IO讀寫事件在任意進程需要從某一個IO端口讀取或寫入數(shù)據(jù)時注冊；當EPOLL機制發(fā)出該IO端口有數(shù)據(jù)可供讀取、或可供寫入數(shù)據(jù)時，該IO讀寫事件轉為就緒狀態(tài)。
進一步地，在就緒事件處于回收狀態(tài)時，不釋放該就緒事件所占用的內(nèi)存空間，以便于新的就緒事件注冊時可直接利用該內(nèi)存空間；只有當內(nèi)存資源不足時，回收狀態(tài)的就緒事件所占用的內(nèi)存空間才會被釋放。
本申請金融實時交易系統(tǒng)中的負載均衡模塊具有多機熱備(或多機互備)、負載均衡、事件驅動等多種功能，不僅可以完美取代現(xiàn)有的金融實時交易系統(tǒng)中的通訊模塊，而且在功能、性能、擴展性等諸多方面都有了較大提升。


圖
圖
圖
圖
圖
圖I是金融實時交易系統(tǒng)的理論結構示意圖；2是現(xiàn)有的金融實時交易系統(tǒng)的實際結構示意圖；3是現(xiàn)有的金融實時交易系統(tǒng)中由多臺網(wǎng)控器級聯(lián)作為通訊模塊的示意圖； 4是本申請的金融實時交易系統(tǒng)的結構示意圖；5是本申請的健康檢查算法的流程圖；6是本申請的基于EPOLL機制的事件驅動算法所具有的事件分類圖。
圖中附圖標記說明
10、IOa為終端；20、20a、20b、20c為通訊模塊；30為負載均衡模塊；31為負載均衡服務器一 ；32為負載均衡服務器二 ；50為后臺服務器；500為后臺服務器集群。
具體實施方式
請參閱圖4，本申請金融實時交易系統(tǒng)包括
——多個終端10 :用于讀取金融卡片信息，并將交易請求發(fā)送給后臺服務器集群 500，還接收后臺服務器集群500返回的交易結果。
——負載均衡模塊30 :用于實時接收來自多個終端10的短連接方式傳輸?shù)慕灰渍埱?，并將其以長連接方式異步發(fā)送給后臺服務器集群500 ;還接收后臺服務器集群500以長連接方式異步傳輸?shù)慕灰捉Y果，并將其以短連接方式同時發(fā)送回各個終端10。所述負載均衡模塊30與終端10之間采用短連接的通訊方式。所述負載均衡模塊30與后臺服務器集群500之間采用長連接的通訊方式。
——后臺服務器集群500 :用于接收來自負載均衡模塊30的交易請求，根據(jù)金融卡片信息對交易信息進行處理后，將交易結果返回給負載均衡模塊30。
所述后臺服務器集群500由多個后臺服務器50組成。
所述負載均衡模塊30由至少兩臺負載均衡服務器服務器31、32組成。每臺負載均衡服務器均具有兩塊網(wǎng)卡，一塊與各終端10進行通訊稱為前臺網(wǎng)卡，另一塊與各后臺服務器50進行通訊稱為后臺網(wǎng)卡。所有負載均衡服務器都采用VRRP協(xié)議，以使所有前臺網(wǎng)卡(物理意義上)構成一組，并選出一塊主控前臺網(wǎng)卡，其余的作為備份前臺網(wǎng)卡。所述VRRP 協(xié)議還將所有后臺網(wǎng)卡也構成一組，并選出一塊主控后臺網(wǎng)卡，其余的作為備份后臺網(wǎng)卡。
VRRP協(xié)議通常用于虛擬路由，其應用環(huán)境中均為單一網(wǎng)卡設備。本申請將其應用于具有兩塊網(wǎng)卡的計算機環(huán)境中，可能會出現(xiàn)這樣的情況負載均衡服務器一 31的前臺網(wǎng)卡被VRRP協(xié)議選定為主控前臺網(wǎng)卡，負載均衡服務器二 32的后臺網(wǎng)卡被VRRP協(xié)議選定為主控后臺網(wǎng)卡，而這兩塊物理網(wǎng)卡之間并不進行數(shù)據(jù)交換因而產(chǎn)生了錯誤。
在負載均衡模塊30的各臺服務器31、32、......中均運行有負載均衡程序,該負載均衡程序主要包括負載均衡進程、多機熱備進程和監(jiān)控進程。其中的多機熱備進程特別地監(jiān)控VRRP協(xié)議所選定的主控前臺網(wǎng)卡和主控后臺網(wǎng)卡，并要求兩者必須在同一臺負載均衡服務器上。例如可采用如下方法當一臺負載均衡服務器上的前臺網(wǎng)卡被選為主控前臺網(wǎng)卡時，則強制地將該臺負載均衡服務器上的后臺網(wǎng)卡也選為主控后臺網(wǎng)卡。如果無法強制選舉，則說明負載均衡模塊30或網(wǎng)絡環(huán)境出錯，此時將以郵件等方式報警，轉為人工處理。
所述負載均衡進程和多機熱備進程之間還進行信息同步，所同步的信息包括主控前臺網(wǎng)卡和主控后臺網(wǎng)卡在哪一臺負載均衡服務器上。
所述多機熱備進程可以實現(xiàn)多機熱備功能，即正常情況下只有負載均衡服務器一 31進行工作，負載均衡服務器二 32不工作；當負載均衡服務器一 31出現(xiàn)故障，則轉由負載均衡服務器二 32進行工作。所述多機熱備進程也可以實現(xiàn)多機互備功能，即正常情況下兩臺負載均衡服務器31、32各自獨立地進行工作，并且彼此設為備機；當一臺服務器出現(xiàn)故障，其處理的工作轉由另一臺服務器進行，并且不影響該接手的服務器的原有工作。多機熱7備、多機互備均有成熟的算法加以實現(xiàn)，本申請不再予以贅述。
所述負載均衡進程以報文作為調(diào)度單位在各個后臺服務器50之間進行任務調(diào)度，這是與現(xiàn)有的負載均衡算法的顯著區(qū)別。此外，進行任務調(diào)度的依據(jù)是盡量使各個后臺服務器50的工作負荷維持為大致相同。
現(xiàn)有的負載均衡算法是以會話(session)為調(diào)度單位的。會話是指在通訊網(wǎng)絡中的兩節(jié)點之間建立通信連接、維持通信連接的暢通以交換數(shù)據(jù)、終止通信連接的過程。
這種以會話為調(diào)度單位的負載均衡算法無法真正地實現(xiàn)對服務器集群的均衡調(diào)度，舉例說明如下
如果一個網(wǎng)頁服務器集群采用了現(xiàn)有的以會話為調(diào)度單位的負載均衡算法，當一個用戶的訪問請求被分配到服務器A，并且在服務器A登錄了。然后在很短的時間內(nèi)，這個用戶(例如以IP地址判斷是否為同一用戶)又發(fā)出了一個訪問請求，如果沒有會話保持功能的話，這個用戶的請求很有可能會被分配到服務器B。這個時候這個用戶在服務器B上是沒有登錄的，所以這個用戶要重新登錄。從用戶的角度來說，他所面對的是“一臺”網(wǎng)頁服務器，他感覺需要在短時間內(nèi)重復登陸，因而用戶體驗很不好。為了提升用戶體驗，現(xiàn)有的以會話為調(diào)度單位的負載均衡算法均包含有會話保持功能，在一段時間內(nèi)將同一用戶的訪問請求都分配給同一臺服務器。這樣實際上并不是完全考慮每臺服務器的運行負荷來進行調(diào)度分配的，其中摻雜有會話保持的因素。只有針對不同用戶的訪問請求，現(xiàn)有的以會話為調(diào)度單位的負載均衡算法由于無需考慮會話保持，才真正實現(xiàn)了以每臺服務器的運行負荷來進行調(diào)度分配。
本申請以報文作為負載均衡算法的調(diào)度單位。所述報文例如是符合IS08583協(xié)議的報文，包括交易請求、交易結果等。由于金融交易之間彼此沒有關聯(lián)，互不影響，因而即便是同一終端10所發(fā)出的多個交易請求，也可以分配給后臺服務器集群500中的不同服務器 50。因此本申請所采用的負載均衡算法不需要會話保持功能，這使后臺服務器集群500中的各臺服務器50僅根據(jù)運行負荷得到調(diào)度分配，從而最為均衡、充分地發(fā)揮處理性能。
通常，所述負載均衡進程與后臺服務器集群500中的每一臺服務器50建立一條且僅建立一條長連接用于報文通訊。所述負載均衡進程采用健康檢查算法來獲知與各臺服務器50之間的連接是否中斷，一旦連接中斷則停止向其進行調(diào)度分配，一旦連接恢復才重新開始向其進行調(diào)度分配。所述健康檢查算法大致可描述為負載均衡進程間隔性地向與每一臺服務器50的長連接發(fā)送用于獲取該條長連接的狀態(tài)的命令，并獲取該條命令所返回的結果。通過分析所述結果，判斷每一條長連接是否中斷。
本申請示例性地給出所述健康檢查算法的一個實施例，如圖5所示,包括如下步驟
第I 步，設置 setsockopt 函數(shù)的 S0_KEEPALIVE 選項。setsockopt 函數(shù)是 LINUX 系統(tǒng)下(P0SIX標準的)用來設置socket連接參數(shù)的函數(shù),是set socket option的縮寫。
TCP協(xié)議內(nèi)置有KEEPALIVE內(nèi)部健康檢查機制，大致的做法為每隔一段時間發(fā)送一個數(shù)據(jù)包并接收應答；如果在規(guī)定的時間內(nèi)未收到應答，則按一定的時間間隔重復發(fā)送; 如果連續(xù)發(fā)送了 N個數(shù)據(jù)包都收不到應答則認為連接斷開；只要重復發(fā)送的數(shù)據(jù)包中有一個收到應答就認為連接未斷。
S0_KEEPALIVE是setsockopt函數(shù)支持的選項，用來設置KEEPALIVE機制的參數(shù)，包括重復發(fā)送數(shù)據(jù)包的時間間隔、最大重復發(fā)送次數(shù)、啟動檢查的閑置時間等。所述啟動檢查的閑置時間是指當系統(tǒng)正在通過連接傳輸數(shù)據(jù)，則說明該連接未斷開，KEEPALIVE機制不發(fā)送數(shù)據(jù)包。當系統(tǒng)停止傳輸數(shù)據(jù)后，經(jīng)過預定的時間后KEEPALIVE機制才發(fā)送數(shù)據(jù)包， 所述預定的時間就是“啟動檢查的閑置時間”。
第2步，所述負載均衡進程定時地向與每一臺服務器50的長連接發(fā)送帶有S0_ ERROR選項的getsockopt函數(shù)，并獲取其所返回的S0_ERR0R選項。getsockopt是LINUX 系統(tǒng)下(P0SIX標準的)用來得到socket連接選項的函數(shù),是get socket option的縮寫。 S0_ERR0R是getsockopt函數(shù)支持的選項,是用來查看socket連接的狀態(tài)是否異常,具體來說是查看KEEPALIVE機制的檢查結果。S0_ERR0R選項通常為一位數(shù)字，具有一個表示連接正常的取值(例如為O)和多個表示連接異常的取值(例如為1、2、……，不同取值表示不同的異常狀態(tài))。
所述負載均衡進程還定時地向與每一臺服務器50的長連接發(fā)送用于帶有TCP_ INFO選項的getsockopt函數(shù)，并獲取其所返回的TCP_INF0選項。TCP_INF0是getsockopt 函數(shù)支持的另一選項，用來查看TCP連接狀態(tài)信息。TCP_INF0選項中包含RETRANSMIT域， 其中記載了當前時刻數(shù)據(jù)包在該條長連接的重新發(fā)送次數(shù)。TCP數(shù)據(jù)包在第一次發(fā)送失敗后，經(jīng)過第一時間間隔后，將進行第二次發(fā)送；在第二次發(fā)送失敗后，經(jīng)過第二時間間隔后， 將進行第三次發(fā)送；……以此類推，直至到達設定的最大發(fā)送次數(shù)。并且第二時間間隔為第一時間間隔的兩倍，第三時間間隔是第二時間間隔的兩倍，……。所述RETRANSMIT域就記載了 TCP數(shù)據(jù)包當前時刻的重新發(fā)送次數(shù)，根據(jù)各時間間隔即可得到對應的重新發(fā)送時間。
第3步，一旦有某條長連接的S0_ERR0R選項顯示連接異常，則所述負載均衡進程判定該條長連接中斷，停止向該條長連接所對應的后臺服務器50分配任務。
針對S0_ERR0R選項顯示連接正常的長連接，再看這些長連接的TCP_INF0選項中的 RETRANSMIT 域。
如果這些長連接的TCP_INF0選項中的RETRANSMIT域顯示當前時刻數(shù)據(jù)包在該條長連接的重新發(fā)送次數(shù)大于預設的閾值(即重新發(fā)送時間大于預設的閾值)，則所述負載均衡進程判定該條長連接中斷，停止向該條長連接所對應的后臺服務器50分配任務。
如果這些長連接的TCP_INF0選項中的RETRANSMIT域顯示當前時刻數(shù)據(jù)包在該條長連接的重新發(fā)送次數(shù)小于或等于預設的閾值，則所述負載均衡進程判定該條長連接未中斷，仍然向該條長連接所對應的后臺服務器50分配任務。
所述方法第I步和第2步緊密相關，只有在對KEEPALIVE機制的相關參數(shù)進行設置之后，所獲取的KEEPALIVE機制的檢查結果才是及時、有用的。優(yōu)選地，本申請限定S0_ KEEPALIVE選項中的各參數(shù)的取值范圍是
——重復發(fā)送數(shù)據(jù)包的時間間隔為2秒。該參數(shù)如果設置得太小會影響網(wǎng)絡通訊，因為會有大量的數(shù)據(jù)包發(fā)送；如果設置得太大會影響檢查的及時性，可能網(wǎng)線中斷許久之后才會被發(fā)現(xiàn)。
——最大重復發(fā)送次數(shù)為7次。該參數(shù)如果設置得太小會影響檢查的準確性，因為會有誤判的情況；如果設置得太大會影響檢查的及時性。
——啟動檢查的閑置時間為I秒。該參數(shù)設置得越小，越能盡快開始檢查。
以上這組參數(shù)能保證在1+2*7=15秒左右發(fā)現(xiàn)連接壞掉，并通過了多次試驗證實這組參數(shù)比較穩(wěn)定。
所述方法第3步中，如果僅依靠KEEPALIVE機制的檢查結果，則其具有一個致命缺陷無法及時發(fā)現(xiàn)網(wǎng)線斷開(例如從網(wǎng)線接口中脫落、人為拔下等)的故障。當發(fā)生此類故障時，系統(tǒng)內(nèi)核的發(fā)送緩沖區(qū)中有數(shù)據(jù)，此時KEEPALIVE機制不會工作(其只在系統(tǒng)內(nèi)核的發(fā)送緩沖區(qū)中的數(shù)據(jù)傳輸完畢后，經(jīng)過所設置的“啟動檢查的閑置時間”才開始工作)，通過 S0_ERR0R選項所得到的結果就是KEEPALIVE機制過時的檢查結果。為此本申請同時綜合了 TCP_INF0選項。優(yōu)選地，當RETRANSMIT域顯示當前時刻數(shù)據(jù)包在該條長連接重新發(fā)送了 6 次(即總共發(fā)送了 7次)或更多次，對應于重新發(fā)送時間為15秒左右(第一時間間隔O. 25秒 +第二時間間隔O. 5秒+第三時間間隔I秒+第四時間間隔2秒+第五時間間隔4秒+第六時間間隔8秒=15. 75秒)或更長時間，所述負載均衡模塊30就認為出現(xiàn)了網(wǎng)線斷開的故障，從而判斷該條長連接中斷。本申請將S0_ERR0R選項和TCP_INF0選項相綜合，才可以完整地覆蓋各種故障情況的判定。
所述方法第3步中，除了先判斷S0_ERR0R選項，在S0_ERR0R選項顯示連接正常時再看TCP_INF0選項之外，還可以同時判斷S0_ERR0R選項和TCP_INF0選項，這兩個結果中只要有任何一個顯示某一條長連接異常，則所述負載均衡進程判斷該條長連接中斷。
所述方法第3步中，當所述負載均衡進程發(fā)現(xiàn)其與后臺服務器集群500中的一臺或多臺服務器50之間所建立的長連接斷開，則不再為這些服務器50分配任務。尚未處理完畢的交易請求不會反饋給終端10，終端10在預定時間內(nèi)未收到交易結果則按照超時交易處理，例如發(fā)送沖正交易請求。所述沖正交易請求是指如果之前的交易請求已經(jīng)被后臺服務器集群500所處理，產(chǎn)生了扣款操作；那么該沖正交易請求就將之前的交易請求取消， 將扣款返回原賬戶。如果之前的交易請求尚未被后臺服務器集群500所處理，那么該沖正交易請求就不進行操作。同時，所述負載均衡進程為每一個與其連接的后臺服務器50均僅設置有發(fā)送緩沖區(qū)，不設置接收緩沖區(qū)。所述發(fā)送緩沖區(qū)用于緩存發(fā)送給后臺服務器50的交易請求等報文。一旦發(fā)現(xiàn)某一條長連接斷開，本申請就將為相應的后臺服務器50設置的發(fā)送緩沖區(qū)中的數(shù)據(jù)丟棄掉。這樣設置可以避免下述情況的發(fā)生一旦這些后臺服務器50 與所述負載均衡模塊30之間重新建立長連接，如果不丟棄發(fā)送緩沖區(qū)中的內(nèi)容，則這些后臺服務器50必然會處理發(fā)送緩沖區(qū)中的報文，這就有可能產(chǎn)生終端10認為已經(jīng)超時的交易在后臺服務器集群500卻成功交易的矛盾情形。按照本申請的方法，當這些服務器50與所述負載均衡模塊30之間的長連接恢復以后，就可以開始接收新的任務，而不會受到之前任務的影響。
本申請的負載均衡服務器均運行一個負載均衡程序，在運行時該負載均衡程序分為多個進程(process )執(zhí)行，每個進程在執(zhí)行時具體又分為多個事件(event)。所述進程之間還具有層級，例如，負載均衡程序包括負載均衡進程、多機熱備進程和監(jiān)控進程，監(jiān)控進程是其他兩個進程的父進程，用于在其他兩個進程不論以任何方式退出(例如崩潰)時將它們重新啟動。
本申請所述的負載均衡服務器采用基于EPOLL的事件驅動算法。EPOLL是2. 6以上版本的Linux內(nèi)核提供的可擴展I/O事件通知機制，EPOLL機制對外提供I/O接口的狀態(tài)，包括每個IO端口是否有數(shù)據(jù)到達可供讀取、是否空閑可供寫入數(shù)據(jù)等。
請參閱圖6，本申請所述的基于EPOLL的事件驅動算法將事件分為三種類型
——實時事件，是指由人工操作所引起的事件。人工操作會啟動一個或多個進程執(zhí)行，這些進程所對應的事件就屬于實時事件，必須以最高優(yōu)先級進行處理。
——就緒事件，有且僅有三種，分別是子進程退出事件、IO讀寫事件、超時事件，它們彼此之間的優(yōu)先級從高到低排序為子進程退出事件> IO讀寫事件>超時事件。這些事件按照優(yōu)先級從高到低的順序進入就緒事件隊列，就緒事件隊列為先入先出(FIFO)隊列， 先放入就緒事件隊列的事件就先執(zhí)行。
——同步信號調(diào)用事件，是指對信號的處理，例如子進程退出是以信號的方式通知的，有一些管理員命令如服務器退出也是以信號的方式處理的。
這三種事件類型按照優(yōu)先級從高到低排序為實時事件>就緒事件> 同步信號調(diào)用事件,優(yōu)先級高的事件類型永遠比優(yōu)先級低的事件類型先執(zhí)行。
所述就緒事件在其生存周期從前到后具有如下四種狀態(tài)
——注冊，是指初始化就緒事件，包括設置就緒事件的具體種類、回調(diào)函數(shù)參數(shù)、 IO端口，就緒事件所屬進程及狀態(tài)等信息。
——就緒，是指將就緒事件處于隨時可執(zhí)行的狀態(tài)。
——執(zhí)行，是指處理就緒事件。
——回收，是指就緒事件執(zhí)行完畢后，不釋放該事件所占用的內(nèi)存空間，以便于新的就緒事件注冊時可直接利用該內(nèi)存空間。只有當內(nèi)存資源不足時，回收狀態(tài)的就緒事件所占用的內(nèi)存空間才會被釋放。
所述子進程退出事件在所述負載均衡程序啟動時注冊，更具體地講是在所述多機熱備進程和負載均衡進程啟動時注冊，多機熱備進程和負載均衡進程均以監(jiān)控進程的子進程的方式被創(chuàng)建。在所述負載均衡程序中，監(jiān)控進程是其他所有進程的父進程，其他所有進程是監(jiān)控進程的子進程。當任意子進程退出時，都會向父進程發(fā)出一個退出信號，這是一個同步信號調(diào)用事件。監(jiān)控進程收到該退出信號后，就將子進程退出事件轉為就緒狀態(tài)。根據(jù)進入就緒事件隊列的順序，子進程退出事件會被處理，即將退出的子進程重新啟動，并注冊一個新的子進程退出事件。然后該老的子進程退出事件轉為回收狀態(tài)。
所述IO讀寫事件在任意進程需要從某一個IO端口讀取或寫入數(shù)據(jù)時注冊。當 EPOLL機制發(fā)出該IO端口有數(shù)據(jù)可供讀取、或可供寫入數(shù)據(jù)時，該IO讀寫事件轉為就緒狀態(tài)。根據(jù)進入就緒事件隊列的順序，該IO讀寫事件會被處理，即從該IO端口讀取或寫入數(shù)據(jù)，執(zhí)行時會將IO端口、參數(shù)和狀態(tài)傳給回調(diào)函數(shù)。然后該IO讀寫事件轉為回收狀態(tài)。
所述超時事件通常用于那些需要定時處理的事務，例如前述的健康檢查算法。超時事件也是在所述負載均衡程序啟動時注冊。注冊后經(jīng)過預先設置的時間就轉為就緒狀態(tài)。值得注意的是，這里的時間采用CPU時間，CPU時間具有只增不減且不能人為修改的特點。根據(jù)進入就緒事件隊列的順序，該超時事件會被處理。如果是一次性即可處理完畢的超時事件，隨后就轉為回收狀態(tài)。如果是定時處理的超時事件，在處理過程的最后會將自身重新轉為注冊狀態(tài)，而不轉為回收狀態(tài)。
本申請所述的基于EPOLL的事件驅動算法具有如下優(yōu)點
其一，僅給出了有限的事件類型，并且嚴格定義了優(yōu)先級，經(jīng)過反復驗證確保了在 Linux系統(tǒng)中運行的穩(wěn)定性，避免了事件之間的死鎖現(xiàn)象。為了避免出現(xiàn)事件之間的死鎖現(xiàn)象，現(xiàn)有的事件驅動算法需要人為避免，而本申請則由預先設置的事件類型和優(yōu)先級予以保證，使得程序的穩(wěn)定性大大提高，減少了程序開發(fā)的難度。
現(xiàn)有的事件驅動算法有許多，比較有名的有l(wèi)ibevent, libev,nginx等。這些事件驅動算法都給出了較多的事件類型，并且允許自定義這些事件類型的優(yōu)先級。例如Iibev 事件驅動算法給出了錯誤事件、檢查事件、自定義事件、定期處理事件、清理事件、子進程復制事件等事件類型，它們可以在255個優(yōu)先級之間自行定義。一旦對某些事件類型的優(yōu)先級定義失誤，就可能引起整個程序的死機。例如，把信號的同步信號調(diào)用事件的優(yōu)先級定義得比IO讀寫事件高，然后某個信號的處理過程中會注冊IO讀寫事件并且要等該IO讀寫事件處理完成后該同步信號調(diào)用事件才算完成。那么就會出現(xiàn)新注冊的IO讀寫事件由于優(yōu)先級較低而無法處理，優(yōu)先級較高的同步信號調(diào)用事件由于需要等待該IO讀寫事件而無法繼續(xù)，形成邏輯上的死鎖。
其二，采用單調(diào)的時間管理，默認使用CPU時間。如CPU不支持則使用系統(tǒng)時間加以模擬，模擬的方式為記錄下管理員每次修改系統(tǒng)時間的差值，在計算系統(tǒng)時間時加上差值，以確保不受人為修改系統(tǒng)時間的影響，進而保證超時事件的計時精確性。
其三，與傳統(tǒng)的非事件的IO操作相比，性能明顯提高。如果不使用事件方式運行 IO讀寫即IO的阻塞讀/寫，會掛起IO讀寫的進程，直到讀取或者寫入成功。本申請所述系統(tǒng)顯然具有大量的IO讀寫操作，這勢必會大量耗費系統(tǒng)資源。
與現(xiàn)有的事件驅動方法相比，本申請基于EPOLL機制運行。EPOLL是Linux下效率最高的IO事件通知機制，因而使得本申請的事件驅動算法的性能和擴展性大大提高。
其四，現(xiàn)有的事件驅動算法中，事件執(zhí)行完畢后即釋放內(nèi)存空間，新事件注冊再重新分配內(nèi)存空間。如果大量的事件的初始化(即注冊)都重新分配內(nèi)存空間，將會極大地影響系統(tǒng)性能。
本申請為就緒事件設計了回收狀態(tài)，只是用來保存所分配的內(nèi)存空間。如果不同事件實際所需的內(nèi)存大小不同，那么本申請為所有事件不加區(qū)分地分配最大的內(nèi)存空間， 以便于重復使用該內(nèi)存空間時可用于任何事件。這樣新事件在注冊時，首先利用回收狀態(tài)的事件的已分配的內(nèi)存空間，只有當回收狀態(tài)的事件全部使用光了，才由系統(tǒng)重新分配內(nèi)存空間。所述三種就緒事件在回收狀態(tài)便不再區(qū)分，任何新的就緒事件注冊都可以使用。例如，IO讀寫事件進入回收狀態(tài)后，其未被釋放的內(nèi)存空間可用于新的超時事件的注冊。
本申請所述的負載均衡程序分為兩種工作模式，分別為調(diào)試模式和生產(chǎn)模式。生產(chǎn)模式用于實際工作，調(diào)試模式則用于發(fā)現(xiàn)程序運行過程中的內(nèi)存錯誤和文件描述符錯誤。
程序在運行過程中會占用計算機的內(nèi)存資源，在為程序分配內(nèi)存的過程中，會出現(xiàn)如下幾種錯誤內(nèi)存訪問越界(buffer overrun)、釋放空指針(free null pointer) > 重分配空指針(realIoc null pointer)、釋放沒有分配的內(nèi)存(free non-allocated buffer)、多次釋放同一內(nèi)存(double free)、分配的內(nèi)存在程序結束時沒有釋放 (non-released buffer) 0這些內(nèi)存錯誤可能會導致程序運行錯誤、程序運行失敗、計算機死機等重大問題，并且如果不解決內(nèi)存錯誤這些問題將會持續(xù)不斷地發(fā)生。
本申請所述的負載均衡模塊在調(diào)試模式下采用了一種內(nèi)存管理算法，來檢查負載均衡程序在運行過程中的內(nèi)存分配、釋放及使用中的問題。該內(nèi)存管理算法是這樣的
其一，在調(diào)試模式下，負載均衡程序在每一次要求獲取內(nèi)存空間時，都會分配比所要求的內(nèi)存空間更大的實際內(nèi)存空間。該實際內(nèi)存空間分為三段，中間一段就是所要求的內(nèi)存空間大小，前后各多分配一小段空間均用于記錄內(nèi)存邊界的校驗和數(shù)據(jù)。
其二，每次內(nèi)存分配時還會在內(nèi)存中以額外的數(shù)據(jù)結構記錄本次內(nèi)存分配的類型、文件、函數(shù)、行號、大小、分配后的內(nèi)存地址。校驗和主要是用于檢測內(nèi)存的越界訪問，越界訪問的話校驗和就會被破壞。
其三，每次內(nèi)存分配時還會在磁盤中記錄日志，包括系統(tǒng)在何時進行了何種操作， 具有何種結果等信息。
在調(diào)試模式下，通過分析上述校驗和是否完整、額外的數(shù)據(jù)結構、日志記錄等，可發(fā)現(xiàn)程序設計是否會出現(xiàn)內(nèi)存分配問題。
文件描述符(file descriptor)是系統(tǒng)內(nèi)核用來訪問文件的，由于其長度固定，因而文件描述符的數(shù)量是有限的。在為程序分配文件描述符的過程中，會出現(xiàn)如下幾種錯誤 打開的文件描述符在程序結束時沒有關閉(non-closed fd)、關閉沒有打開的文件描述符 (closed non-opened fd)、關閉空描述符(close bad fd)、多次關閉同一描述符(double close)、PIPE打開的描述符關閉了一半(only close one of pipe fd)。這些文件描述符錯誤可能會導致程序運行錯誤、程序運行失敗、計算機死機等重大問題，并且如果不解決文件描述符錯誤這些問題將會持續(xù)不斷地發(fā)生。
本申請所述的負載均衡模塊在調(diào)試模式下采用了一種文件描述符管理算法，來檢查負載均衡程序在運行過程中的文件描述符的分配、釋放及使用中的問題。該文件描述符管理算法是這樣的
其一，在調(diào)試模式下，負載均衡程序在每一次要求獲取文件描述符時，都會在內(nèi)存中以額外的數(shù)據(jù)結構記錄本次文件描述符分配的類型、文件、函數(shù)、行號、大小、打開后的文件描述符的數(shù)值。
其二，每次文件描述符分配時還會在磁盤中記錄日志，包括系統(tǒng)在何時進行了何種操作，具有何種結果等信息。
在調(diào)試模式下，通過分析上述額外的數(shù)據(jù)結構、日志記錄等，可發(fā)現(xiàn)程序設計是否會出現(xiàn)文件描述符的分配問題。
本申請所述的負載均衡模塊用于替代現(xiàn)有的金融實時交易系統(tǒng)中的通訊模塊，因而必然要支持通訊模塊所能實現(xiàn)的全部功能。其中最主要的就是實時接收來自多個終端的短連接方式傳輸?shù)慕灰渍埱?，并將其以長連接方式異步發(fā)送給后臺服務器集群；還接收后臺服務器集群以長連接方式異步傳輸?shù)慕灰捉Y果，并將其以短連接方式同時發(fā)送回各個終端。該過程中傳輸?shù)木褪荌S08583協(xié)議定義的報文，該報文包括TPDU(Transport Protocol Data Unit，傳輸協(xié)議數(shù)據(jù)單元)、報文頭和應用數(shù)據(jù)。其中TDPU由三項組成，分別是用于標識報文類型的ID項(I個字節(jié))、目的地址項(2個字節(jié))、源地址項(2個字節(jié))。所述ID項在報文正確時一般為0x60，錯誤時一般為0x68，Ox表示十六進制數(shù)。目的地址項就是報文接收方的標識。源地址項就是報文發(fā)送方的標識。
例如，在一個實際的金融實時交易系統(tǒng)中，終端10與后臺服務器50之間進行交易通訊，但終端10所連接的實際上是負載均衡模塊30。終端10、負載均衡模塊30、后臺服務器50的標識地址分別為A、B、C，均表示兩字節(jié)的十六進制數(shù)。那么從終端10向負載均衡模塊30所發(fā)送的報文的TPDU部分就是〈0x60，C，A>。負載均衡模塊30在收到該報文后， 將該報文的TPDU部分變?yōu)椤?x60，C，B〉，同時記錄下新的源地址B (標識負載均衡模塊30) 與老的源地址A (標識終端10)的對應關系。所述新的源地址B是在均衡模塊30動態(tài)分配的，對于不同的報文，會分配不同的新的源地址B來記錄該報文與終端10的對應關系，從而確定該報文應該回到哪個終端10。負載均衡模塊30將該報文發(fā)送給后臺服務器50后，后臺服務器50將該報文的TPDU部分再次變?yōu)椤?x60，B，C〉，即將目的地址和源地址交換。該報文經(jīng)過后臺服務器50處理后，發(fā)送回負載均衡模塊30，負載均衡模塊30第三次將該報文的TPDU部分變?yōu)椤?x60，A，C〉，隨后將該報文發(fā)送回終端10。
對負載均衡模塊30而言，其接收的來自終端10的交易請求報文的TDPU部分為 <0x60, C，A>，其向后臺服務器50發(fā)出的交易請求報文的TDPU部分為〈0x60，C，B〉，其接收的來自后臺服務器50的交易結果報文的TPDU部分為〈0x60，B, C〉，其向終端10發(fā)送的交易結果報文的TPDU部分為〈0x60，A，C〉。
對后臺服務器50而言，其所接收的交易請求報文的TDPU部分為〈0x60，B, C〉，其所發(fā)送的交易結果報文的TPDU部分為〈0x60，C，B〉。
對終端10而言，其所發(fā)出的交易請求報文的TDPU部分為〈0x60，C，A>，其所接收的交易結果報文的TPDU部分為〈0x60，A，C〉，中間的處理過程對終端10是透明的。
由于本申請是以計算機運行負載均衡程序的方式實現(xiàn)負載均衡模塊，因而具有極大的擴展性。例如，可對IS08583協(xié)議定義的報文格式進行修改，將TDPU的目的地址項和源地址項均由2個字節(jié)擴展為4個字節(jié)，這樣負載均衡模塊所支持的同時處理的報文數(shù)量就可以由216擴展為232。這種擴展由于突破了 IS08583協(xié)議的限制，因而需要對終端和后臺服務器進行程序升級，可用于并發(fā)交易數(shù)量突破216的將來。
本申請所述的負載均衡模塊中的服務器需要配置至少兩張網(wǎng)卡，一張網(wǎng)卡用于連接終端的接入，另一張網(wǎng)卡用于連接后臺服務器集群。通過兩張網(wǎng)卡的隔離設置，可以實現(xiàn)網(wǎng)段的隔離，從而很好地保護后臺服務器集群的安全性，同時提高實際網(wǎng)絡部署時的靈活性。
以上僅為本申請的優(yōu)選實施例，并不用于限定本申請。對于本領域的技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本申請的保護范圍之內(nèi)。1權利要求
1.一種金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述負載均衡模塊位于終端與后臺服務器集群之間； 所述負載均衡模塊包括至少兩臺服務器，每臺負載均衡服務器均具有一塊前臺網(wǎng)卡和一塊后臺網(wǎng)卡，并均采用虛擬路由器冗余協(xié)議； 所述虛擬路由器冗余協(xié)議將所有前臺網(wǎng)卡構成一組，并選出一塊主控前臺網(wǎng)卡，其余的作為備份前臺網(wǎng)卡；還將所有后臺網(wǎng)卡也構成一組，并選出一塊主控后臺網(wǎng)卡，其余的作為備份后臺網(wǎng)卡； 每臺負載均衡服務器均運行有負載均衡程序，該負載均衡程序包括負載均衡進程、多機熱備進程和監(jiān)控進程；所述監(jiān)控進程用于在負載均衡進程和/或多機熱備進程退出時將其重新啟動；所述多機熱備進程監(jiān)控虛擬路由器冗余協(xié)議所選定的主控前臺網(wǎng)卡和主控后臺網(wǎng)卡，并要求兩者必須在同一臺負載均衡服務器上；所述負載均衡進程與多機熱備進程之間還相互同步主控前臺網(wǎng)卡和主控后臺網(wǎng)卡在哪一臺負載均衡服務器上的信息。
2.根據(jù)權利要求I所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，各臺負載均衡服務器之間為多機熱備關系或多機互備關系； 在多機熱備關系下，一組前臺網(wǎng)卡對外僅具有唯一 IP地址和MAC地址，一組后臺網(wǎng)卡對外也僅有唯一 IP地址和MAC地址； 在多機互備關系下，一組前臺網(wǎng)卡對外具有X個IP地址和MAC地址，一組后臺網(wǎng)卡對外也有X個IP和MAC地址，X為互備的負載均衡服務器的個數(shù)。
3.根據(jù)權利要求I所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述負載均衡進程以報文作為調(diào)度單位，根據(jù)后臺服務器集群的各個后臺服務器的負荷進行任務調(diào)度；所述負載均衡進程與各個終端之間為短連接通訊方式，與各個后臺服務器之間為長連接通訊方式。
4.根據(jù)權利要求I所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述負載均衡進程間隔性地向與每一個后臺服務器的長連接發(fā)送用于獲取該條長連接的狀態(tài)的命令，并獲取該條命令所返回的結果，由此判斷每一條長連接是否中斷； 所述命令包括帶有SO_ERROR選項的getsockopt函數(shù)、帶有TCP_INF0選項的getsockopt 函數(shù)； 所述結果包括所述S0_ERR0R選項、所述TCP_INF0選項中的RETRANSMIT域；這兩個結果任何一個顯示某一條長連接異常，則所述負載均衡進程判斷該條長連接中斷，并停止向對應的后臺服務器進行任務調(diào)度；否則所述負載均衡進程判斷該條長連接正常。
5.根據(jù)權利要求4所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述負載均衡進程為每一臺后臺服務器僅設置發(fā)送緩沖區(qū)，用于緩存發(fā)送給該后臺服務器的報文；當所述負載均衡進程判斷某一條長連接中斷，則將負載均衡服務器中的為相應的后臺服務器設置的發(fā)送緩沖區(qū)中的數(shù)據(jù)丟棄。
6.根據(jù)權利要求I所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述負載均衡服務器采用基于EPOLL的事件驅動算法，EPOLL是Linux內(nèi)核提供的可擴展I/O事件通知機制； 所述基于EPOLL的事件驅動算法將事件分為三種大類，按優(yōu)先級由高到低排序為實時事件、就緒事件、同步信號調(diào)用事件；所述就緒事件又分為三種小類，按優(yōu)先級由高到低排序為子進程退出事件、IO讀寫事件、超時事件； 所述就緒事件在其生存周期從前到后具有注冊、就緒、執(zhí)行、回收四種狀態(tài)。
7.根據(jù)權利要求6所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述超時事件從注冊狀態(tài)經(jīng)過預先設置的時間就轉為就緒狀態(tài)；計算時間時采用CPU時間。
8.根據(jù)權利要求6所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，所述IO讀寫事件在任意進程需要從某一個IO端口讀取或寫入數(shù)據(jù)時注冊；當EPOLL機制發(fā)出該IO端口有數(shù)據(jù)可供讀取、或可供寫入數(shù)據(jù)時，該IO讀寫事件轉為就緒狀態(tài)。
9.根據(jù)權利要求6所述的金融實時交易系統(tǒng)中的負載均衡模塊，其特征是，在就緒事件處于回收狀態(tài)時，不釋放該就緒事件所占用的內(nèi)存空間，以便于新的就緒事件注冊時可直接利用該內(nèi)存空間；只有當內(nèi)存資源不足時，回收狀態(tài)的就緒事件所占用的內(nèi)存空間才會被釋放。
全文摘要
本申請公開了一種金融實時交易系統(tǒng)中的負載均衡模塊，位于終端與后臺服務器集群之間。所述負載均衡模塊包括至少兩臺服務器，每臺負載均衡服務器均具有一塊前臺網(wǎng)卡和一塊后臺網(wǎng)卡，并均采用VRRP協(xié)議。所有前臺網(wǎng)卡構成一組，對外具有唯一IP地址和MAC地址，對內(nèi)則區(qū)分為一塊主控前臺網(wǎng)卡和其余的備份前臺網(wǎng)卡。所有后臺網(wǎng)卡也構成一組，對外具有唯一IP地址和MAC地址，對內(nèi)則區(qū)分為一塊主控后臺網(wǎng)卡和其余的備份后臺網(wǎng)卡。每臺負載均衡服務器均運行有負載均衡程序，該負載均衡程序包括負載均衡進程、多機熱備進程和監(jiān)控進程；其中的多機熱備進程監(jiān)控VRRP協(xié)議所選定的主控前臺網(wǎng)卡和主控后臺網(wǎng)卡，并要求兩者必須在同一臺負載均衡服務器上。
文檔編號G06Q40/04GK102932444SQ201210419239
公開日2013年2月13日 申請日期2012年10月29日 優(yōu)先權日2012年10月29日
發(fā)明者袁立威, 鐘開鴛, 張林彥 申請人:上海銀商資訊有限公司