[2012站慶技術(shù)討論]：如何設(shè)計分布式異步事件處理系統(tǒng)？（獲獎名單已公布-12-26）

xujg

回復(fù) 39# yifangyou

這兩句沒看出來說改造了TCP.

而且, "比TCP快"也是有前提的.
   

asdmonster

拋磚引玉,希望參與的熱情能夠混本書哈

在大容量，高并發(fā)的業(yè)務(wù)請求下，如何處理費力費資源的服務(wù)請求而不阻塞住，從而耽誤其他的服務(wù)，如何能快速響應(yīng)即時業(yè)務(wù)需求，例如，充值，就發(fā)短信通知等等。這些服務(wù)請求極有可能又分布在不同的服務(wù)器上，那如何處理這些分布式的請求呢。 那我們是否可以建立一個分布式的異步事件處理服務(wù)呢。
---------------------------------------
這個沖值發(fā)短信/通知的例子并不顯著的分布式的例子,如果我來描述分布式的需求大致是這樣:在1秒鐘內(nèi)有1000萬個沖值請求,但是每臺服務(wù)器僅能夠在1秒內(nèi)處理10條這樣的請求,所以,分布式的需求就這樣產(chǎn)生了.
所謂的異步請求是:充值需要10分鐘才能處理完,用戶不會等待10分鐘,于是,異步,提交了任務(wù)以后,用戶可以同時去做別的事情.
我覺得二者并不沖突,可以分別設(shè)計滿足其需求,對于分布式,重要的是任務(wù)的調(diào)度,單點錯誤的容忍性,最終結(jié)果的正確性一致性這些,對于異步系統(tǒng),無非就是建立等待隊列,任務(wù)分發(fā),任務(wù)結(jié)果分發(fā)或者回調(diào)什么的.這里面的每項技術(shù),都不復(fù)雜.

分布式異步事件處理是在例如處理不同事務(wù)的服務(wù)器通過網(wǎng)絡(luò)進行通信的分布式通信環(huán)境下，發(fā)送端發(fā)出承載消息的事件后不必等待接收端應(yīng)答就繼續(xù)執(zhí)行。而接收端在接收到事件之后采用異步的方式來處理事件。分布式異步事件處理解決了發(fā)送端必須等待接收端處理完畢事件后才能繼續(xù)執(zhí)行的問題，也解決了接收端并發(fā)處理多個發(fā)送端請求的事件的性能瓶頸問題，因此顯著提高了事件處理的效率。
-------------------------------------------
其實畫一張邏輯的拓撲圖,就很容易的看到系統(tǒng)的瓶頸(即多個任務(wù)需要最終同步的地方).一般而言,瓶頸無非是兩個地方:前端接收請求,后端匯總結(jié)果這兩個點.優(yōu)化策略嘛,無非就是將最終只能單步的任務(wù)盡可能的簡化唄.
需要提到一點的是,有些分布式系統(tǒng)號稱它的拓撲圖中所有的實例地位對等,也就沒有了我上面描述的那兩個瓶頸,但是據(jù)說也有個物理學(xué)家證明,這樣的系統(tǒng),理論上是不存在的.我更傾向于后者的觀點.

在分布式異步事件處理系統(tǒng)中，因為異步無等待，由于發(fā)送端沒有等待接收端的反饋就繼續(xù)執(zhí)行，那開發(fā)者又能如何知道服務(wù)是否已執(zhí)行完成呢？若是異步事件處理服務(wù)掛掉了，又怎么能讓沒有成功執(zhí)行的事件重入呢？
--------------------------------------------
基本上也就是注冊/通知機制，當(dāng)然，細節(jié)點，可能還有些什么任務(wù)序列化/調(diào)度等的問題。
更準(zhǔn)確地說，除非整個服務(wù)器或者其master節(jié)點（群）down機，這個是災(zāi)難性的，在正常運行時，分布式系統(tǒng)需要處理的是，參與分布式的某個節(jié)點故障的時候，將該節(jié)點的任務(wù)轉(zhuǎn)移到別的有效節(jié)點的問題。還有在啟動/災(zāi)難恢復(fù)時，如何選舉出仲裁者的問題。
對于分布式系統(tǒng)中的實例特別是實際的工作實例而言，它不關(guān)心自己是同步還是異步的，它需要做的是，將系統(tǒng)現(xiàn)有的任務(wù)，按著既定的調(diào)度策略執(zhí)行完。同步還是異步，是接口考慮的問題，也僅僅是接口需要考慮的問題。

crazyhadoop

回復(fù) 37# propsyche


    方法很不錯，scribe是個好東西，不過還是有些弱，syslog可以考慮一下

pitonas

太專業(yè)了

tulip0425

呵呵,謝謝樓主了~~~~~~~~~~~