交易并行度設(shè)計

yulihua49

初次架構(gòu)并行交易系統(tǒng)的朋友們，往往注重并行度，異步化這些問題。
但是，事情并非是越并行，越異步越好。
先說并行度的問題：
在一個分布式交易系統(tǒng)中，有好多環(huán)節(jié)分布在不同的服務(wù)器上，每個環(huán)節(jié)會產(chǎn)生每個環(huán)節(jié)的瓶頸。但是，整個系統(tǒng)必然有一個主瓶頸。最常見的主瓶頸是數(shù)據(jù)庫，有時也可能是網(wǎng)絡(luò)帶寬。
對于數(shù)據(jù)庫來說，有一個最佳并行度，它不是一個值，而是一個范圍，在這個范圍之外效率會降低。其他環(huán)節(jié)的并行度，受限于這個并行度，過高的并行度并無好處。
再說異步操作問題：
并非是異步操作比同步操作高效，相反，異步操作通常效率較低（這里所說的異步，并不單純指異步IO，有些業(yè)務(wù)處理也可以異步的）。那么我們?yōu)槭裁匆�考慮異步操作呢？為了并行操作服務(wù)。
異步操作是為了騰出CPU進(jìn)行其他任務(wù)，也就是并行輔助手段。并行和異步都是有開銷的,有時開銷還很大。
如果一個大的作業(yè)被劃分成小的并行單元，這個單元過小，為他付出并行和異步開銷是否合算？

所以，并行架構(gòu)設(shè)計要注意三個適度：

適度并行。

適度異步。

適度粒度（批量）.

對于OLAP（在線分析處理，通常是在線交易分析），對于大批量的數(shù)據(jù)源，通常是需要拆分成小的并行單元。他的處理環(huán)節(jié)也比較多，哪里設(shè)計并行，哪里需要異步，批次大小的選擇，有時就需要一個或幾個demo系統(tǒng)，綜合評價一下。
而OLTP（在線交易處理），通常處理的顆粒度很小，往往需要合并。一個用戶不太容易與另外的用戶合并。應(yīng)該是把自己的各個步驟合并，而不是拆分。典型的，例如12306那樣的交易系統(tǒng)，可以把：到發(fā)站車次查詢，時刻表查詢，票價查詢，席位余額查詢合并。事實上也是這么做的。

hellioncu

說了跟沒說一樣

windoze

回復(fù) 1# yulihua49

加點細(xì)節(jié)吧，有實例最好。
然后就可以入選精華了

cokeboL

新產(chǎn)品的話，寧愿golang從頭，大多數(shù)情況都是順序編程

yulihua49

yulihua49 發(fā)表于 2015-08-17 11:21
初次架構(gòu)并行交易系統(tǒng)的朋友們，往往注重并行度，異步化這些問題。
但是，事情并非是越并行，越異步越好。 ...

這是在一個OLAP項目中有感，設(shè)計者做了一個處處異步，點點并行的方案，粒度劃分的非常小。
有一個普遍的意識，似乎異步處理性能要高于同步處理。

我的想法是在拆分(map-reduce的主map點）的主節(jié)點上提供有限的異步就可以了。
比如后臺有8個并行度，主分發(fā)節(jié)點map異步發(fā)出16個包，其中8個被處理，8個在等待。然后就不必繼續(xù)map了，等一下，處理掉多少再map多少。盡量減少處于未完成狀態(tài)的交易數(shù)量。（設(shè)計者的觀點，數(shù)據(jù)全部抓過來，處理不了的都放在內(nèi)存隊列，好巨大啊，都是未完成態(tài)，然后是事務(wù)完整性管理。。。哪些做好了，哪些失敗了，需要commit？rollback？redo？abort？。處處異步，無限度的異步。）
其余節(jié)點都是同步處理，這樣容易保證交易完整性。

還有粒度，小到一個處理只需幾十微秒，為他開銷了好幾個毫秒的異步和并行。

yulihua49

cokeboL 發(fā)表于 2015-08-17 13:40
新產(chǎn)品的話，寧愿golang從頭，大多數(shù)情況都是順序編程

一個舊系統(tǒng)改造項目，重新架構(gòu)。原系統(tǒng)是順序的串行系統(tǒng)，單節(jié)點操作。新系統(tǒng)是多節(jié)點并行操作，一個是要性能，二是要容錯，不能有單點故障。語言不是問題，關(guān)鍵是架構(gòu)，這也看出架構(gòu)對系統(tǒng)的重要性。
每天要分析4400萬交易，邏輯還是相當(dāng)?shù)膹?fù)雜。

fender0107401

Good！

fender0107401

雖然我的系統(tǒng)也要處理打量的數(shù)據(jù)，不過邏輯什么的還是相對簡單的。

cokeboL

回復(fù) 6# yulihua49


    如果用go的話，可能就不存在這幾個問題了

yulihua49

fender0107401 發(fā)表于 2015-08-17 15:07
雖然我的系統(tǒng)也要處理打量的數(shù)據(jù)，不過邏輯什么的還是相對簡單的。

如果邏輯簡單，也沒什么性能、容錯方面的要求，當(dāng)然架構(gòu)就簡單些，誰也不愿意找麻煩。
但是你的業(yè)務(wù)發(fā)展了，有新的要求，架構(gòu)問題就提到桌面。
新接觸并行處理的架構(gòu)師們，需要一個合理的邏輯，或者叫理念，去設(shè)計他的系統(tǒng)。