單機(jī)時代的數(shù)據(jù)請求

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

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

大數(shù)據(jù)時代的數(shù)據(jù)請求

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

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

針對這個問題也有兩個思路：

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

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

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

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

然而這又帶來了一個問題，那就是異步處理的寫法是具有傳染性的。如果一個服務(wù)中有的函數(shù)寫的異步，有的函數(shù)沒寫異步，就會造成有的函數(shù)返回了Future Object，有的函數(shù)返回了數(shù)值，導(dǎo)致無法執(zhí)行。要實現(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的操作都要改。每一個DB Query都拆分成兩步，一個set request，一個receive response。這里的工作量很大，所以如果創(chuàng)業(yè)團(tuán)隊的話，最好是第一天就用正確的寫法，就不會這么痛苦。

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

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

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

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

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

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

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

但是對于保時捷這個查詢而言，這是不對的，因為淘寶上買保時捷的人是很少的，可能就一兩個，而淘寶上的好友數(shù)可能有上百。因此保時捷的查詢應(yīng)該是這個次序比較優(yōu)化：

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

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

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

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

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

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