現(xiàn)在是多核時(shí)代，并發(fā)才能實(shí)現(xiàn)更高的吞吐量、更快的響應(yīng)，但也是把雙刃劍。總結(jié)如下幾個(gè)用法：
c++多線程+顯示鎖；西安達(dá)內(nèi)培訓(xùn)（http://www.xatarena.net）講師表示，接口是被多線程調(diào)用的，當(dāng)被調(diào)用時(shí)，顯示加鎖，再操作實(shí)體數(shù)據(jù)。悲劇的是，工程師為了優(yōu)化會(huì)設(shè)計(jì)多個(gè)鎖，以減少鎖的粒度，甚至有些地方使用了原子操作。這些都為領(lǐng)域邏輯增加了額外的設(shè)計(jì)負(fù)擔(dān)。*壞的情況是會(huì)出現(xiàn)死鎖。
多線程+任務(wù)隊(duì)列；接口被多線程調(diào)用，但請(qǐng)求會(huì)被暫存到任務(wù)隊(duì)列，而任務(wù)隊(duì)列會(huì)被單線程不斷執(zhí)行，典型生產(chǎn)者消費(fèi)者模式。西安達(dá)內(nèi)科技培訓(xùn)講師表示，它的并發(fā)在于不同的接口可以使用不同的任務(wù)隊(duì)列。這也是我*常用的并發(fā)方式。
這是兩種*常見的多線程并發(fā)，它們有個(gè)天生的缺陷——Scalability。一個(gè)機(jī)器的性能總是有瓶頸的。兩個(gè)場(chǎng)景的邏輯雖然由多個(gè)線程實(shí)現(xiàn)了并發(fā)，但是運(yùn)算量十分有可能是一臺(tái)機(jī)器無法承載的。如果是多進(jìn)程并發(fā)，那么可以分布式把其部署到其他機(jī)器（也可部署在一臺(tái)機(jī)器）。所以多進(jìn)程并發(fā)比多線程并發(fā)更加Scalability。另外采用多進(jìn)程后，每個(gè)進(jìn)程單線程設(shè)計(jì)，這樣的程序更加Simplicity。多進(jìn)程的其他優(yōu)點(diǎn)如解耦、模塊化、方便調(diào)試、方便重用等就不贅言了。
異步消息/接口調(diào)用
提到分布式，就要說一下分布式的通訊技術(shù)。常用的方式如下：
類RPC；包括WebService、RPC、ICE等，特點(diǎn)是遠(yuǎn)程同步調(diào)用。遠(yuǎn)程的接口和本地的接口非常相似。但是游戲服務(wù)器程序一般非常在意延遲和吞吐量，所以這些阻塞線程的同步遠(yuǎn)程調(diào)用方式并不常用。但是我們必須意識(shí)到他的優(yōu)點(diǎn)，就是非常利于調(diào)用和測(cè)試。
全異步消息；當(dāng)調(diào)用遠(yuǎn)程接口的時(shí)候，異步發(fā)送請(qǐng)求消息，接口響應(yīng)后返回一個(gè)結(jié)果消息，調(diào)用方的回調(diào)函數(shù)處理結(jié)果消息繼續(xù)邏輯操作。所以有些邏輯就會(huì)被切割成ServiceStart和ServiceCallback兩段。有時(shí)異步會(huì)講領(lǐng)域邏輯變得支離破碎。另外消息處理函數(shù)中一般會(huì)寫一坨的switch/case 處理不同的消息。*大的問題在于單元測(cè)試，這種情況傳統(tǒng)單元測(cè)試根本束手無策。
消息的序列化與Reflection
實(shí)現(xiàn)消息的序列化和反序列化的方式有很多，常見的有Struct、json、Protobuff等都有很成功的應(yīng)用。我個(gè)人傾向于使用輕量級(jí)的二進(jìn)制序列化，優(yōu)點(diǎn)是比較透明和高效，一切在掌握之中。在FFLIB 中實(shí)現(xiàn)了bin_encoder_t 和 bin_decoder_t 輕量級(jí)的消息序列化，幾十行代碼而已。 |
 |
|
手機(jī)站
您當(dāng)前位置是：商業(yè)機(jī)會(huì) >> 商務(wù)服務(wù) >> 軟件開發(fā) >> C++多線程與并發(fā)用法
聯(lián)系信息