併發已不再是語言層面上的事情了
原文連結 譯者：張軍 校對：方騰飛
本文將併發和記憶體管理做了個類比。最近有一個說法是因為現代工程師幾乎總是面對計算機叢集程式設計，所以我們需要用於構建分散式系統的工具。這就意味著我們需要在語言層面支援分散式系統開發。像GO和Erlang這樣的語言其優勢正好符合這個觀點。
GO和Erlang可能最終會流行，但我不認為是這個原因。分散式系統開發並不會成為每個應用開發者日常工作的一部分，因為那將會是件非常痛苦的事情。在某種程度上，我想今天發生的事情是因為缺乏良好的分散式計算框架，而迫使應用去重新實現一些分散式系統原語。但這種情況不會一直存在，而必將有一些框架提供不同的程式設計模型，在彈性機器池上處理分佈和併發問題。
MapReduce已經解決了這個問題。MapReduce程式設計幾乎都是單執行緒的，併發是由框架來管理，另外有助於你寫好MapReduce程式的原因是，有很多使用者級別(user-level)的併發原語，並且MapReduce是高度並行的。
這不是個新事物，即使是Java servlets，其所有的缺陷主要是因為抽象了執行緒模型，但是至少對於應用程式來說只需要通過阻塞I/O與一個數據庫進行互動。
我覺得有三大基本領域需要處理：線上，近實時和離線。
- 線上領域，我們建立請求/響應式服務，並行性是通過將每個請求的處理當作一個工作單元，劃分到不同的執行緒和機器。我見過該模型的多個變種，從“服務查詢語言”到將REST呼叫拼接在一起的DSLs，它們的共同點就是抽象併發的處理，而不需要像執行緒一樣直接訪問單個伺服器的併發機制。
- 在近實時處理領域，流處理框架做的很好，通過非同步處理而根本不用考慮併發。而且你關心的併發和並行只在框架層面，你寫的程式碼看起來完全是單執行緒的。
- 離線領域似乎為了不同的目標朝著YARN框架 （校對注：YARN框架介紹）的方向發展。
幾乎所有這些框架的共同點是它們都不需要使用者直接管理併發。
我認為這些高層次的領域（線上，非同步和離線）將被證明會長期存在，但是我不認為我們需要十幾個基礎分散式計算框架來涵蓋這些領域。
這讓我花了很多時間來思考，在語言層面支援單機併發（軟體事務記憶體和其他）效果是有限的。它只會幫助框架的實現者而不是終端使用者。相比應用開發者，框架實現者會有一些非常不同的需求，他們更關心效能和細粒度的控制。儘管這顯然是一個有爭議的說法，我不確定執行緒和鎖對框架開發者來說是否是一個可行的模型，畢竟，對於一個受訓過的團隊它們做的非常好，並有出色的效能和控制能力。
