服務(wù)器通信技術(shù)方案前言11.服務(wù)器通訊需要解決的問題2矚慫潤厲釤瘞睞櫪廡賴賃軔朧。1.1單臺(tái)RCU設(shè)備通訊情況2聞創(chuàng)溝燴鐺險(xiǎn)愛氌譴凈禍測樅。1.2上萬個(gè)RCU甚至達(dá)到將近百萬終端與服務(wù)器同時(shí)通訊2殘騖樓諍錈瀨濟(jì)溆塹籟婭騍東。1.2.1單臺(tái)服務(wù)器2釅錒極額閉鎮(zhèn)檜豬訣錐顧葒鈀。1.2.2集群服務(wù)器2彈貿(mào)攝爾霽斃攬磚鹵廡詒爾膚。2.目前服務(wù)器通訊主流技術(shù)方案3謀蕎摶篋飆鐸懟類蔣薔點(diǎn)鉍雜。2.1網(wǎng)上常用主流方案簡介與比較3廈礴懇蹣駢時(shí)盡繼價(jià)騷巹癩龔。煢楨廣鰳鯡選塊網(wǎng)羈淚鍍齊鈞。2.1.1傳統(tǒng)的socket通訊模型32.1.2Windows下IOCP模型3鵝婭盡損鵪慘歷蘢鴛賴縈詰聾。2.1.3籟叢媽羥為贍僨蟶練淨(jìng)櫧撻曉。linux下epoll模型42.1.4其它的網(wǎng)絡(luò)通訊第三方開源庫簡介及比較5預(yù)頌圣鉉儐歲齦訝驊糴買闥齙。2.2服務(wù)器集群方案6滲釤嗆儼勻諤鱉調(diào)硯錦鋇絨鈔。3.根據(jù)項(xiàng)目情況選擇最合適方案8鐃誅臥瀉噦圣騁貺頂廡縫勵(lì)羆。擁締鳳襪備訊顎輪爛薔報(bào)贏無。3.1推薦選擇linux系統(tǒng)下的epoll及開源庫Boost::asio83.2可能問題8贓熱俁閫歲匱閶鄴鎵騷鯛漢鼉。修訂記錄序號(hào) 版本號(hào) 修訂內(nèi)容 修訂人 修訂日期 第一個(gè)版本 顏冬前言RCU-U設(shè)備采集數(shù)據(jù)如：車輛診斷，通過 GSM基站定位，內(nèi)置 GPS，GPRS系統(tǒng)提供遠(yuǎn)程數(shù)據(jù)，對(duì)車輛各個(gè)系統(tǒng)的運(yùn)行狀況（如 ENG、ABS、ETC等）實(shí)時(shí)監(jiān)測狀態(tài)數(shù)據(jù)等。 壇摶鄉(xiāng)囂懺蔞鍥鈴氈淚躋馱釣。這些數(shù)據(jù)的網(wǎng)絡(luò)通訊平臺(tái)， 則由服務(wù)器提供的通訊技術(shù)來實(shí)現(xiàn)， 因此如何實(shí)現(xiàn)這種多設(shè)備數(shù)據(jù)同時(shí)接收的技術(shù)方案很重要。本文將詳細(xì)介紹相關(guān)技術(shù)及提出方案。 蠟變黲癟報(bào)倀鉉錨鈰贅籜葦繯。1/8服務(wù)器通訊需要解決的問題單臺(tái)RCU設(shè)備通訊情況主要通訊數(shù)據(jù) :設(shè)備端，剛連接時(shí)登陸驗(yàn)證（設(shè)備端信息驗(yàn)證） ;設(shè)備端，診斷數(shù)據(jù)及其它采集數(shù)據(jù)上傳到服務(wù)器（估計(jì)頻率 每秒發(fā)一次） ;服務(wù)器端，發(fā)送指令，實(shí)現(xiàn)對(duì)設(shè)備端的遠(yuǎn)程配置 ;RCU設(shè)備工程師估計(jì)的數(shù)據(jù):1每個(gè)RCU設(shè)備每秒鐘產(chǎn)生一條數(shù)據(jù)，每條數(shù)據(jù)大概100個(gè)字節(jié)左右(0.1K左右)；2可以假設(shè)每臺(tái)車每天平均開動(dòng)1小時(shí)或2小時(shí)(實(shí)際產(chǎn)生數(shù)據(jù)時(shí)間)；RCU數(shù)量（個(gè)）1秒1小時(shí)2小時(shí)10.1kb360kb720kb1萬1000kb3515M7030M0.97M3.43G6.86G100萬100,000kb343G686G97M1000萬1000,000kb3430G6860G970M3.35TB6.70TB從上數(shù)據(jù)顯示如果達(dá)到：100萬級(jí)別的 RCU用戶量，需要服務(wù)器有近百兆的網(wǎng)絡(luò)帶寬吞吐量。1000萬級(jí)別的 RCU用戶量，需要服務(wù)器有近千兆的網(wǎng)絡(luò)帶寬吞吐量。上萬個(gè) RCU甚至達(dá)到將近百萬終端與服務(wù)器同時(shí)通訊單臺(tái)服務(wù)器如果按照經(jīng)典的 server/client 通訊模型，當(dāng)有一個(gè)設(shè)備通過（ TCP/UDP）連接服務(wù)器時(shí)，服務(wù)端單獨(dú)開一個(gè)線程為這個(gè)設(shè)備數(shù)據(jù)服務(wù)， 顯然，當(dāng)路數(shù)越多， 我們的設(shè)備又是長連接方式，很快服務(wù)器將在設(shè)備近千路時(shí)服務(wù)器資源將達(dá)到上限，并且存在大量線程切換與管理問題。這時(shí)如果我們能合理利用單臺(tái)服務(wù)器資源（如： windows 下iocp 模式，linux下的epoll網(wǎng)絡(luò)通信模式等） ，在更優(yōu)的管理模式下，將能接更多設(shè)備的服務(wù)（網(wǎng)上資料預(yù)估幾千路的長連接甚至硬件較好配置下達(dá)到萬路以上） 。上面我們能在單臺(tái)服務(wù)器在較好硬件配置和軟件優(yōu)化的模型管理下，能解決幾千路上萬路設(shè)備的長連接。 買鯛鴯譖曇膚遙閆擷凄屆嬌擻。集群服務(wù)器但是，如果幾十萬臺(tái)甚至接近百萬級(jí)別的設(shè)備數(shù)量同時(shí)訪問服務(wù)端時(shí)， 這個(gè)時(shí)候需要涉及到一種合理的集群服務(wù)器架構(gòu)模式。 理論上，為了達(dá)到 1:10000的連接，可以采用 Server-Client的連接方式，而為了達(dá)到 1:10000*100 的連接，我們?cè)趺崔k呢？一般會(huì)采用 Client->ConnServer->LogicServer 。相當(dāng)于有一批服務(wù)器來合理布局解決設(shè)備的大并發(fā)通訊問題。 綾鏑鯛駕櫬鶘蹤韋轔糴飆鈧麥。ConnServer 在接受完 Client 的連接后，將 LogicServer 暴露給 Client,并立刻斷開連接，稱之為短連接。以后的數(shù)據(jù)交互就和 ConnServer沒有關(guān)系了，讓 LogicServer 直接跟 client再長連接通訊，這種架構(gòu)有很多的優(yōu)勢。 驅(qū)躓髏彥浹綏譎飴憂錦諑瓊針。2/8[圖一：標(biāo)準(zhǔn)集群 Server架構(gòu)方案]目前服務(wù)器通訊主流技術(shù)方案2.1網(wǎng)上常用主流方案簡介與比較2.1.1傳統(tǒng)的socket通訊模型socket有兩種：流式Socket（SOCK_STREAM）和數(shù)據(jù)報(bào)式Socket（SOCK_DGRAM）。流式是一種面向連接的Socket，針對(duì)于面向連接的TCP服務(wù)應(yīng)用；數(shù)據(jù)報(bào)式Socket是一種無連接的Socket，對(duì)應(yīng)于無連接的UDP服務(wù)應(yīng)用。貓蠆驢繪燈鮒誅髏貺廡獻(xiàn)鵬縮。一般小型的c/s通訊系統(tǒng)利用socketAPI和結(jié)合一個(gè)線程對(duì)應(yīng)一個(gè)客戶的開發(fā)模式。如果路數(shù)增多，容易耗盡服務(wù)端資源。該通訊模型利用硬件資源效率不高。鍬籟饗逕瑣筆襖鷗婭薔嗚訝擯。 下IOCP模型IOCP 完成端口模型又是怎樣實(shí)現(xiàn)的呢？首先我們創(chuàng)建一個(gè)完成端口CreateIOCompletionPort 。綁定端口之后，建立一個(gè)監(jiān)聽線程，用來監(jiān)聽客戶端的連接，當(dāng)有連接進(jìn)來時(shí)，將該連接的套接字加入到 IOCP對(duì)隊(duì)列中，同時(shí)再創(chuàng)建幾個(gè)工作線程（ CPU數(shù)*2+2），工作線程調(diào)用 getQueuedCompletionStatus 方法在關(guān)聯(lián)到這個(gè)完成端口上的所有套接字上等待 I/O的完成，再判斷完成了什么類型的 I/O，然后接著發(fā)出 WSASend 和WSARecv，這樣在該連接發(fā)生請(qǐng)求時(shí)， IOCP模型就會(huì)在工作線程通知，這樣我們就可以在工作線程中，完成對(duì)客戶端的請(qǐng)求做出一系列響應(yīng)。 構(gòu)氽頑黌碩飩薺齦話騖門戲鷯。完成端口提供了一個(gè)高效復(fù)雜的內(nèi)核對(duì)象，使得非 I／O處理和 I／O處理能重疊并行地操作。該對(duì)象通過指定工作線程的數(shù)量，對(duì)重疊的 I／O操作進(jìn)行處理。當(dāng)一個(gè)事件發(fā)生，此完成端口就被操作系統(tǒng)加入一個(gè)隊(duì)列中， 然后應(yīng)用程序可以對(duì)核心層進(jìn)行查詢以得到此完成端口。IOCP的核心思想簡單說就是：將所有用戶的請(qǐng)求都投遞到一個(gè)消息隊(duì)列中，利用事先創(chuàng)建好的若干個(gè)工作線程逐一從消息隊(duì)列中取出消息并加以處理。 這樣不僅減少了線程資源，也大大提高了線程的利用率。要注意的是，所謂完成端口，實(shí)際上是 Windows 采用的一種I／O構(gòu)造機(jī)制，并非通常所說的端口 (如Port：80)。輒嶧陽檉籪癤網(wǎng)儂號(hào)澩蠐鑭釃。3/8下epoll模型epoll是Linux下多路復(fù)用 IO接口select/poll的增強(qiáng)版本，它能顯著提高程序在大量并發(fā)連接中只有少量活躍的情況下的系統(tǒng) CPU利用率。因?yàn)樗鼤?huì)復(fù)用文件描述符集合來傳遞結(jié)果而不用迫使開發(fā)者每次等待事件之前都必須重新準(zhǔn)備要被偵聽的文件描述符集合， 另一點(diǎn)原因就是獲取事件的時(shí)候，它無須遍歷整個(gè)被偵聽的描述符集，只要遍歷那些被內(nèi)核IO事件異步喚醒而加入Ready隊(duì)列的描述符集合就行了。epoll除了提供select/poll那種IO事件的電平觸發(fā)（LevelTriggered）外，還提供了邊沿觸發(fā)（EdgeTriggered），這就使得用戶空間程序有可能緩存IO狀態(tài)，減少epoll_wait/epoll_pwait的調(diào)用，提高應(yīng)用程序效率。堯側(cè)閆繭絳闕絢勵(lì)蜆贅瀝紕縭。傳統(tǒng)的select/poll另一個(gè)致命弱點(diǎn)就是當(dāng)你擁有一個(gè)很大的socket集合，不過由于網(wǎng)絡(luò)延時(shí)，任一時(shí)間只有部分的socket是“活躍”的，但是select/poll每次調(diào)用都會(huì)線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個(gè)問題，它只會(huì)對(duì)“活躍”的socket進(jìn)行操作---這是因?yàn)樵趦?nèi)核實(shí)現(xiàn)中epoll是根據(jù)每個(gè)fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有“活躍”的socket才會(huì)主動(dòng)的去調(diào)用callback函數(shù)，其他idle狀態(tài)socket則不會(huì)。識(shí)饒鎂錕縊灩筧嚌儼淒儂減攙。通訊模型 主要優(yōu)點(diǎn)傳統(tǒng)socket 適合于連接量較小的通訊情況，通過socetAPI 建立 C/S通訊。

主要缺點(diǎn)服務(wù)連接路數(shù)小，IO沒有復(fù)用，一般是一個(gè)線程對(duì)應(yīng)終端的服務(wù)模式。通訊情況下，每個(gè)socket句柄，包含不活躍的連接也會(huì)需要遍歷。Windows下IOCP 適合于大量連接數(shù)（上萬路） ，IO復(fù)用，消息隊(duì)列，可指定相應(yīng)工作線程數(shù)，輪詢端口的事件， 充分利用多核，高效率地服務(wù)于多并發(fā)。

只跑在windows服務(wù)器下，如果數(shù)據(jù)庫平臺(tái)為linux服務(wù)器，影響系統(tǒng)功能模塊整合。linux下epoll適合于大量連接數(shù)（上萬路），ET和LT模式下，其中LT模多路復(fù)用IO接口，只遍歷那些被內(nèi)核式比較復(fù)雜，較難處理數(shù)據(jù)收IO事件異步喚醒而加入Ready隊(duì)列的發(fā)。描述符集合。通訊情況下，只對(duì)活躍的連接遍歷，提高了效率。當(dāng)前主流4/8服務(wù)器為 linux,也有系統(tǒng)優(yōu)勢。基于以上比較，我們服務(wù)器的操作系統(tǒng)平臺(tái)是linux下（大數(shù)據(jù)庫的平臺(tái)也是），顯然大并發(fā)訪問通訊模型linux下epoll更合適我們項(xiàng)目實(shí)際需求。凍鈹鋨勞臘鍇癇婦脛糴鈹賄鶚。2.1.4其它的網(wǎng)絡(luò)通訊第三方開源庫簡介及比較Libeventlibevent是一個(gè)事件觸發(fā)的網(wǎng)絡(luò)庫，適用于windows、linux、bsd等多種平臺(tái)，內(nèi)部使用select、epoll、kqueue等系統(tǒng)調(diào)用管理事件機(jī)制。著名分布式緩存軟件memcached也是libeventbased，而且libevent在使用上可以做到跨平臺(tái)，而且根據(jù)libevent官方網(wǎng)站上公布的數(shù)據(jù)統(tǒng)計(jì)，似乎也有著非凡的性能。恥諤銪滅縈歡煬鞏鶩錦聰櫻鄶。libevent包括事件管理、緩存管理、DNS、HTTP、緩存事件幾大部分。事件管理包括各種IO（socket）、定時(shí)器、信號(hào)等事件；緩存管理是指evbuffer功能；DNS是libevent提供的一個(gè)異步DNS查詢功能；HTTP是libevent的一個(gè)輕量級(jí)http實(shí)現(xiàn)，包括服務(wù)器和客戶端。libevent也支持 ssl，這對(duì)于有安全需求的網(wǎng)絡(luò)程序非常的重要，但是其支持不是很完善，比如httpserver的實(shí)現(xiàn)就不支持ssl。鯊腎鑰詘褳鉀溈懼統(tǒng)庫搖飭緡。Libevlibev是libevent之后的一個(gè)事件驅(qū)動(dòng)的編程框架，其接口和libevent基本類似。據(jù)官方介紹，其性能比libevent還要高，bug比libevent還少。碩癘鄴頏謅攆檸攜驤蘞鷥膠據(jù)。ACE有人評(píng)價(jià)其框架模式很值得學(xué)習(xí)，但是其網(wǎng)絡(luò)應(yīng)用效率和開發(fā)應(yīng)用相比其他開源庫較差，這也是其主要用于研究很少用于商業(yè)應(yīng)用的原因，這方面不像boost應(yīng)用廣泛。應(yīng)用中需要充分理解其復(fù)雜的架構(gòu)模式。這不是短時(shí)間可掌握和靈活運(yùn)用的，相對(duì)來說其他第三方網(wǎng)絡(luò)開源庫相對(duì)模式精簡很多。閿擻輳嬪諫遷擇楨秘騖輛塤鵜。ICEZeroCICE是指ZeroC公司的ICE（InternetCommunicationsEngine）中間件平臺(tái)。對(duì)于客戶端和服務(wù)端程序的開發(fā)提供了很大的便利。氬嚕躑竄貿(mào)懇彈瀘頷澩紛釓鄧。目前ICE平臺(tái)中包括Ice，Ice-E，IceTouch。Ice為主流平臺(tái)設(shè)計(jì)，包括Windows和Linux，支持廣泛的語言，包括C++，Java，C#（和其他.Net的語言，例如VisualBasic），Python，Ruby，PHP和ActionScript。也包括所有的ICE服務(wù)，例如IceGrid，IceStorm釷鵒資贏車贖孫滅獅贅慶獷緞。等。Ice-E是Ice在資源受限的平臺(tái)上的一個(gè)實(shí)現(xiàn)，支持C++和嵌入式操作系統(tǒng)，例如WindowsCE，Linux。Ice-E本身不包含任何服務(wù)，但是可以利用在Ice上提供的各種服務(wù)。因此，通過Ice-E，移動(dòng)設(shè)備也能無縫的集成到分布式系統(tǒng)中。慫闡譜鯪逕導(dǎo)嘯畫長涼馴鴇撟。IceTouch是為iphone和ipodtouch開發(fā)的版本，包括Object-C映射，支持IphoneOS，并為MACOSX開發(fā)圖形界面應(yīng)用程序提供完整的Cocoa框架的訪問。諺辭調(diào)擔(dān)鈧諂動(dòng)禪瀉類謹(jǐn)覡鸞。Boost::asioBoost.Asio是利用當(dāng)代C++的先進(jìn)方法,跨平臺(tái),異步I/O模型的C++網(wǎng)絡(luò)庫，ASIO在Linux平臺(tái)下的實(shí)現(xiàn)基于epoll，在windows下基于iocp。其商業(yè)應(yīng)用非常廣泛。Boost庫本身還支持很多常有用的開源庫，如regex正則表達(dá)式算法，它本身是基于STL的二次開發(fā)。嘰覲詿縲鐋囁偽純鉿錈癱懇跡。Muduomuduo 是一個(gè)基于 Reactor模式的現(xiàn)代 C++ 網(wǎng)絡(luò)庫,它采用非阻塞 IO 模型,基于事件驅(qū)動(dòng)和回調(diào),原生支持多核多線程,適合編寫Linux服務(wù)端多線程網(wǎng)絡(luò)應(yīng)用程序。這是一個(gè)國內(nèi)個(gè)人寫的開源庫，有專門介紹的書，網(wǎng)上熱評(píng)較多，據(jù)其書上測試數(shù)據(jù)所描述，其性能要稍5/8好于libevent 與boost。熒紿譏鉦鏌觶鷹緇機(jī)庫圓鍰緘。Node.jsNode.js是一套用來編寫高性能網(wǎng)絡(luò)服務(wù)器的 JavaScript 工具包。Node.js可以在不新增額外線程的情況下， 依然可以對(duì)任務(wù)進(jìn)行并行處理， Node.js是單線程的。 它通過事件輪詢 （eventloop）來實(shí)現(xiàn)并行操作。 鶼漬螻偉閱劍鯫腎邏蘞闋簣擇。但它是一個(gè)新興的后臺(tái)語言， 網(wǎng)絡(luò)資源相對(duì)較小，需要對(duì) javascript的事件驅(qū)動(dòng)非常熟悉。調(diào)試方面比較困難。后期維護(hù)較難。紂憂蔣氳頑薟驅(qū)藥憫騖覲僨鴛。開源庫主要優(yōu)點(diǎn)主要缺點(diǎn)Libevent跨平臺(tái)/支持安全機(jī)制ssl/有事件機(jī)制/DNS支基于其上開發(fā)網(wǎng)絡(luò)庫，還需要持實(shí)現(xiàn)很多網(wǎng)絡(luò)模塊。Libev類似libevent,包含它的所有功能，官方描述其網(wǎng)上評(píng)價(jià)相對(duì)來說libevent應(yīng)性能比它好。用較廣泛。ACE封裝程度高，模式框架強(qiáng)，支持事件驅(qū)動(dòng)，學(xué)生用于論文研究開發(fā)的網(wǎng)跨平臺(tái)。絡(luò)通訊庫，學(xué)術(shù)性強(qiáng)，應(yīng)用及性能較差，模式復(fù)雜。ICE支持分布式系統(tǒng)，支持多語言，多操作系統(tǒng)，應(yīng)用不太廣泛，是一個(gè)公司的是一個(gè)zeroc公司開發(fā)的庫，應(yīng)用不是很廣網(wǎng)絡(luò)開源通訊庫。二次開發(fā)待泛，被稱為ACE的輕量級(jí)別。驗(yàn)證。Boost::asio跨平臺(tái)，本身利用epoll與iocp模型就為了支充分了解boost開源庫需要一持多路連接并發(fā)考慮的庫。商業(yè)應(yīng)用非常廣定時(shí)間，其主要利用泛型編程泛，其庫有可能納入C++規(guī)范里面做教材用模式。Muduo非阻塞，多線程，支持linux平臺(tái)，其利用通個(gè)人網(wǎng)絡(luò)庫，知名度應(yīng)用方面訊模型epoll實(shí)現(xiàn)應(yīng)用。書中的測試數(shù)據(jù)顯示，不如libevent與boost,但是其單臺(tái)服務(wù)器（硬件配置8核CPU，16G內(nèi)存）書熱評(píng)很多。已經(jīng)實(shí)現(xiàn)10000臺(tái)終端連接數(shù)，并有與其他開源庫測試性能比較。Node.js官方描述，高性能網(wǎng)絡(luò)服務(wù)器的JavaScript基于javascript的新型網(wǎng)絡(luò)工具包。Node.js可以在不新增額外線程的情庫，應(yīng)用時(shí)間較短，調(diào)試麻煩，況下，依然可以對(duì)任務(wù)進(jìn)行并行處理，后期維護(hù)困難。Node.js是單線程的。它通過事件輪詢（event它的單線程模式，對(duì)現(xiàn)在的硬loop）來實(shí)現(xiàn)并行操作件多核處理器來說，利用不了多核的優(yōu)勢?；谝陨媳容^，主要選商業(yè)應(yīng)用較廣泛，開源時(shí)間較長，庫功能豐富的Boost::asio第三方開源庫,另外兩個(gè)個(gè)人與公司的開源庫Muduo和ICE待驗(yàn)證作為備選。穎芻莖蛺餑億頓裊賠瀧漲負(fù)這。2.2 服務(wù)器集群方案6/8[圖一：標(biāo)準(zhǔn)集群Server架構(gòu)方案]DNS均衡服務(wù)器原理:就是1個(gè)主機(jī)紀(jì)錄對(duì)應(yīng)多個(gè)IPAddress(不同的多臺(tái)服務(wù)器或多張網(wǎng)卡),實(shí)現(xiàn)不同DNS客戶的均衡輪詢。濫驂膽閉驟羥闈詔寢賻減棲綜。我們先來了解下集群式服務(wù)器開發(fā)的常用幾個(gè)技術(shù)知識(shí):1：線程2：線程池3：內(nèi)存池線程，在服務(wù)器開發(fā)中，線程是一個(gè)非常重要的概念，尤其是現(xiàn)在多核服務(wù)器的發(fā)展。當(dāng)然，提到了線程自然應(yīng)該說到線程之間的互斥。這也是服務(wù)器開發(fā)者們?cè)陂_發(fā)最初最容易出現(xiàn)的問題。體現(xiàn)在一個(gè)資源或者多個(gè)資源在多個(gè)線程中共享使用如何避免出現(xiàn)臟數(shù)據(jù)的問題。銚銻縵嚌鰻鴻鋟謎諏涼鏗穎報(bào)。線程池，池，這里相當(dāng)是一個(gè)存儲(chǔ)容器。這是一個(gè)由多個(gè)線程組成的一個(gè)隊(duì)列，當(dāng)有事情發(fā)生時(shí)候，我們把當(dāng)前的空閑的線程丟給他，為他服務(wù)。當(dāng)下一個(gè)事件發(fā)生的時(shí)候，我們又從池里面取一個(gè)空閑的線程丟給他，為他服務(wù)。當(dāng)服務(wù)完畢，把線程丟回池中。起到反復(fù)利用的目的。這樣比程序處理業(yè)務(wù)時(shí)，反復(fù)申請(qǐng)與關(guān)閉線程對(duì)資源的利用更有效率。擠貼綬電麥結(jié)鈺贖嘵類羋罷鴇。內(nèi)存池，同樣也是一個(gè)池。這個(gè)概念的產(chǎn)生是為了避免服務(wù)器頻繁的分配內(nèi)存，而采取預(yù)先分配一定數(shù)目的對(duì)象，并將對(duì)象們放到隊(duì)列中，當(dāng)需要的時(shí)候，從該隊(duì)列中取出，當(dāng)用完，就返回池中。比如我們的 Server可能會(huì)存在 10000 個(gè)連接，我們預(yù)先開辟 10000 個(gè)Client對(duì)象，存儲(chǔ)在 list<Client*>pFreeClientsList 中，當(dāng)需要的時(shí)候，從隊(duì)列中 pop一個(gè)出來，當(dāng)使用完畢就丟回 pFreeClientsList 。這種機(jī)制很好的起到了避免頻繁開辟內(nèi)存對(duì)象的目的， 可以很好的提高系統(tǒng)的性能。 賠荊紳諮侖驟遼輩襪錈極嚕辮。從上面集群 Server架構(gòu)方案圖，我們可以理解出如下服務(wù)器通訊過程：ConnServe 里面存在一個(gè) List_LogicServer 對(duì)象， 該對(duì)象監(jiān)聽端口， 當(dāng)有LogicServer 連接過7/8來，將該 LogicServer 存入隊(duì)列，并實(shí)時(shí)獲取該 Server當(dāng)前的壓力情況，可以起到一個(gè)負(fù)載均衡的作用。而保持的 List_LogicServer 隊(duì)列，當(dāng)客戶端連接過來， ConnServer 則從List_LogicServer 中將當(dāng)前 currentConn 最小的服務(wù)器發(fā)送給客戶端，以后客戶端將同該塤礙籟饈決穩(wěn)賽釙冊(cè)庫麩適緄。LogicServer發(fā)起連接。在該系統(tǒng)中，當(dāng)我們的 ConnServer 不夠的時(shí)候，可以考慮架設(shè)多臺(tái) ConnServer，當(dāng)客戶端無法連接時(shí)候， 程序自動(dòng)連接下一臺(tái) ConnServer. 這個(gè)由圖上的 DNS均衡服務(wù)器實(shí)現(xiàn)，使得大量移動(dòng)終端同時(shí)訪問時(shí)，由 DNS均衡服務(wù)器，分配當(dāng)前壓力較小的 ConnServer 去短連接并驗(yàn)證，驗(yàn)證登陸成功后，再把該 ConnServer 下對(duì)應(yīng)的壓力較小的 LogicServer 與該終端長連接 TCP通訊(域名服務(wù)有利于服務(wù)器端動(dòng)態(tài) IP變換而設(shè)備終端不受影響，只需要記住一個(gè)總的服務(wù)器域名即可 )。裊樣祕(mì)廬廂顫諺鍘羋藺遞燦擾。DNS域名服務(wù)器：使得終端只需要記住一個(gè)固定的域名就行，服務(wù)器 IP變換不會(huì)影響到終端的更新。終端訪問域名后，實(shí)際會(huì)把終端信息轉(zhuǎn)接到均衡服務(wù)器上來，均衡服務(wù)器先把壓力最小的ConnServer 分配給它讓它登陸驗(yàn)證。登陸驗(yàn)證成功后， ConnServer 再分配具體的 LogicServer與它長連接進(jìn)行業(yè)務(wù)數(shù)據(jù)通信。 倉嫗盤紲囑瓏詁鍬齊驁絛鯛鱧。均衡服務(wù)器，就是管理分配