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

send_linux

獲獎名單已公布，詳情請看：http://72891.cn/thread-4060812-1-1.html  

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

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

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

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

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

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


活動時間：
2012.11.16-2012.12.06

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

圖書簡介：

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

linux_c_py_php

分布式架構有點太大了, 我們還是主要關注基礎服務集群方面的開發(fā)技術吧...

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

2, 在1)的基礎上, 并不是所有業(yè)務都可以實現(xiàn)立即響應, 可能有的事情要處理1小時, 我們不能借助1中的實現(xiàn)手段解決此類問題, 因為客戶端并不一定喜歡阻塞1小時等待你的應答, 雖然我們的服務端有能力異步的接入足夠多的并發(fā)請求.

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

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

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

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

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

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

chenyx

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

action08

回復 2# linux_c_py_php


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

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

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

action08

回復 3# chenyx


    這個人很牛的，{:3_188:}

hellioncu

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

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

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

happy_fish100

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

dyyseo

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

crazyhadoop

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

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

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

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

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

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

smalloc

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