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

send_linux

獲獎(jiǎng)名單已公布，詳情請(qǐng)看：http://72891.cn/thread-4060812-1-1.html  

站慶活動(dòng)：
2012站慶活動(dòng)拉開大幕，歡迎大家積極參與！所有參與ChinaUnix社區(qū)11周年站慶的朋友，都有機(jī)會(huì)獲得站慶定制禮品一份！

話題背景：
在大容量，高并發(fā)的業(yè)務(wù)請(qǐng)求下，如何處理費(fèi)力費(fèi)資源的服務(wù)請(qǐng)求而不阻塞住，從而耽誤其他的服務(wù)，如何能快速響應(yīng)即時(shí)業(yè)務(wù)需求，例如，充值，就發(fā)短信通知等等。這些服務(wù)請(qǐng)求極有可能又分布在不同的服務(wù)器上，那如何處理這些分布式的請(qǐng)求呢。 那我們是否可以建立一個(gè)分布式的異步事件處理服務(wù)呢。

分布式異步事件處理是在例如處理不同事務(wù)的服務(wù)器通過網(wǎng)絡(luò)進(jìn)行通信的分布式通信環(huán)境下，發(fā)送端發(fā)出承載消息的事件后不必等待接收端應(yīng)答就繼續(xù)執(zhí)行。而接收端在接收到事件之后采用異步的方式來處理事件。分布式異步事件處理解決了發(fā)送端必須等待接收端處理完畢事件后才能繼續(xù)執(zhí)行的問題，也解決了接收端并發(fā)處理多個(gè)發(fā)送端請(qǐng)求的事件的性能瓶頸問題，因此顯著提高了事件處理的效率。

在分布式異步事件處理系統(tǒng)中，因?yàn)楫惒綗o等待，由于發(fā)送端沒有等待接收端的反饋就繼續(xù)執(zhí)行，那開發(fā)者又能如何知道服務(wù)是否已執(zhí)行完成呢？若是異步事件處理服務(wù)掛掉了，又怎么能讓沒有成功執(zhí)行的事件重入呢？

討論話題：
現(xiàn)實(shí)中，你會(huì)如何設(shè)計(jì)這樣的一個(gè)系統(tǒng)呢？

邀請(qǐng)嘉賓：
happy_fish100：分布式文件系統(tǒng)版版主，F(xiàn)astDFS文件系統(tǒng)作者
crazyhadoop：Linux環(huán)境編程版版主
T-Bagwell：嵌入式開發(fā)版版主


活動(dòng)時(shí)間：
2012.11.16-2012.12.06

活動(dòng)要求：
1，針對(duì)本次話題說說您對(duì)分布式異步處理系統(tǒng)的理解
2，分享您在開發(fā)、部署和運(yùn)維這些異步處理系統(tǒng)中的經(jīng)驗(yàn)
                 
討論有獎(jiǎng)：
活動(dòng)結(jié)束后，我們會(huì)評(píng)選出四位積極參與話題討論的網(wǎng)友獎(jiǎng)勵(lì)分布式系統(tǒng)：概念與設(shè)計(jì)（英文版·第5版）圖書一本，對(duì)其他積極參與討論的網(wǎng)友（回帖有參考價(jià)值）我們將獎(jiǎng)勵(lì)積分20分。

圖書簡(jiǎn)介：

原書名： Distributed Systems：Concepts and Design，F(xiàn)ifth Edition
原出版社： Addison-Wesley; 5 edition
作者： (英)Jean Dollimore    George Coulouris    Tim Kindberg    Gordon Blair   
叢書名： 經(jīng)典原版書庫(kù)
出版社：機(jī)械工業(yè)出版社
ISBN：9787111397724
上架時(shí)間：2012-10-29
    出版日期：2012 年10月

linux_c_py_php

分布式架構(gòu)有點(diǎn)太大了, 我們還是主要關(guān)注基礎(chǔ)服務(wù)集群方面的開發(fā)技術(shù)吧...

1, 服務(wù)端微架構(gòu)上我們是完全可以實(shí)現(xiàn): 單線程 + 異步 +等待但不阻塞  的事件框架的, 從nginx/lighttpd的異步事件框架如何與fcgi module協(xié)調(diào)工作就可以掌握其原理, 所以我們是有能力開發(fā)一個(gè)邏輯中轉(zhuǎn)服務(wù)端, 作為一個(gè)反向代理進(jìn)行工作, 保證請(qǐng)求的接入->轉(zhuǎn)發(fā)到具體業(yè)務(wù)服務(wù)端->從業(yè)務(wù)服務(wù)端接受應(yīng)答->將應(yīng)答轉(zhuǎn)發(fā)回客戶端.

2, 在1)的基礎(chǔ)上, 并不是所有業(yè)務(wù)都可以實(shí)現(xiàn)立即響應(yīng), 可能有的事情要處理1小時(shí), 我們不能借助1中的實(shí)現(xiàn)手段解決此類問題, 因?yàn)榭蛻舳瞬⒉灰欢ㄏ矚g阻塞1小時(shí)等待你的應(yīng)答, 雖然我們的服務(wù)端有能力異步的接入足夠多的并發(fā)請(qǐng)求.

這時(shí)候, 如果我們能夠給客戶端提供推送通知或者提供詢問接口是一種常用設(shè)計(jì), 還是要提到買火車票的問題, 鐵道部都會(huì)用買票排隊(duì)這種手段降低DB的負(fù)載, 何況我們...

我們需要借助高效的中間件來完成一些事情, 在這方面我們主要是架構(gòu)師, 不是碼農(nóng)...(說出來都嫌丟臉..)

比如我們都知道用消息隊(duì)列, java用activemq... c(python/php)用zeromq, rabbitmq, memcacheq...

消息隊(duì)列是干嘛的? 容量無限(可持久化到磁盤), 沒有關(guān)系型數(shù)據(jù)庫(kù)的復(fù)雜所以讀寫效率高(一個(gè)queue一個(gè)queue, 能有多復(fù)雜呢), 支持訂閱與發(fā)布模型很容易擴(kuò)展, 等等.

借助消息隊(duì)列, 我們可以簡(jiǎn)化編程, 開發(fā)生產(chǎn)者, 開發(fā)消費(fèi)者, 消費(fèi)者完成業(yè)務(wù)邏輯并通知客戶端(客戶端開個(gè)端口監(jiān)聽不就得了?)/存DB, 所以還是挺好玩的.

3, 還有種模型, 就是XMPP這種天生聰穎的協(xié)議+jabberd2這種天生聰穎的架構(gòu)了. 如果客戶端始終維持一個(gè)到服務(wù)端的長(zhǎng)連接來發(fā)送命令和讀取應(yīng)答, 那么前兩種方案弱爆了, 我們不如把業(yè)務(wù)遷移到XMPP集群中去, 我們只要開發(fā)服務(wù)型的客戶端連接到XMPP集群, 就可以為客戶端型的客戶端提供發(fā)布與訂閱(新聞推送?), 或者普通的一問一答了, 因?yàn)榭蛻舳耸情L(zhǎng)連接的特點(diǎn), 誰也沒強(qiáng)迫誰要在多少時(shí)間內(nèi)應(yīng)答, 就算不答又怎樣? 在XMPP里, 請(qǐng)求和應(yīng)答從來都不是"一問一答"的, 所以這真的是種特殊的工作模式, 并且很常見, 比如IM.

chenyx

太底層了,沒接觸過,友情支持下

action08

回復(fù) 2# linux_c_py_php


    你們很多技術(shù)都太專業(yè)了，能分享一下一些基礎(chǔ)平臺(tái)的信息么？

前端用的什么服務(wù)器，apache/nginx或者自己定制的，大約部署了多少臺(tái)這樣的機(jī)器？
還有主要的開發(fā)語言，開發(fā)出來的事件處理系統(tǒng)負(fù)責(zé)了什么業(yè)務(wù)邏輯，（我很菜，對(duì)大型系統(tǒng)架構(gòu)不熟悉），為什么傳統(tǒng)的架構(gòu)模型就不能勝任了呢（遇到了什么瓶頸）？
后端用到nosql沒有，目前平臺(tái)大約部署了多少臺(tái)數(shù)據(jù)庫(kù)機(jī)器？？

就包括機(jī)器配置，面臨的業(yè)務(wù)數(shù)據(jù)量，也可以分享一下的。這也重要，至少讓別人了解一下環(huán)境，然后再了解具體采取了的措施。

action08

回復(fù) 3# chenyx


    這個(gè)人很牛的，{:3_188:}

hellioncu

分布式一個(gè)很大的問題是信息同步，要盡量減少同步的數(shù)據(jù)量，還要保證同步的及時(shí)性。
一種辦法是讓客戶端盡量在一個(gè)服務(wù)器上被服務(wù)，減少服務(wù)器間的切換，這可能需要在客戶端方面做一定的配合。

業(yè)務(wù)性質(zhì)不同，對(duì)架構(gòu)影響很大。如有的業(yè)務(wù)客戶端發(fā)送請(qǐng)求一段時(shí)間之后沒收到結(jié)果可以重復(fù)發(fā)起請(qǐng)求，但有的不行，必須先查詢之前的結(jié)果，再?zèng)Q定是否重發(fā)。有的對(duì)可靠性要求高，如服務(wù)器收到應(yīng)答，已反饋客戶端已經(jīng)收到請(qǐng)求之后，即使服務(wù)器宕機(jī)，也得想辦法恢復(fù)該請(qǐng)求，這要求服務(wù)器有可靠的持久化、備份措施。

同樣是分布式異步事件處理系統(tǒng)，架構(gòu)可能是千差萬別

happy_fish100

apache traffic server前身是雅虎收購(gòu)的inktom公司的traffic server，人家大約10年前就實(shí)現(xiàn)了異步事件處理，即事件驅(qū)動(dòng)框架。
apache traffic server支持cluster模式，對(duì)URL采用一致性hash來分布。

dyyseo

很牛逼。。。。。。。。。。。。

crazyhadoop

拋磚引玉~分布式異步事件處理系統(tǒng)應(yīng)該可以專注的處理多方的事件且不影響別人，微侵入，高性能。
那么事件是什么樣子的呢？
1. 類似消息通知的，有些要求及時(shí)傳遞，比如qq上線通知，有些可以忽略，比如好友寫了新日志
2. 不可重入的事件，充值加積分，這樣的事件發(fā)生了，相應(yīng)的積分加且只能加一次，要求精準(zhǔn)處理
3. 多方關(guān)注的事件，例如充值50Q幣，可能很多業(yè)務(wù)邏輯都要發(fā)生動(dòng)作，會(huì)員會(huì)xx，VIP系統(tǒng)會(huì)xxx，禮物系統(tǒng)會(huì)XXX
4. 可重入的事件，比如在線時(shí)長(zhǎng)加積分
5. 耗費(fèi)時(shí)間的事件，如發(fā)送1億份郵件，或者抓取10億張圖，只關(guān)注結(jié)果，不關(guān)注過程，事件丟一點(diǎn)也沒有關(guān)系

這樣看來，用一個(gè)隊(duì)列存儲(chǔ)這些任務(wù)比較合適，根據(jù)事件的類型和數(shù)量，可能堆實(shí)現(xiàn)的優(yōu)先級(jí)隊(duì)列效率會(huì)更高一點(diǎn)。查詢某個(gè)任務(wù)
效率會(huì)極大的提高。
提到持久化，可以用binlog日志去記錄這些事件，一旦當(dāng)隊(duì)列暫時(shí)崩潰，重新啟動(dòng)就可以恢復(fù)工作。這也是數(shù)據(jù)庫(kù)事務(wù)系統(tǒng)常用
的一致性解決方法。

隊(duì)列可以只是做簡(jiǎn)單的工作，存儲(chǔ)數(shù)據(jù)就好了，亦可以實(shí)現(xiàn)一些調(diào)度的功能，例如gearman這樣的集隊(duì)列和調(diào)度為一身。
或者用redis的數(shù)據(jù)結(jié)構(gòu)搞起，外包一個(gè)事件處理調(diào)度框架，這樣可以自由的做很多事情。

既然是分布式，那就還能處理多方請(qǐng)求，那如何收集呢？為了降低復(fù)雜度，提高可靠性，用日志收集處理的方法是
一個(gè)可行的選擇。所有的發(fā)生的事件記錄統(tǒng)一的格式，然后多機(jī)可以路由到同一臺(tái)機(jī)器，然后再用一個(gè)分析程序
去分析這些事件，灌入隊(duì)列。

事件任務(wù)被分配以后，又如何知曉事件是否做好呢？ 可以考慮讓處理的程序發(fā)個(gè)反饋。不過讓業(yè)務(wù)反饋這實(shí)在是不友好，
那最好是能獲取到處理程序執(zhí)行任務(wù)的狀態(tài)，事件處理系統(tǒng)自己反饋這個(gè)信息，然后根據(jù)自己的判斷，這個(gè)任務(wù)下一步該
如何處理，是刪除掉，還是繼續(xù)推送。

其實(shí)方法很多。關(guān)鍵的一點(diǎn)是可靠性高，能做到萬無一失最好了，就算是除了一些紕漏，能快速找到這些事件，再執(zhí)行也
是可以的。

smalloc

分布式系統(tǒng)好象應(yīng)該建立在分布式計(jì)算上的吧