服務(wù)器通信技術(shù)方案

1、服務(wù)器通信技術(shù)方案前言11服務(wù)器通訊需要解決的問(wèn)題2矚慫潤(rùn)厲釤瘞睞櫪廡賴賃軔朧。1.1單臺(tái)RCU設(shè)備通訊情況 2聞創(chuàng)溝燴鐺險(xiǎn)愛(ài)氌譴凈禍測(cè)樅。1.2上萬(wàn)個(gè)RCU甚至達(dá)到將近百萬(wàn)終端與服務(wù)器同時(shí)通訊2殘騖樓諍錈瀨濟(jì)溆塹籟婭驟東單臺(tái)服務(wù)器2釅錒極額閉鎮(zhèn)檜豬訣錐顧葒鈀。集群服務(wù)器2彈貿(mào)攝爾霽斃攬磚鹵廡詒爾膚。2. 目前服務(wù)器通訊主流技術(shù)方案3謀蕎摶篋飆鐸懟類蔣薔點(diǎn)鉍雜。2.1 網(wǎng)上常用主流方案簡(jiǎn)介與比較3廈礴懇蹣駢時(shí)盡繼價(jià)騷巹癩龔。2.1.1 傳統(tǒng)的socket通訊模型 3煢楨廣鰳鯡選塊網(wǎng)羈淚鍍齊鈞。2.1.2 Windows下IOCP模型3鵝婭盡損鶴慘歷蘢鴛賴縈詰聾。2.1.3 linux下epol

2、l模型4籟叢媽羥為贍債蟶練淨(jìng)櫧撻曉。2.1.4 其它的網(wǎng)絡(luò)通訊第三方開(kāi)源庫(kù)簡(jiǎn)介及比較5預(yù)頌圣鉉儐歲齦訝驊糴買闥齙。2.2服務(wù)器集群方案 6滲釤嗆儼勻諤鱉調(diào)硯錦鋇絨鈔。3. 根據(jù)項(xiàng)目情況選擇最合適方案8鐃誅臥瀉噦圣騁貺頂廡縫勵(lì)羆。3.1推薦選擇linux系統(tǒng)下的epoll及開(kāi)源庫(kù)Boost:asio8擁締鳳襪備訊顎輪爛薔報(bào)贏無(wú)。3.2 可能問(wèn)題8贓熱俁閫歲匱閶鄴鎵騷鯛漢鼉。修訂記錄序號(hào)版本號(hào)修訂內(nèi)容修訂人修訂日期1.00.000第一個(gè)版本顏冬2013.09.07前言RCU-U設(shè)備采集數(shù)據(jù)如：車輛診斷，通過(guò) GSM基站定位，內(nèi)置 GPS, GPRS系統(tǒng)提供遠(yuǎn)程 數(shù)據(jù)，對(duì)車輛各個(gè)系統(tǒng)的運(yùn)行狀況（如

3、ENG、ABS、ETC等）實(shí)時(shí)監(jiān)測(cè)狀態(tài)數(shù)據(jù)等。 壇搏鄉(xiāng)囂 懺蔞鍥鈴氈淚躋馱釣。這些數(shù)據(jù)的網(wǎng)絡(luò)通訊平臺(tái)， 則由服務(wù)器提供的通訊技術(shù)來(lái)實(shí)現(xiàn)，因此如何實(shí)現(xiàn)這種多設(shè)備數(shù)據(jù)同時(shí)接收的技術(shù)方案很重要。本文將詳細(xì)介紹相關(guān)技術(shù)及提出方案。蠟變黲癟報(bào)倀鉉錨鈰贅籜葦繯。服務(wù)器通訊需要解決的問(wèn)題單臺(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)車每天平均開(kāi)

4、動(dòng)1小時(shí)或2小時(shí)（實(shí)際產(chǎn)生數(shù)據(jù)時(shí)間）；RCU數(shù)量（個(gè)）1秒1小時(shí)2小時(shí)10.1kb360kb720kb1萬(wàn)1000kb3515M7030M0.97M3.43G6.86G100萬(wàn)100,000kb97M343G686G1000 萬(wàn)1000,000kb3430G6860G970M3.35TB6.70TB從上數(shù)據(jù)顯示如果達(dá)到：100萬(wàn)級(jí)別的RCU用戶量，需要服務(wù)器有近百兆的網(wǎng)絡(luò)帶寬吞吐量。1000萬(wàn)級(jí)別的RCU用戶量，需要服務(wù)器有近千兆的網(wǎng)絡(luò)帶寬吞吐量。上萬(wàn)個(gè)RCU甚至達(dá)到將近百萬(wàn)終端與服務(wù)器同時(shí)通訊單臺(tái)服務(wù)器如果按照經(jīng)典的server/client通訊模型，當(dāng)有一個(gè)設(shè)備通過(guò)（TCP/UDP）連接服

5、務(wù)器時(shí)，服務(wù)端單獨(dú)開(kāi)一個(gè)線程為這個(gè)設(shè)備數(shù)據(jù)服務(wù)，顯然，當(dāng)路數(shù)越多，我們的設(shè)備又是長(zhǎng)連接方式，很快服務(wù)器將在設(shè)備近千路時(shí)服務(wù)器資源將達(dá)到上限，并且存在大量線程切換與管理問(wèn)題。這時(shí)如果我們能合理利用單臺(tái)服務(wù)器資源（如：windows下iocp模式，linux下的epoll網(wǎng)絡(luò)通信模式等），在更優(yōu)的管理模式下，將能接更多設(shè)備的服務(wù)（網(wǎng)上資料預(yù)估幾千路的長(zhǎng) 連接甚至硬件較好配置下達(dá)到萬(wàn)路以上）。上面我們能在單臺(tái)服務(wù)器在較好硬件配置和軟件優(yōu)化的模型管理下，能解決幾千路上萬(wàn)路設(shè)備的長(zhǎng)連接。買鯛鴯譖曇膚遙閆擷凄屆嬌擻。集群服務(wù)器但是，如果幾十萬(wàn)臺(tái)甚至接近百萬(wàn)級(jí)別的設(shè)備數(shù)量同時(shí)訪問(wèn)服務(wù)端時(shí)，這個(gè)時(shí)候需要涉及到

6、一種合理的集群服務(wù)器架構(gòu)模式。理論上，為了達(dá)到1:10000的連接，可以采用Server-Client的連接方式，而為了達(dá)到1:10000*100的連接，我們?cè)趺崔k呢？ 一般會(huì)采用Clie nt->Conn Server -> LogicServer。相當(dāng)于有一批服務(wù)器來(lái)合理布局解決設(shè)備的大并發(fā)通訊問(wèn)題。綾鏑鯛駕櫬鶘蹤韋轔糴飆銃麥。Conn Server在接受完Clie nt的連接后，將Logic Server暴露給Clie nt,并立刻斷開(kāi)連接，稱 之為短連接。以后的數(shù)據(jù)交互就和Conn Server沒(méi)有關(guān)系了，讓 Logic Server直接跟client再長(zhǎng)連接通訊，這種架構(gòu)

7、有很多的優(yōu)勢(shì)。驅(qū)躓髏彥浹綏譎飴憂錦諑瓊針。Illdl一忙域占底LiWR機(jī)riv機(jī) 備（觴蜒訊并配陌力儷）jam. a=rei垃fij號(hào)暑廠 frBi'Mnr Er&i-Jim琴ya舞端登錄失效r '.乓>f-圖一：標(biāo)準(zhǔn)集群 Server架構(gòu)方案目前服務(wù)器通訊主流技術(shù)方案2.1網(wǎng)上常用主流方案簡(jiǎn)介與比較傳統(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是一種無(wú)連 接的Sock

8、et，對(duì)應(yīng)于無(wú)連接的 UDP服務(wù)應(yīng)用。貓蠆驢繪燈鮒誅髏貺廡獻(xiàn)鵬縮。一般小型的c/s通訊系統(tǒng)利用socket API和結(jié)合一個(gè)線程對(duì)應(yīng)一個(gè)客戶的開(kāi)發(fā)模式。如果路數(shù)增多，容易耗盡服務(wù)端資源。該通訊模型利用硬件資源效率不高。 鍬籟饗逕瑣筆襖鷗婭薔嗚訝擯。下 IOCP 模型IOCP完成端口模型又是怎樣實(shí)現(xiàn)的呢？首先我們創(chuàng)建一個(gè)完成端口 CreatelOCompletio nPort。綁定端口之后，建立一個(gè)監(jiān)聽(tīng)線程，用來(lái)監(jiān)聽(tīng)客戶端的連接，當(dāng) 有連接進(jìn)來(lái)時(shí)，將該連接的套接字加入到IOCP對(duì)隊(duì)列中，同時(shí)再創(chuàng)建幾個(gè)工作線程（ CPU數(shù)*2+2），工作線程調(diào)用 getQueuedCompletionStatus

9、方法在關(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ì)象，使得非1/ O處理和1/ O處理能重疊并行地操作。該對(duì)象通過(guò)指定工作線程的數(shù)量，對(duì)重疊的I / O操作進(jìn)行處理。當(dāng)一個(gè)事件發(fā)生，此完成端口就被操作系統(tǒng)加入一個(gè)隊(duì)列中，然后應(yīng)用程序可以對(duì)核心層進(jìn)行查詢以得到此完成端 口。IOCP的核心思想簡(jiǎn)單說(shuō)就是：將所有用戶的請(qǐng)求都投遞到一個(gè)消息隊(duì)

10、列中，利用事先 創(chuàng)建好的若干個(gè)工作線程逐一從消息隊(duì)列中取出消息并加以處理。這樣不僅減少了線程資 源，也大大提高了線程的利用率。要注意的是，所謂完成端口，實(shí)際上是Windows采用的一種I/O構(gòu)造機(jī)制，并非通常所說(shuō)的端口（如Port: 80）。輒嶧陽(yáng)檉籪癤網(wǎng)儂號(hào)澩蠐鑭釃。創(chuàng)狂先戦端口引任存X q解工事斗班丄開(kāi)外工窗肛*1-11工卅連徑羔聯(lián)擁完成耀I(xiàn)IiS1堀業(yè)理1r謹(jǐn)肝捋庫(kù)的i/o掾惟-一1折敲下-步的11111闍1 g喲工作流親下 epoll 模型epoll是Linux下多路復(fù)用10接口 select/poll的增強(qiáng)版本，它能顯著提高程序在大量并發(fā)連 接中只有少量活躍的情況下的系統(tǒng)CPU利用率

11、。因?yàn)樗鼤?huì)復(fù)用文件描述符集合來(lái)傳遞結(jié)果而不用迫使開(kāi)發(fā)者每次等待事件之前都必須重新準(zhǔn)備要被偵聽(tīng)的文件描述符集合，另一點(diǎn)原因就是獲取事件的時(shí)候，它無(wú)須遍歷整個(gè)被偵聽(tīng)的描述符集，只要遍歷那些被內(nèi)核10事件異步喚醒而加入 Ready隊(duì)列的描述符集合就行了。epoll除了提供select/poll那種10事件的電平觸發(fā)(Level Triggered )外，還提供了邊沿觸發(fā)(Edge Triggered )，這就使得用戶空間 程序有可能緩存IO狀態(tài)，減少epoll_wait/epoll_pwait的調(diào)用，提高應(yīng)用程序效率。堯側(cè)閏繭絳闕絢勵(lì)蜆贅瀝紕縭。傳統(tǒng)的select/poll另一個(gè)致命弱點(diǎn)就是當(dāng)你擁有

12、一個(gè)很大的socket集合，不過(guò)由于網(wǎng)絡(luò)延時(shí)，任一時(shí)間只有部分的 socket是 活躍"的，但是select/poll每次調(diào)用都會(huì)線性掃描全部的 集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個(gè)問(wèn)題，它只會(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)主要缺點(diǎn)傳統(tǒng)socket適合于連接量較小的通訊情況，通過(guò) socet API建立 C/S通訊。服務(wù)

13、連接路數(shù)小，IO沒(méi)有復(fù) 用，一般是一個(gè)線程對(duì)應(yīng)終端 的服務(wù)模式。通訊情況下，每 個(gè)socket句柄，包含不活躍 的連接也會(huì)需要遍歷。Windows 下 IOCP適合于大量連接數(shù)(上萬(wàn)路)，IO復(fù) 用，消息隊(duì)列，可指定相應(yīng)工作線程 數(shù)，輪詢端口的事件，充分利用多核， 高效率地服務(wù)于多并發(fā)。只跑在windows服務(wù)器下， 如果數(shù)據(jù)庫(kù)平臺(tái)為linux服務(wù) 器，影響系統(tǒng)功能模塊整合。linux 下 epoll適合于大量連接數(shù)(上萬(wàn)路)， 多路復(fù)用IO接口，只遍歷那些被內(nèi)核 IO事件異步喚醒而加入 Ready隊(duì)列的 描述符集合。通訊情況下，只對(duì)活躍 的連接遍歷，提咼了效率。當(dāng)前主流ET和LT模式下，其中

14、 LT模 式比較復(fù)雜，較難處理數(shù)據(jù)收 發(fā)。服務(wù)器為linux，也有系統(tǒng)優(yōu)勢(shì)?；谝陨媳容^，我們服務(wù)器的操作系統(tǒng)平臺(tái)是linux下（大數(shù)據(jù)庫(kù)的平臺(tái)也是），顯然大并發(fā)訪問(wèn)通訊模型linux下epoll更合適我們項(xiàng)目實(shí)際需求。凍鈹鋨勞臘錯(cuò)癇婦脛糴鈹賄鶚。其它的網(wǎng)絡(luò)通訊第三方開(kāi)源庫(kù)簡(jiǎn)介及比較Libeve ntlibevent是一個(gè)事件觸發(fā)的網(wǎng)絡(luò)庫(kù)，適用于windows、linux、bsd等多種平臺(tái)，內(nèi)部使用select、epoll、kqueue等系統(tǒng)調(diào)用管理事件機(jī)制。著名分布式緩存軟件 memcached也是libevent based，而且libevent在使用上可以做到跨平臺(tái)，而且根據(jù)libeve

15、nt官方網(wǎng)站上公布的數(shù)據(jù)統(tǒng)計(jì)，似乎也有著非凡的性能。恥諤銪滅縈歡煬鞏鶩錦聰櫻鄶。libevent包括事件管理、緩存管理、DNS、HTTP、緩存事件幾大部分。事件管理包括各種10（socket ）、定時(shí)器、信號(hào)等事件；緩存管理是指 evbuffer功能；DNS是libevent提供的一 個(gè)異步DNS查詢功能；HTTP是libevent的一個(gè)輕量級(jí) http實(shí)現(xiàn)，包括服務(wù)器和客戶端。libevent也支持ssl,這對(duì)于有安全需求的網(wǎng)絡(luò)程序非常的重要，但是其支持不是很完善，比如http server的實(shí)現(xiàn)就不支持 ssl。鯊腎鑰詘漣鉀溈懼統(tǒng)庫(kù)搖飭緡。Libevlibev是libevent之后的一個(gè)事

16、件驅(qū)動(dòng)的編程框架，其接口和libevent基本類似。據(jù)官方介紹，其性能比libevent還要高，bug比libevent還少。碩癘鄴頏謅攆檸攜驤蘞鷥膠據(jù)。ACE有人評(píng)價(jià)其框架模式很值得學(xué)習(xí)，但是其網(wǎng)絡(luò)應(yīng)用效率和開(kāi)發(fā)應(yīng)用相比其他開(kāi)源庫(kù)較差，這也是其主要用于研究很少用于商業(yè)應(yīng)用的原因，這方面不像boost應(yīng)用廣泛。應(yīng)用中需要充分理解其復(fù)雜的架構(gòu)模式。這不是短時(shí)間可掌握和靈活運(yùn)用的，相對(duì)來(lái)說(shuō)其他第三方網(wǎng)絡(luò)開(kāi)源庫(kù)相對(duì)模式精簡(jiǎn)很多。閿擻輳嬪諫遷擇植秘騖輛塤鵜。ICEZeroC ICE 是指 ZeroC 公司的 ICE（ Internet Communications Engine ）中間件平臺(tái)。對(duì)于客

17、戶端和服務(wù)端程序的開(kāi)發(fā)提供了很大的便利。氬嚕躑竄貿(mào)懇彈濾頷澩紛釓鄧。目前 ICE平臺(tái)中包括 Ice, Ice-E，Ice Touch。Ice為主流平臺(tái)設(shè)計(jì)，包括 Windows和Linux，支持廣泛的語(yǔ)言，包括C+，Java，C# （和其他.Net 的語(yǔ)言，例如 Visual Basic）， Python，Ruby， PHP 和 ActionScript。也包括所有的 ICE服務(wù)，例如Ice Grid，IceStorm等。釷鵒資贏車贖孫滅獅贅慶獷緞。Ice-E是Ice在資源受限的平臺(tái)上的一個(gè)實(shí)現(xiàn)，支持 C+和嵌入式操作系統(tǒng)，例如WindowsCE，Linux。Ice-E本身不包含任何服務(wù)，但是

18、可以利用在Ice上提供的各種服務(wù)。因此，通過(guò)Ice-E，移動(dòng)設(shè)備也能無(wú)縫的集成到分布式系統(tǒng)中。慫闡譜鯪逕導(dǎo)嘯畫長(zhǎng)涼馴鴇撟。Ice Touch是為iphone和ipod touch 開(kāi)發(fā)的版本，包括 Object-C 映射，支持Iphone OS ， 并為MAC OS X開(kāi)發(fā)圖形界面應(yīng)用程序提供完整的 Cocoa框架的訪問(wèn)。諺辭調(diào)擔(dān)鈧諂動(dòng)禪瀉類謹(jǐn) 覡鸞。Boost:asioBoost.Asio是利用當(dāng)代 C+的先進(jìn)方法 跨平臺(tái)，異步I/O模型的C+網(wǎng)絡(luò)庫(kù)，ASIO在Linux 平臺(tái)下的實(shí)現(xiàn)基于 epoll，在windows下基于iocp。其商業(yè)應(yīng)用非常廣泛。 Boost庫(kù)本身還 支持很多常有用的

19、開(kāi)源庫(kù)，如 regex正則表達(dá)式算法，它本身是基于 STL的二次開(kāi)發(fā)。嘰覲 詿縲鐋囁偽純鉿錈癱懇跡。Muduomuduo是一個(gè)基于 Reactor模式的現(xiàn)代 C+網(wǎng)絡(luò)庫(kù)，它采用非阻塞IO模型，基于事件驅(qū) 動(dòng)和回調(diào)，原生支持多核多線程，適合編寫Linux服務(wù)端多線程網(wǎng)絡(luò)應(yīng)用程序。 這是一個(gè)國(guó)內(nèi)個(gè)人寫的開(kāi)源庫(kù)，有專門介紹的書，網(wǎng)上熱評(píng)較多，據(jù)其書上測(cè)試數(shù)據(jù)所描述，其性能要稍好于libevent與 boost。熒紿譏鉦鏌觶鷹緇機(jī)庫(kù)圓鍰緘。Node.jsNode.js是一套用來(lái)編寫高性能網(wǎng)絡(luò)服務(wù)器的JavaScript工具包。Node.js可以在不新增額外線程的情況下，依然可以對(duì)任務(wù)進(jìn)行并行處理，No

20、de.js是單線程的。它通過(guò)事件輪詢(eventloop )來(lái)實(shí)現(xiàn)并行操作。鶼漬螻偉閱劍鯫腎邏蘞闋簣擇。但它是一個(gè)新興的后臺(tái)語(yǔ)言，網(wǎng)絡(luò)資源相對(duì)較小，需要對(duì) javascript的事件驅(qū)動(dòng)非常熟悉。調(diào)試方面比較困難。后期維護(hù)較難。紂憂蔣氳頑薟驅(qū)藥憫騖覲僨鴛。開(kāi)源庫(kù)主要優(yōu)點(diǎn)主要缺點(diǎn)Libeve nt跨平臺(tái)/支持安全機(jī)制ssl/有事件機(jī)制/DNS支持基于其上開(kāi)發(fā)網(wǎng)絡(luò)庫(kù)，還需要 實(shí)現(xiàn)很多網(wǎng)絡(luò)模塊。Libev類似libevent,包含它的所有功能，官方描述 其性能比它好。網(wǎng)上評(píng)價(jià)相對(duì)來(lái)說(shuō)libeve nt應(yīng)用較廣泛。ACE封裝程度高，模式框架強(qiáng)，支持事件驅(qū)動(dòng)， 跨平臺(tái)。學(xué)生用于論文研究開(kāi)發(fā)的網(wǎng) 絡(luò)通訊庫(kù)

21、，學(xué)術(shù)性強(qiáng)，應(yīng)用及 性能較差，模式復(fù)雜。ICE支持分布式系統(tǒng)，支持多語(yǔ)言，多操作系統(tǒng)， 是一個(gè)zeroc公司開(kāi)發(fā)的庫(kù)，應(yīng)用不是很廣 泛，被稱為ACE的輕量級(jí)別。應(yīng)用不太廣泛，是一個(gè)公司的 網(wǎng)絡(luò)開(kāi)源通訊庫(kù)。二次開(kāi)發(fā)待 驗(yàn)證。Boost:asio跨平臺(tái)，本身利用epoll與iocp模型就為了支持多路連接并發(fā)考慮的庫(kù)。商業(yè)應(yīng)用非常 廣泛，其庫(kù)有可能納入C+規(guī)范里面做教材用充分了解boost開(kāi)源庫(kù)需要 一定時(shí)間，其主要利用泛型編 程模式。Muduo非阻塞，多線程，支持linux平臺(tái)，其利用通 訊模型epoll實(shí)現(xiàn)應(yīng)用。書中的測(cè)試數(shù)據(jù)顯 示，單臺(tái)服務(wù)器(硬件配置8核CPU, 16G內(nèi)存)已經(jīng)實(shí)現(xiàn)1000

22、0臺(tái)終端連接數(shù)，并有 與其他開(kāi)源庫(kù)測(cè)試性能比較。個(gè)人網(wǎng)絡(luò)庫(kù)，知名度應(yīng)用方面 不如libevent與boost,但是其 書熱評(píng)很多。Node.js官方描述，咼性能網(wǎng)絡(luò)服務(wù)器的JavaScript工具包。Node.js可以在不新增額外線程的情 況下，依然可以對(duì)任務(wù)進(jìn)行并行處理， Node.js是單線程的。它通過(guò)事件輪詢(event loop )來(lái)實(shí)現(xiàn)并行操作基于javascript的新型網(wǎng)絡(luò) 庫(kù)，應(yīng)用時(shí)間較短，調(diào)試麻煩， 后期維護(hù)困難。它的單線程模式，對(duì)現(xiàn)在的硬 件多核處理器來(lái)說(shuō)，利用不了 多核的優(yōu)勢(shì)?；谝陨媳容^，主要選商業(yè)應(yīng)用較廣泛，開(kāi)源時(shí)間較長(zhǎng)，庫(kù)功能豐富的Boost:asio第三方開(kāi)源庫(kù)，

23、另外兩個(gè)個(gè)人與公司的開(kāi)源庫(kù) Muduo和ICE待驗(yàn)證作為備選。穎芻莖峽餑億頓裊賠瀧漲 負(fù)這。2.2服務(wù)器集群方案Illdl一忙域占底LiWR機(jī)riv機(jī) 備（觴蜒訊并配陌力儷）jam. a=rei垃fij號(hào)暑廠 frBi'Mnr Er&i-Jim琴ya舞端登錄失效r '.乓>f-圖一：標(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客戶的均衡輪詢。濫驂膽閉驟羥闈詔寢賻減棲綜。我們先來(lái)了解下集群式服務(wù)器開(kāi)發(fā)的常用幾個(gè)技術(shù)知識(shí)：1:線程2:線程池3:內(nèi)存池線程，在服務(wù)器開(kāi)發(fā)中，線

24、程是一個(gè)非常重要的概念，尤其是現(xiàn)在多核服務(wù)器的發(fā)展。當(dāng)然,提到了線程自然應(yīng)該說(shuō)到線程之間的互斥。這也是服務(wù)器開(kāi)發(fā)者們?cè)陂_(kāi)發(fā)最初最容易出現(xiàn)的問(wèn)題。體現(xiàn)在一個(gè)資源或者多個(gè)資源在多個(gè)線程中共享使用如何避免出現(xiàn)臟數(shù)據(jù)的問(wèn)題。銚銻縵嚌鰻鴻鋟謎諏涼鏗穎報(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)存池，同樣也是一

25、個(gè)池。這個(gè)概念的產(chǎn)生是為了避免服務(wù)器頻繁的分配內(nèi)存，而采取預(yù)先分配一定數(shù)目的對(duì)象，并將對(duì)象們放到隊(duì)列中，當(dāng)需要的時(shí)候，從該隊(duì)列中取出，當(dāng)用完， 就返回池中。比如我們的Server可能會(huì)存在10000個(gè)連接，我們預(yù)先開(kāi)辟10000個(gè)Client對(duì)象，存儲(chǔ)在list<Clie nt *> pFreeClie ntsList 中，當(dāng)需要的時(shí)候，從隊(duì)列中pop 個(gè)出來(lái)，當(dāng)使用完畢就丟回pFreeClientsList。這種機(jī)制很好的起到了避免頻繁開(kāi)辟內(nèi)存對(duì)象的目的，可以很好的提高系統(tǒng)的性能。賠荊紳諮侖驟遼輩襪錈極嚕辮。從上面集群Server架構(gòu)方案圖，我們可以理解出如下服務(wù)器通訊過(guò)程：Co

26、nn Serve里面存在一個(gè) List_LogicServer對(duì)象，該對(duì)象監(jiān)聽(tīng)端口，當(dāng)有LogicServer連接過(guò)來(lái)，將該LogicServer存入隊(duì)列，并實(shí)時(shí)獲取該Server當(dāng)前的壓力情況，可以起到一個(gè)負(fù)載均衡的作用。而保持的List_LogicServer隊(duì)列，當(dāng)客戶端連接過(guò)來(lái)，Conn Server則從List_LogicServer中將當(dāng)前 currentConn最小的服務(wù)器發(fā)送給客戶端，以后客戶端將同該 LogicServer發(fā)起連接。塤礙籟饈決穩(wěn)賽釙冊(cè)庫(kù)麩適緄。在該系統(tǒng)中，當(dāng)我們的Conn Server不夠的時(shí)候，可以考慮架設(shè)多臺(tái)Conn Server，當(dāng)客戶端無(wú)法連接時(shí)候，程

27、序自動(dòng)連接下一臺(tái)Conn Server.這個(gè)由圖上的DNS均衡服務(wù)器實(shí)現(xiàn)，使得大量移動(dòng)終端同時(shí)訪問(wèn)時(shí)，由DNS均衡服務(wù)器，分配當(dāng)前壓力較小的Conn Server去短連接并驗(yàn)證，驗(yàn)證登陸成功后，再把該 Conn Server下對(duì)應(yīng)的壓力較小的Logic Server與該終端長(zhǎng)連接 TCP通訊（域名服務(wù)有利于服務(wù)器端動(dòng)態(tài)IP變換而設(shè)備終端不受影響，只需要記住一個(gè)總的服務(wù)器域名即可）。裊樣祕(mì)廬廂顫諺鍘羋藺遞燦擾。DNS域名服務(wù)器：使得終端只需要記住一個(gè)固定的域名就行，服務(wù)器IP變換不會(huì)影響到終端的更新。終端訪問(wèn)域名后，實(shí)際會(huì)把終端信息轉(zhuǎn)接到均衡服務(wù)器上來(lái)，均衡服務(wù)器先把壓力最小的Conn Server分配給它讓它登陸驗(yàn)證。登陸驗(yàn)證成功后，Conn Server再分配具體的 LogicServer與它長(zhǎng)連接進(jìn)行業(yè)務(wù)