原文地址：http://www.infoq.com/cn/presentations/optimization-of-asynchronous-processing-in-distributed-systems

視頻地址：http://v.qq.com/boke/page/l/0/6/l0196plsvp6.html

主講人：趙海平 Facebook hiphop HHVM 阿里巴巴技術保障部

問題1.進入大數據時代，

用戶增多，數據增多帶來挑戰，上億的用戶，不能一臺機器存所以數據，一個計算機更強大，針對一個用戶要做的事情也比以前更多，造成數據量的膨脹。

多到再不可能訪問一個數據庫就可以展示網頁，需要訪問多個庫。

不好的做法，訪問數據庫1的結果是訪問2需要的依賴，只能先訪問1再拿1的結果去訪問2，最后匯總結果顯示出來。

問題：同步等待。

發現有時候1和2其實沒有依賴性，這樣就無意義的等待。

并行的發送2個數據庫去查詢比較好，facebook早年就是有這樣的代碼，幾個mysql同時查詢，專門的查詢函數查詢多個查詢，只要這些查詢之間沒有依賴。

這樣讓代碼復雜性，不過不要緊。問題在于人腦思維有局限性，在真實場景有小組，每個小組負責自己的業務，負責查詢自己所在的數據庫，所有每個組在函數上是一個同步的寫法，同步的等待過程，從數據庫抓數據，只要調用其函數就需要同步等待，讓并行處理變難。

第三方需要調用多個函數都各自做各自的事情，都同步的抓數據，只能先后調用。讓并行處理很復雜。facebook就遇到這樣的現實問題。

如何把并行在代碼層面寫的很直觀，又在機器層面執行的非常好就是一個藝術。

新的寫法-異步寫法

我知道需要訪問數據庫，先不馬上訪問，把訪問數據庫的所有條件記錄先下來，記錄下來的目的是稍微等待看有沒有其他地方也需要訪問這個或者其他數據庫，如果有可以兩個一起處理。所有異步寫法就不是一個同步的等待。

異步返回的是Future這樣一個object而不是結果result。Future可能不同語言叫法不一樣，但是目的都是一樣就是將所有將來需要訪問數據庫的信息記錄下來，先不去訪問它，有不同的Future的object就可以匯總在一起，再執行。

要判斷什么樣的Future的object可以并行處理，什么樣的不能并行處理。可以做調整。

異步寫法不再擔心函數把異步寫法合并，有函數也沒事，getresult到最后把Future的object返回給調用者，這個函數可以暫時認為已經結束執行，下一次就無需訪問我了，因為我已經告訴你怎么去訪問數據庫，然后調用者可以去調用其他函數，再調用函數的過程中沒有任何的等待過程。調用的人有一個總的調度過程。不同的團隊可以寫自己的函數，這些函數可以合作。

要求同一個公司都這樣寫，不然其他調用者對于一個是Future，而另一個是同步進行，調用者就會不知所措，因為返回不同。調用者希望所有的函數給他的都是Future的object。

但是這樣阻礙很多的代碼轉變，fb就經歷過這樣痛苦的轉變，不過異步確實讓代碼更有效的執行，就開始漸漸在代碼中加入異步的調用函數，發現所有調用都要改為Future。

代碼第一天開始就用正確的寫法以后就不會有這樣的問題，facebook局部的把代碼變為異步的方法。一旦異步遇到同步就馬上去執行異步的數據，把結果再和同步匯總，最后facebook還是把整個網站改為異步寫法。每一個函數只要有一個調用遠程服務的網絡IO的過程就要將其改為異步的。到一個數據庫查詢先發一個seng請求然后yield，還有另一個操作就是接受Response，把一個同步的等待分為一半一半，一個seng請求和接受Response。

最后發現一個網頁形成一棵樹，右邊最下面2個葉子可以沒有任何依賴性都可以到遠端調用數據，調用數據都回來了后執行其共同的父節點。然后左邊2個葉子沒有任何依賴性的執行，每一個節點都是一個Future的object，每個節點2個狀態：一個是正在等待執行，還有一個是已經執行了。只有所有的葉子節點執行后才可以開始自己的執行，逐級往上依賴的執行。

一個網頁不是馬上從后端服務器調用數據，而是組成一個distributed（分布式的）查詢，每一個分布式查詢可以組成一個依賴性樹。

第一個face階段：總調用者拿到一顆很大的樹，這顆樹描述數據調用的依賴性。樹的每一個node都記錄下來怎么調用數據。

第二個face：執行整個樹，執行的過程就是所有的底層的葉子可以并行執行，再上面一層，要看執行的速度，有時候某些點快就可以上去的更早，有的點上的稍微晚點執行。無論怎么樣，最后的目的是一直往上，頂點也被執行完，這個頂點就是網頁的html就被完全準備好了。

發現把PHP變為這樣一種語言，不像原來那樣一上來就執行，而是一上來先Lazy一下，組成一個query，然后等看清楚完整的query之后再開始執行第二個face。

實例：找出所有朋友中在淘寶買過東西的人。

不能馬上得到friends列表會得到一個Future的object，這個Future的object將來會告訴我有哪些朋友。

再yield return getTaoBaoBuyers(friends);需要執行第二個數據調用，是對friends有依賴性的，要知道有哪些friends，然后查這個friend有沒有在淘寶購物。

如果是另一個不恰當的例子，在淘寶買保時捷的人可能不會很多就2個人。

第一個例子在淘寶上買過東西的人實際上是狠多的。

在淘寶上買保時捷少的情況下這個查詢就出現這樣一種問題，是找朋友還是倒過來先查那2個人在淘寶上買過保時捷，再看看這2個人那個是我的朋友？

同一個問題2個方向去解決：可以先查我的朋友，也可以先查這2個人。這2個方向是怎么決定的？

如果第二個問題沿用第一行代碼就錯了。

應該先查買過保時捷的人！因為第二件事情做得人比較少。

這種情況在傳統數據庫早就存在，因為存在表連接。在數據庫優化上在join的時候會自動做這種優化，看那個表返回的少。innno join從小表這邊走。表join方向的問題，傳統數據庫這樣的問題已經被優化，但是寫程序就沒有做到這一點。

但是fb把網頁改為異步，但是fb還沒有能夠在2個face之間去分析優化查詢。

這個問題不僅僅是php中有。任何語言都會遇到要訪問多個庫的情形，是并行串行？同步異步？的問題。

用同步處理CPU的利用率上不去，用線程去處理并行方案不是最佳方案。線程設的最高300以上以及到了環境的極限。

這個時候需要用很多小小的協程等一些方案做一些小的task.

寫代碼必須一行行寫，但是其實機器可以并行執行代碼，這是人腦思維和機器執行的差異。

其實這些并行的優化就是以前數據庫做的內部優化的放大。

寫第一行代碼就已經把表join的方向給靜態固化，把哪一個class放memcached里給固化下來。這些都不是一個真正的優化過程。

要的是不要告訴我們表join從哪個方向，也不要告訴我把哪一個class放memcached里給固化，因為寫這個的研發人員不知道從系統資源的角度上來說哪個class更值得放入緩存。或者以后業務有整體大的變化，有哪些新的class應該放入緩存，老的class應該從緩存搬走。

所有的這些優化應該是中間的face介于這兩者之間組成查詢，然后看這個查詢在哪兒可以執行，最后經過這樣一個優化過程當中再去執行，所有的這些是中間的調度過程中去執行優化過程。

Java和php都沒有給我們這樣的便利。在fb加了yield return這樣的語法實際上非常類似于python的yield return，雖然有yield，但是只是把程序變成2個face。

我們沒有辦法把這個查詢優化為一個更值得優化的一棵樹再去執行。

.

只要是分布式系統就要思考怎么用異步來優化。

希望大家把計算機當成科學來看待，以后語言層面已經把異步優化給處理好。

總結

以上是生活随笔為你收集整理的《异步处理在分布式系统中的优化作用》学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。