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