集群的可扩展性及其分布式体系结构之九
2008-11-25 11:00:02 来源：WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�
闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨奸柟鐧哥秮閺岋綁顢橀悙鎼闂侀潧妫欑敮鎺楋綖濠靛鏅查柛娑卞墮椤ユ艾鈹戞幊閸婃鎱ㄩ悜钘夌；婵炴垟鎳為崶顒佸仺缂佸瀵ч悗顒勬⒑閻熸澘鈷旂紒顕呭灦瀹曟垿骞囬悧鍫㈠幍缂傚倷鐒﹂敋缂佹う鍥ㄧ厓鐟滄粓宕滈敃鍌氱煑闁告劦鐓堝ḿ鏍煕濠靛棗鐝旂憸鏂跨暦閹偊妲炬繛瀵稿Т閵堢ǹ顫忛搹瑙勫珰闁肩⒈鍓涢澶愭⒑閻撳海绉虹紒鐘崇墵楠炲啯銈ｉ崘鈺佲偓濠氭煢濡警妲奸柟鑺ユ礋濮婃椽妫冨☉杈€嗘繝纰樷偓铏枠鐎规洏鍨介幃浠嬪川婵炵偓瀚奸梺鑽ゅ枑閻熴儳鈧氨鍏樺畷顖濈疀濞戞瑧鍘遍梺缁樏壕顓熸櫠閻㈠憡鐓忛柛鈩冾殔閳ь剙婀辩紓鎾寸鐎ｎ亜绐涙繝鐢靛Т鐎氼剟鐛崼銉︹拺缁绢厼鎳庨ˉ宥夋煙濞茶绨芥俊鍙夊姍瀵挳鎮㈤崫鍕ㄥ彏闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥囧弲闂侀潧鐗嗗ú鐘诲磻閹炬剚娼╂い鎰╁灩缁侇噣姊虹紒妯圭繁闁革綇缍侀悰顕€骞掗幊铏閸┾偓妞ゆ帒鍊绘稉宥夋煥濠靛棙顥犵紒鈾€鍋撻梻鍌氬€搁悧濠勭矙閹达箑姹叉繛鍡楃贩閻熸壋鍫柛顐犲灮閺嗩偊姊洪崫鍕効缂傚秳鐒﹂幈銊╁焵椤掑嫭鐓冮柟顖滃绾偓绻濋埀顒佹綇閵娧呭骄闂佸搫娲ㄩ崰鎾跺姬閳ь剙鈹戦鏂や緵闁告﹢绠栧畷銏ゆ偨閸涘ň鎷虹紓鍌欑劍閿氬┑顕嗙畵閺屾盯骞橀弶鎴濇懙闂佽鍠楄摫婵炵厧绻樻俊鎼佸Χ閸モ晝鏆伴梻鍌欑濠€杈╁垝椤栨粍鏆滈柣鎰摠濞呯姵绻涢幋鐐寸殤缁炬崘鍋愮槐鎾存媴鐠愵垳绱板┑鐐村絻椤曨參鍩€椤掑喚娼愭繛鍙夌墪閻ｇ兘顢楅崘顏冪胺闂傚倷绀侀幉锟犲礉閺囥垹鐤柣妯款嚙缁€鍫熺節闂堟稓澧涚€规洖寮剁换娑㈠箣閻愩劎绱伴梺鍝勬濡鍩為幋锔藉亹閺夊牜鍋勯崢锟犳⒑鏉炴壆鍔嶉柣妤佺矌濡叉劙骞樼€涙ê顎撴繛瀵稿Т椤戝懘骞楅悽鍛娾拺闁革富鍘介崵鈧┑鐐茬湴閸婃繈骞冩ィ鍐╁€婚柦妯侯槺椤斿﹪姊虹憴鍕剹闁告ü绮欏畷鎾绘偨閸涘ň鎷洪梺鑽ゅ枑濠㈡﹢骞冩笟鈧弻锝夊箳閻愮數鏆ら梺璇″枟椤ㄥ﹪鐛弽銊﹀闁稿繐顦扮€氳棄鈹戦悙鑸靛涧缂佹彃娼″畷鏇㈠Χ婢跺﹤鎯為梺閫炲苯澧存慨濠冩そ楠炴牠鎮欏ù瀣壕闁哄稁鍘介崑瀣煟濡灝鍚圭€规挷绶氶悡顐﹀炊閵娧€濮囬梺鍝勬噺閹倿寮婚妸鈺傚亞闁稿本绋戦锟�
濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣閿濆棭妫勯梺鍝勵儎缁舵岸寮诲☉妯锋婵鐗婇弫楣冩⒑閸涘﹦鎳冪紒缁樺灴婵＄敻宕熼姘鳖啋闂佸憡顨堥崑鐔哥閼测晝纾藉ù锝呮惈椤庡矂鏌涢妸銉у煟鐎殿喛顕ч埥澶愬閻樼數鏉搁梻鍌氬€搁悧濠勭矙閹烘鍊堕柛顐犲劜閸婄敻鏌ｉ悢鍝勵暭闁哥喓鍋熺槐鎺旀嫚閹绘帗娈绘繝纰夌磿閺佽鐣烽悢纰辨晬婵﹢纭搁崯瀣⒑鐠囨煡鍙勬繛浣冲洤绠烘繝濠傜墛閸嬧晛鈹戦崒姘暈闁抽攱鍨归惀顏堫敇閻愭潙顎涘┑鐐插悑閸旀牜鎹㈠☉銏″殤妞ゆ巻鍋撻柡瀣閵囧嫰顢曢姀銏㈩唺缂備浇椴哥敮鎺曠亽闂佸吋绁撮弲婊堝吹瀹€鍕拻濞撴埃鍋撻柍褜鍓涢崑娑㈡嚐椤栨稒娅犳い鏃囧亹閺嗗棝鏌ㄥ┑鍡欏闁告柨鐏氶妵鍕晜閻ｅ苯寮ㄩ梺璇″櫙缁绘繃淇婇懜闈涚窞閻庯綆鍓欑敮楣冩⒒娴ｇǹ顥忛柛瀣噽閹广垽宕橀鑲╋紱濡炪倕绻愰幊鎰不閸撗€鍋撻悷鏉款棌闁哥姵娲滈懞杈ㄧ節濮橆剛鐣鹃梺缁樻煥閸氬鍩涢幋锔藉€甸柛锔诲幖鏍￠梺闈涙閸熸挳寮婚妶澶婄闁肩⒈鍓欓悡鐔兼倵鐟欏嫭绀冪紒璇茬墦瀵偊宕橀鑲╁姦濡炪倖甯掔€氀囧焵椤掍焦顥堢€规洘锕㈤、娆撳床婢诡垰娲﹂悡鏇㈡煃閳轰礁鏋ゆ繛鍫燂耿閺岋綁鎮㈢粙鍨潚濠殿喖锕ュ浠嬪箖閳╁啯鍎熼柍鈺佸暞閻︼綁姊绘担铏瑰笡闁绘娲熸俊鍓佺矙鐠恒劍娈鹃梺缁樺灦宀ｈ法寮ч埀顒勬⒑閹肩偛鍔€闁告劑鍔庨妶顕€姊婚崒娆戠獢婵炰匠鍕垫闊洦娲橀～鏇㈡煛閸ャ儱鐏╅柛灞诲妽閵囧嫯绠涢幘璺侯杸闂佹娊鏀遍崹鍧楀蓟閻斿吋鍤冮柍杞版缁爼姊洪崨濠冣拹妞ゃ劌锕濠氭晸閻樻彃绐涘銈嗘閺侇喗鎱ㄩ崶鈺冪＝濞达絿枪閳ь剙婀遍弫顕€鎮㈡俊鎾虫川閳ь剟娼ч幗婊呭婵傜ǹ绾ч柛顐ｇ☉婵¤偐绱掑Δ浣侯暡缂佺粯鐩幃鈩冩償閿濆浂鍟嬮梻浣虹《閺備線宕滃┑瀣闁告稑鐡ㄩ悡銉╂倵閿濆懐浠涚紓宥嗩殜濮婂宕掑顑藉亾瀹勬噴褰掑炊瑜滃ù鏍煏婵炵偓娅嗛柛濠傛健閺屻劑寮撮悙娴嬪亾閸濄儳涓嶉柡灞诲劜閻撴洟鏌曟径妯烘灈濠⒀屽櫍閺岋紕鈧絺鏅濈粣鏃堟煛瀹€鈧崰鏍х暦濠婂棭妲鹃柣銏╁灡閻╊垶寮婚敓鐘插窛妞ゆ棁妫勯埀顒佸姍閺岋紕浠︾拠鎻掝潎闂佽鍠撻崐婵嗙暦閹烘垟妲堟慨妤€妫旂槐锟�闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚� 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚敐澶婄闁挎繂鎲涢幘缁樼厱闁靛牆鎳庨顓㈡煛鐏炶鈧繂鐣烽锕€唯闁挎棁濮ら惁搴♀攽閻愬樊鍤熷┑顕€娼ч～婵嬪Ω瑜庨～鏇㈡煙閹规劦鍤欑痪鎯у悑缁绘盯宕卞Ο铏圭懆闂佸憡锕槐鏇犳閹惧鐟归柛銉戝嫮褰梻浣规偠閸斿矂鎮ラ崗闂寸箚闁圭虎鍠栫粈鍐┿亜閺冨倸甯剁紒鎰洴濮婃椽宕崟鍨ч梺鎼炲妼缂嶅﹤鐣烽姀鐘嗘椽顢旈崨顓涘亾閸偒娈介柣鎰皺娴犮垽鏌涢弮鈧喊宥夊Φ閸曨垱鏅滈悹鍥皺娴犳悂鎮楃憴鍕┛缂佺粯绻堥悰顔芥償閵婏箑娈熼梺闈涳紡閸愩劌顩梻鍌氬€搁オ鎾磻閸曨個娲晝閳ь剛鍙呴梺鍝勭Р閸斿孩鏅堕敓鐘斥拻闁稿本鐟︾粊鐗堛亜閺囧棗鎳夐崑鎾诲垂椤愩垺璇為悗瑙勬礃缁捇骞冮姀锛勯檮濠㈣泛顑囩粙渚€姊绘担鐟板姢缂佺粯鍔曢敃銏℃綇閳轰緡妫滈梺绋跨箻濡法鎹㈤崱妯镐簻闁哄秲鍔庨。鏌ユ煙椤栨氨澧涢柕鍥у椤㈡洟濮€閵忋垹濮辨繝娈垮枛閿曘儱顪冮挊澶屾殾闁绘垹鐡旈弫鍥ㄧ箾閹寸偟鎳冮柣婵嬩憾濮婄粯鎷呴崨闈涚秺椤㈡牠宕ㄩ鍥ㄧ☉閳规垹鈧綆浜為悾楣冩⒑闁偛鑻晶顖炴煏閸パ冾伂缂佺姵鐩獮妯尖偓鍨偠閸嬫劖绻濈喊妯活潑闁搞劍澹嗛埀顒佺濠㈡﹢锝炶箛鎾佹椽顢旈崟顏嗙倞闂備礁鎲″ú锕傚礈濮樿泛绠柛妤冨亹閺€浠嬫煟閹邦厼绲荤紒鐙欏啰鏆嗛柨婵嗘噺閸嬨儲顨ラ悙鏉戠伌濠殿喒鍋撻梺缁橈供閸嬪懘寮埀顒€鈹戦悩鍨毄濠殿喖顕埀顒佸嚬閸ｏ絽顕ｉ崼鏇炵濞达絽鍘滈幏娲⒑閸涘﹦绠撻悗姘煎幖椤斿繐鈹戦崱蹇旀杸濡炪倖姊归崕鎶藉储閹绢喗鐓欐い鏃囶嚙瀹撳棗鈹戦敍鍕幋闁糕晪绻濆畷鎺懳旀担鍓蹭紲濠电姷鏁搁崑鐘诲箵椤忓棗绶ゅù鐘差儏缁犺銇勯幇鈺佲偓鏍汲濠婂牊鍋ｉ弶鐐村椤掔喖鏌ｉ弬鎸庮棦闁哄矉缍侀幃銏犵暋閹殿喚娉块梻浣姐€€閸嬫捇鏌ゆ慨鎰偓妤冨婵傚憡鐓曢悘鐐靛亾閻ㄦ垹鈧稒绻傝灃婵°倕锕ｇ花鐑芥煕濡も偓閸熷潡鎮鹃悜鑺ュ亗閹兼惌鍠楅崓鐢告⒑閹稿海绠撻柟鍐茬У缁旂喖寮撮姀鈾€鎷洪梺鍛婄箓鐎氼剟寮冲▎鎾寸厽婵°倐鍋撴俊顐ｇ〒閸掓帡宕奸妷銉ь槰闂佸磭鎳撻妵妯艰姳婵犳碍顥婃い鎰╁灪閹兼劖绻涚€电ǹ鍘撮挊婵嬫煥閺囨浜鹃梻鍥ь槹缁绘繃绻濋崒婊冣叡闂佷紮绲惧浠嬪蓟閿涘嫪娌悹鍥ㄥ絻椤牓姊虹€圭媭娼愰柛銊ョ仢閻ｇ兘宕￠悙鈺傤潔闂佺懓鍚€缁€浣圭閻愵兛绻嗛柕鍫濆€告禍鎯ь渻閵堝骸寮ㄩ柛搴☆煼绡撳〒姘ｅ亾闁哄本鐩幃鈺佺暦閸パ€鎷版繝鐢靛Л閸嬫挸銆掑锝呬壕濠殿喖锕ㄥ▍锝囨閹烘嚦鐔煎即閻旈浼岄梺璇″枤閸忔ɑ淇婇悿顖ｆХ闂佺ǹ顑嗛幐鎼侊綖濠靛鍋傞幖娣灮娴滃墽绱撻崒娆戣窗闁哥姵姘ㄩ崚鎺楊敍閻愬弬褔鏌ㄥ┑鍡╂Ц缂佲偓閸愵喗鐓冮柛婵嗗閺嗘瑦顨ラ悙鑼濞ｅ洤锕幃娆擃敂閸曘劌浜鹃柡宥庡幖缁€澶愭煙鏉堝墽鐣辩痪鎯х秺閺岋繝宕堕妷銉т患闂佸憡鍨规繛鈧鐐寸墪鑿愭い鎺嗗亾濠碘€茬矙閺岋綁骞樼捄鐑樼亪闂佺粯鎼╅崑濠傜暦閹偊妾ㄩ梺绋块缁绘﹢寮诲☉銏犵睄闁逞屽墰閸掓帡骞樼拠鑼舵憰闂佸搫娲㈤崹褰掓倷婵犲嫭鍠愮€广儱顦介弫鍌涖亜閹捐泛袥闁稿鎸搁埢鎾诲垂椤旂晫浜舵繝鐢靛仜閸氬鎮烽妸鈺傚€堕柟鐑橆殕閳锋垿鏌涘☉姗堝姛缂佺姵鎹囬幃妤€顫濋悡搴♀拤濡炪們鍊曢崐鍦崲濠靛牆鏋堝璺虹灱閿涚喖姊虹粙娆惧剱闁搞劌鐏濋悾鐑藉箛閺夎法顓洪梺鎸庢磵閸嬫捇鏌涢妸銉モ偓鍦崲濞戞﹩鍟呮い鏃囧吹閸戝綊姊虹粙娆惧劀缂佺粯绻堝璇差吋婢跺﹣绱堕梺鍛婃处閸撴瑥鈻嶉敐鍥╃＝濞达絽鎼牎闂佺粯顨堟繛鈧€殿喛顕ч鍏煎緞婵犲嫬骞愬┑鐐舵彧缁蹭粙骞夐垾鏂ユ灁闁哄被鍎查埛鎴犵磼鐎ｎ偄顕滈柟鐧哥秮閺屾盯鎮╁畷鍥р拰閻庢鍠栭…宄邦嚕閹绢喖顫呴柣姗€娼ч埀顒傚仱閹嘲饪伴崘顎倝鏌ゆウ鍧楀摵缂佺粯绻傞～婵嬵敇閻樻彃绠ラ梻鍌欑閹诧繝宕归鐐茬９闁哄稁鍋€閸嬫挸顫濋悙顒€顏�
1. 都是调度
三层和四层的负载平衡器实现了对IP数据包的投递选择，将客户端发送的请求报文分布到集群的节点中。我们可以把这种形式看作是一种作业调度，其调度的粒度是报文或者是连接。分布式系统中，作业调度的粒度选择一直是影响性能和吞吐量的关键因素：大粒度的调度往往性能不高，而细粒度的调度开销又比较大。显然三层交换技术由于采取IP报文作为调度的基本单位，可以最小化调度算法的复杂性，给各种优化性能的高效技术提供扩展的空间。我们如果抽象的看待三层调度，其模型可以描述如下：
〔图一〕：集群调度模型
均衡器从IP层开始，截获所有的流入报文，并按照报文调度策略进行服务节点选择、报文修改、报文重新投递三项工作。此外，对于错误的报文以及超时等网络上常见的异常也需要进行处理。由于报文仅仅是网络通信过程中的数据片断，因此对于完整的通信来说，TCP/IP采用了连接这一更大的任务粒度来描述通信。连接引入了状态：起始、消亡、异常等，将无续的报文组织起来，满足了通信会话的功能要求。
三层交换基础到目前为止已经非常成熟，因为处理器仅需要识别报文的地址相关信息，利用快速查找表即可以实现报文交换。软件方面，Windows下的NLB集群以及Linux下的LVS都是典型的代表，它们都在核心层的TCP/IP协议栈实现报文的快速处理，并且尽可能避免耗时的上下文交换（上下文交换用于核心进程和用户进程之间交换处理的数据，实现了对数据更为复杂的处理）。而硬件方面对于报文交换的实现更为成熟，借助专用的并行处理器实现对报文的线速处理。这方面有Cisco、Intel、F5等多家厂商实现的高性能集群产品。
四层交换对TCP连接进行调度，粒度更大。原则上粒度大的调度在分配算法本身的开销相对更小，因为调度算法的执行频度因为粒度的不同降低几个数量级。但是，维护大粒度任务所需的状态集合可能要比小粒度的任务大的多，状态的切换也更加复杂，特别是对于异常状态和边界状态的处理，这对平衡器的逻辑设计提出更高的要求。
三层交换，在后端服务节点内容全镜像的情况下，均衡器仅需要记录一张报文的来源－目的映射表即可，查表算法可以使用快速的搜索算法进行，已经应答的报文只需要简单的从映射表中删除。核心进程的维护工作比较轻松。而对于连接调度，均衡器"表"中的项目可以小一些，但是表中每一个连接任务的状态信息都必须维护，对于任务单位而言需要消耗更多的空间存储任务状态，而且任务的生存周期变长。因此一段时间下来，均衡器就会维护着大量的有状态的连接任务调度信息。
这里并不是说明三层和四层交换孰优孰劣，他们各自有自己的适用面。我们需要知道的是，选择了不同的调度粒度，直接导致整体调度策略的变化，以及对于集群调度性能影响的关键因素也将发生改变。三层调度中，快速的查表和避免上下文交换是提高性能的关键；四层交换中，CPU还需要足够的内存维护大量的活跃连接，每个连接所管理的报文构成二级查找结构――这需要更快的CPU搜索算法，甚至需要利用多CPU和多线程技术。
面向内容的交换，严格上讲，并没有脱离四层交换的范畴。是四层调度技术的一种补充――毕竟没有什么比网络连接更为根本了。但是，从调度的角度来理解，面向内容的交换技术必须跨越连接而面向会话。
众所周知，TCP/IP的设计中没有严格的定义会话，仅仅是在OSI模型中给出会话的规范并未具体实现。联系一下现实的情况，我们把Http协议中一次Session过程认为是一次TCP上的会话，Session由多个连接的通信活动构成，有起始状态，和异常状态。因此，本文对于会话的理解，是基于实际的应用层协议定义进行的。
面向内容的交换仅仅是一个笼统的概念。可以针对HTTP的Session应用进行交换基本单位的定义；或者是根据请求报文的内容分类定义交换策略；甚至可以在自定义的UDP协议上处理会话级别的调度（UDP是无状态协议，但是在应用层上我们可以通过通信语义将它实现为有状态协议）。无论哪一种策略，都会导致调度算法的实现大不相同。但是，万变不离其宗，所有的面向内容的交换技术必然遵循这一根本原则：
面向内容交换的集群技术，处理模式的核心是，针对请求报文中所包含的重要关键域（也可以理解为Keyword），对之进行分析、分类和策略化处理。以达到有效的按照应用层的协议特点特别是集群的调度需要，对调度策略进行灵活的调整。
这样，面向内容的均衡工作理论上可以在不同的网络层次进行。协议层均衡需要对所有经过的IP包头进行协议检验，按照已定义的规则进行转发。同样，集群的负载均衡器可以实现高层次的流量分配。特别是针对特殊要求设计的Web站点、视频服务器等。更需要这种特殊优化的负载平衡。
2. 面向内容交换集群技术主要特点：
2.1. 面向会话
面向内容交换技术的设计初衷，就是为了解决高层通信协议中会话应用的问题（在本系列 文章之八 中，我们讨论过这种情况）。
由于集群的设计直接面向具体的协议。关键是通过数据请求解析模块和可扩展的报文分类机制，可以灵活的针对目前主流的协议进行定制，提供基于协议的会话级交换。
以HTTP为例，不论是客户端的Cookie还是服务端的Cookie，都可以直接从HTTP协议的URL字符串获得。以PHP中的Session为例，当客户端浏览器与集群的服务器节点建立了Session之后，由服务器端产生的Session标识符会伴随整个Session过程的始末，集群均衡器负责记录这个Session标识与这个服务节点之间的映射关系，表示该会话属于某一节点，并将后续的同样带有该Session标识信息的Request定向到这个服务器，保证了会话的正确运行。
Session ID
Session ID客户端――――――――――>服务节点x
会话中，客户端可能有多次的连接发往服务节点x，都被均衡器调度到同一台节点上。这里，调度的粒度变成了会话（等效于Session ID），均衡器除了第一次的连接需要进行调度处理之外，后续的同一会话的连接只要简单的按照映射表项进行转发即可，不需要复杂的调度算法。已存在的会话可以复用旧的连接，以避免不断开辟新的TCP连接导致的三次握手的开销过大问题；新的会话则根据负载平衡原则，在会话初建期先选择负载最轻的节点，而后产生新的会话连接。
面向会话负载平衡的核心，实际上集中在如何更加有效的进行协议解析（URL解析）和快速分类，以及如何指定分发策略上。
本质上，把协议解析看作是负载平衡集群的前置工作，由均衡器中特定的预处理模块担当，而后续的平衡策略实施与原有的面向连接的负载平衡技术也就大同小异了。
由于会话的定义在具体的协议中依据有所不同。对于SSL等基于ID的会话应用，可以使用上面的方法实现。对于本来就是无状态的UDP通信而言，会话的定义隐含在UDP包头中，这要具体按照应用中对会话的定义进行前置处理程序的修改。总而言之，会话级调度的支持，满足了负载平衡功能上的需要，特别对于某些应用层协议。
2.2. 更高的File System扩展性
三层交换和四层交换中，由于采取面向数据包调度，无法区分数据包的业务意义。因此只能假设后端服务器能够提供一致的内容。对于集群的服务节点群来说，可以完全复制一样的数据内容或者是访问一个共享的磁盘来实现。但是对于性能和存储能力都有较大的影响。
〔图二：〕三层和四层交换需要一致存储镜像支持
采用面向协议的负载平衡，在后端文件系统的要求上，允许更好的扩展性。请求往往是直接面向数据的，而数据大多数以文件的形式存在，在Web类型的应用中尤其明显。不管是Web站点还是视频点播服务器，对信息的获取都是通过获取文件进行。因此，HTTP协议中包含的文件相关信息（相对路径以及文件名）足以提供负载平衡的解析支持。
通过文件存储的分区，按照文件类型（通过文件名后缀）、不同文件的读写频度差异，或者不同文件的功能进行区分，将文件分散到不同的服务节点或者是服务结点组上。物理上文件是分散的，但是逻辑上多个服务器的存储在内容可以构成一个单一的系统存储映像，这一点类似windows里面的逻辑卷的概念，对外提供一致的访问服务。一方面将负载静态的分布到不同的节点，提高整体的吞吐量；另一方面避免了完全镜像中，多点同步引发的开销问题。
〔图三〕根据HTTP请求中文件类型进行负载平衡的面向内容交换
负载平衡器需要在请求分发这一环节支持内容分区。通过解析后的请求分类，将指定类型的请求发往特定的节点或者节点组。当然，这必然要求负载平衡器保留一份全集群的内容索引镜像，并且在内容有更新的时候同步这个镜像。镜像可以是简单的hash表，记录每个节点所能处理的请求类型或者文件类型；如果支持节点组的话，还可以扩展该映射表，用二级的索引结构来支持节点集。
对于以静态内容为主的大型站点，可以很简单的修改负载平衡器的规则集就能支持内容分区，借助节点的本地硬盘组合，就可以实现大容量的服务站点。
2.3. 面向XML电子数据交换应用
XML作为现今最为通用的数据格式交换标准，必将逐步替代HTML。而具备对协议的深入解析的能力，就能够按照预定的样式(Schema)分析HTTP协议数据中的XML数据。典型的EDI服务环境中，EDI服务属于计算密集和通信密集的应用，XML应用在EDI中有着天然的优势。然而，如果仅仅依赖单一的计算系统提供大规模的数据交换显然是存在很多弊病的。
面向XML交换的集群技术，可以允许将后端的交换服务器按照不同的交换职责或者是不同的交换类型进行划分。例如，贸易类企业数据交换和工业企业数据交换的格式及表示习惯有很大的区别，而日常中也体现出不同的流量峰值。因此，将不同类型的数据交换任务静态地划分到服务结点上，可以提高集群整体的吞吐量和通信效率。负载平衡器需要分析带有XML请求的数据包，获得有效的负荷信息，分析XML中的关键域（Key Field），并根据已定义的模式将数据转发到有对应处理能力的节点组中。
我们假设这样的一个应用：一个集群系统，提供了基于XML的服务。服务是同时面向企业用户和个人用户，并且在功能上相当。但是企业用户需要支付更高的服务费用，并且享受更好的服务质量和性能；同时，企业日常的请求中，存在部分"紧急请求"的请求需要优先完成。因此，下图所示，集群将企业的"紧急请求"发往集群中的高速主机节点进行服务，保证质量和任务的优先级；企业的一般请求发往相对普通的服务器节点；而一般个人用户因为支付较少的费用享受相对较差的服务（往往是需要更长的服务等待时间），所有的个人请求发往普通服务节点（选取性能权值最低的节点）。
〔图四〕基于XML调度的集群应用
服务节点的好坏可以根据配置和当前处理负载进行排队，权值高的节点表明处理能力强，用于服务"紧急请求"或者高优先级用户（例如企业用户）。另外均衡器判断请求可以根据URL中，包含的XML域进行解析：
| 解析条件 | 候选服务节点 |
| Xml.UserTpye='企业用户' | 高速主机 or MaxWeight（普通服务节点） |
| XML.UserType='个人用户' | MinWieght（普通服务节点） |
| XML.RequestType='紧急请求' and Xml.UserTpye='企业用户' | MaxWeight（高速主机） |
这里的表格用于 均衡器进行XML解析调度的参考，可以看出，将表格中的条件转换为具体的语言并不难。其中MinWeight和MaxWeight分别表示取节点群中权值最小和最大的节点。
面向XML解析的实现方法并不难，关键在于XML解析所带来的额外的消耗是否会使集群的均衡器成为系统的性能瓶颈。关于这一点我们将在后续篇章中讨论。
2.4. 缓存交换
根据HTTP协议的URL信息进行负载平衡还有一个非常重要的应用，就是缓冲交换（Cache Switching）。大型ISP 为了加速网络的响应都会架设大量的前置高速缓冲服务器（forward proxy cache server），但是，对于无法识别内容的缓存集群来说，所有的缓存服务器节点都必须保存整个被访网络的全部内容（理论上，所有的网络中的站点都被缓存过的话）。显然，缓存服务器的存储能力无法满足这一点要求，势必导致大量的页面无法被及时缓存而进行缓存更新，用户访问网络的速度反而变慢。
如果使用面向URL内容的集群调度技术，可以设定每一台集群节点负责部分URL的缓冲请求的任务，由于每个节点所缓存的内容完全不同，集群整体构成一个大的内容超集，提高了总体存储能力。而Cache集群缓冲命中率的提高，也大大降低了用户请求的页面出现缺失的情况，改善了集群的吞吐能力和性能。这一点，也被称为Locality――局部特性。
3. 结束语
分析了面向内容负载平衡集群技术的特点之后，我们将就面向内容交换的核心处理技术进行分析，并在后续的篇章中进一步讨论其体系结构、网络模式、调度算法、性能比较等几大方面的内容。
中查找“集群的可扩展性及其分布式体系结构之九”更多相关内容
中查找“集群的可扩展性及其分布式体系结构之九”更多相关内容更多精彩
赞助商链接
