趙海平大神談異步處理對(duì)分布式系統(tǒng)的優(yōu)化

單機(jī)時(shí)代的數(shù)據(jù)請(qǐng)求

十五年前寫軟件是很簡單的，一個(gè)Client對(duì)應(yīng)一個(gè)DB Server，或者多個(gè)Client對(duì)應(yīng)一個(gè)DB Server，每一個(gè)Client執(zhí)行各自的服務(wù)。當(dāng)時(shí)的討論很多是說，這個(gè)東西要寫在Client端還是寫在DB Server端，流行的思路有兩種：

1.把DB Server寫得很復(fù)雜，比如Oracle數(shù)據(jù)庫，而Client端則寫得很簡單，只有調(diào)用返回
2.DB很簡單，只有簡單的表，而Client寫得復(fù)雜。很多創(chuàng)業(yè)公司會(huì)這樣做，因?yàn)樗麄儗?duì)SQL不是很熟悉，但是很熟悉PHP。早期Facebook就是典型的代表

大數(shù)據(jù)時(shí)代的數(shù)據(jù)請(qǐng)求

單機(jī)時(shí)代隨著兩個(gè)趨勢而逐漸成為歷史。一個(gè)趨勢是隨著互聯(lián)網(wǎng)的流行，越來越多的人開始上網(wǎng)使用Web服務(wù)，而且很多時(shí)候用戶增長速度是非?？斓模Y(jié)果造成一臺(tái)DB Server無法儲(chǔ)存下所有用戶的數(shù)據(jù)。第二個(gè)趨勢是計(jì)算機(jī)能力越來越強(qiáng)，網(wǎng)絡(luò)服務(wù)針對(duì)每一個(gè)用戶要做的事情也變多了，比如Facebook不僅要保存一個(gè)用戶的個(gè)人信息，還有他的關(guān)系鏈信息，他的使用習(xí)慣、點(diǎn)擊習(xí)慣等，就造成一個(gè)用戶的數(shù)據(jù)量也大大增加，僅僅訪問一個(gè)DB Server就準(zhǔn)備好一個(gè)頁面變成了不可能的事情。

這就帶來了一個(gè)問題：針對(duì)多個(gè)DB Server的程序應(yīng)該怎么寫？

針對(duì)這個(gè)問題也有兩個(gè)思路：

1.串行同步。先query DB1，返回res1，再使用res1做另一個(gè)DB的query，返回res2。這是在第二個(gè)Query依賴第一個(gè)Query結(jié)果的情況
2.并行同步。針對(duì)DB1的query跟針對(duì)DB2的query同步進(jìn)行。這是兩個(gè)Query之間沒有依賴關(guān)系的情況。Facebook早期專門寫了一個(gè)并行處理的函數(shù)，用法是 ExecParallelQuery(conn1,Query1,conn2,Query2)
這個(gè)時(shí)候的代碼就比以前的代碼更加復(fù)雜了，不過還是能實(shí)現(xiàn)需要實(shí)現(xiàn)的需求。但這時(shí)候帶來了一個(gè)新的問題，就是等待。一個(gè)頁面的加載可能需要調(diào)用不同的函數(shù)，而不同的函數(shù)可能是由不同的團(tuán)隊(duì)寫的。比如獲取朋友關(guān)系的函數(shù)getFriends把自己需要的數(shù)據(jù)用同步的方式獲取了，但如果一個(gè)第三方開發(fā)者過來，則不僅要調(diào)用這個(gè)函數(shù)，還需要調(diào)用其他函數(shù)，這樣其他函數(shù)的執(zhí)行就需要等待前面這個(gè)getFriends函數(shù)返回了結(jié)果之后才能開始執(zhí)行，就很慢了。

要如何做到并行處理在代碼層面很直觀，在機(jī)器上的執(zhí)行效率又好呢？

異步的處理思路就是這么來的。

所謂異步就是，我這個(gè)函數(shù)知道這里需要訪問哪幾個(gè)DB Server，但我先不著急去訪問，而是先記錄一下，等等看其他函數(shù)是不是也要訪問這個(gè)DB，如果有的話，待會(huì)兒再一起去訪問。異步處理的指令比如說是 conn.asyncExec(Query) ，這個(gè)可以立刻返回一個(gè)Future對(duì)象，意思就是“待會(huì)兒再去執(zhí)行”。如果每個(gè)函數(shù)都返回這種Future對(duì)象，那么就可以根據(jù)這些Future對(duì)象來判斷哪些請(qǐng)求沒有依賴可以并行處理，哪些請(qǐng)求有依賴需要串行處理了。如此，不同的團(tuán)隊(duì)寫出來的函數(shù)就不用一個(gè)等一個(gè)，而是可以在更高層面上互相合作。

然而這又帶來了一個(gè)問題，那就是異步處理的寫法是具有傳染性的。如果一個(gè)服務(wù)中有的函數(shù)寫的異步，有的函數(shù)沒寫異步，就會(huì)造成有的函數(shù)返回了Future Object，有的函數(shù)返回了數(shù)值，導(dǎo)致無法執(zhí)行。要實(shí)現(xiàn)異步，需要關(guān)聯(lián)的所有函數(shù)都用異步的寫法返回Future Object才可以。

所以Facebook在轉(zhuǎn)向異步處理的過程是非常痛苦的，一開始做了局部修改，再修改調(diào)用了局部修改過的函數(shù)的函數(shù)，所有調(diào)用的調(diào)用都要修改，最后全部改成了異步，只要有調(diào)用遠(yuǎn)程服務(wù)IO的操作都要改。每一個(gè)DB Query都拆分成兩步，一個(gè)set request，一個(gè)receive response。這里的工作量很大，所以如果創(chuàng)業(yè)團(tuán)隊(duì)的話，最好是第一天就用正確的寫法，就不會(huì)這么痛苦。

所有函數(shù)改寫后，每一個(gè)函數(shù)執(zhí)行都會(huì)返回Future Object。那么異步處理的第一步，就是將這些Future Object形成一棵依賴樹的結(jié)構(gòu)，好像這樣：

這里每個(gè)節(jié)點(diǎn)都是一個(gè)Future對(duì)象，每一個(gè)Future對(duì)象有兩種狀態(tài)，一個(gè)是等待執(zhí)行，一個(gè)是完成執(zhí)行。同級(jí)的節(jié)點(diǎn)是沒有依賴關(guān)系的，可以并行執(zhí)行；上下節(jié)點(diǎn)是有依賴關(guān)系的，需要串行執(zhí)行，先執(zhí)行下層再執(zhí)行上層。

樹結(jié)構(gòu)形成后，從下到上執(zhí)行，直到最上面的top parent節(jié)點(diǎn)被執(zhí)行進(jìn)入完成執(zhí)行的狀態(tài)，就是完成，比如一個(gè)頁面加載完畢。

所以異步處理之后有一個(gè)很有意思的情況，那就是PHP這個(gè)語言已經(jīng)跟以前不同了，不再是一上來就是執(zhí)行，而是一上來先lazy一下，看清楚所有的Query之后再執(zhí)行。

異步處理還需要解決的問題

到目前為止，這樣做異步處理似乎已經(jīng)是足夠好的優(yōu)化，但實(shí)際上還有問題。看看下面這個(gè)例子。

比如我們現(xiàn)在有兩個(gè)查詢需求。一個(gè)是查詢你在淘寶上買過東西的朋友，另一個(gè)是查詢你在淘寶上買過保時(shí)捷的朋友。常理來說，我們會(huì)先想到查詢你在淘寶上的朋友，再進(jìn)行另一個(gè)條件的查詢，比如這樣：

但是對(duì)于保時(shí)捷這個(gè)查詢而言，這是不對(duì)的，因?yàn)樘詫毶腺I保時(shí)捷的人是很少的，可能就一兩個(gè)，而淘寶上的好友數(shù)可能有上百。因此保時(shí)捷的查詢應(yīng)該是這個(gè)次序比較優(yōu)化：

這個(gè)次序應(yīng)該如何決定？實(shí)際上不應(yīng)該在寫程序的時(shí)候決定，因?yàn)閷懗绦虻臅r(shí)候是無法避免有先后順序的——編輯器只能一行一行的寫代碼，但是機(jī)器執(zhí)行卻無需管這個(gè)。所以更好的方法應(yīng)該是在執(zhí)行代碼之前再加入一個(gè)phase。

其實(shí)傳統(tǒng)數(shù)據(jù)庫的cardinality（基數(shù)）功能已經(jīng)解決了這個(gè)問題。你在DB query里面使用 INNER JOIN 這個(gè)指令，其實(shí)DB已經(jīng)能夠預(yù)判哪一個(gè)表給出的row會(huì)比較少，從而以更優(yōu)化的次序去執(zhí)行。但現(xiàn)在我們用的編程語言，無論是PHP，Java，Python還是C/C++，并沒有考慮這個(gè)問題。有人會(huì)開很多線程來解決這個(gè)問題，但這不是最佳方案，因?yàn)樵贚inux系統(tǒng)里，你的線程數(shù)要是上了200-300，就會(huì)有很大的overhead。

代碼執(zhí)行的次序，這是一個(gè)。另外最近幾年還有一個(gè)流行的優(yōu)化思路，就是上memcache。我們有時(shí)候會(huì)看到程序員把他自己的函數(shù)放進(jìn)了memcache，相當(dāng)于是依賴樹的中間的一個(gè)節(jié)點(diǎn)，我就問他為什么要把他這個(gè)Class放入memcache，他可能會(huì)說，他覺得這個(gè)節(jié)點(diǎn)和這個(gè)節(jié)點(diǎn)的child被調(diào)用的次數(shù)多。我覺得這可能不是特別理想的。你今天覺得這個(gè)Class被調(diào)用的多，可以放進(jìn)memcache，但明天是不是會(huì)有更重要的Class會(huì)更值得放進(jìn)memcache，于是你又要把memcache的資源讓給這個(gè)新的Class？如果你放入memcache的Class并不是最重要的，這就相當(dāng)于真正優(yōu)化的可能性被拿走了。

如何讓異步執(zhí)行的更好？

哪個(gè)query先執(zhí)行，哪個(gè)query后執(zhí)行，不應(yīng)該是在編碼階段來做的。哪個(gè)Class該進(jìn)memcache，哪個(gè)Class該出memcache，也不應(yīng)該在編碼階段來做。應(yīng)該有一個(gè)中間的階段，專門進(jìn)行這種調(diào)度工作，然而到目前為止，還沒有公司能夠做到，因?yàn)闆]有合適的語言。

異步處理在分布式系統(tǒng)中怎樣做有更好的優(yōu)化作用，我們需要更多的思考。希望大家能夠把計(jì)算機(jī)當(dāng)作科學(xué)去思考，而不僅僅是工程應(yīng)用。我們現(xiàn)在看十幾年前，對(duì)單機(jī)是非常了解了，那么未來過了五年十年再回來看，可能對(duì)分布式系統(tǒng)也會(huì)了解的比現(xiàn)在更多很多，可能給分布式系統(tǒng)寫程序也會(huì)變得跟給單機(jī)寫程序一樣簡單。當(dāng)然這就需要更合適的工具語言去給大家提供這種異步的便利。是不是會(huì)有Haskell那樣lazy的方式從系統(tǒng)層面解決這個(gè)問題？希望跟大家一起思考探討。