現在我們都說設計可並行、高併發的程序，而且我們很多時候會在潛意識裡覺得自己對並行（Parallelism）和併發（Concurrency）的區別很清楚，但如果要明確的說出二者的區別，又感覺沒辦法給出一個非常清晰的描述。
那麼什麼是併發？什麼又是並行呢？並行的概念比較簡單，並行總是和執行（executions）相關，很多東西同時執行就是並行；而併發則是通過一些方式組織你的程序，讓它可以分成多個模塊去獨立的執行。並行必然是需要多核的，一個處理器是無法並行的；但併發和處理器並沒有什麼必然聯繫，在一個處理器上面，我們的程序也可以是併發的。
舉個簡單的例子，華羅庚泡茶，必須有燒水、洗杯子、拿茶葉等步驟。現在我們想盡快做完這件事，也就是“一共要處理很多事情”，有很多方法可以實現併發，例如請多個人同時做，這就是並行。並行是實現併發的一種方式，但不是唯一的方式。我們一個人也可以實現併發，例如先燒水、然後不用等水燒開就去洗杯子，所以通過調整程序運行方式也可以實現併發。
如果你覺得以上的講解還是太抽象了，下面通過一個小故事來講解，故事原型來自 Go 語言創始人之一 Rob Pike 的一篇演講。
故事的開始有一個需求：有一群地鼠要把一堆廢棄的說明書用小推車推到火爐去燒燬。
剛開始只有一隻地鼠，使用一輛推車，將書裝到車上，運輸到火爐旁，將書卸到火爐。完成任務必然需要比較長的時間。
此時如果再增加一隻地鼠，那也沒什麼用，因為一隻地鼠在幹活，另一隻地鼠只能等待。（當然有人說兩隻地鼠輪流使用一輛推車，這樣可以讓地鼠得到休息，這樣它們幹活更快，也可以提高效率。）
再找一輛推車來，兩隻地鼠分別使用各自的推車，將書裝到車上，運輸到火爐旁，將書卸到火爐。這樣會提高運輸效率，但它們會在裝書和卸書時進行排隊，降低了效率。
這樣雖然比之前快了，但還是有瓶頸的。因為書只有一堆，火爐也只有一個，所以我們還必須通過消息來協調兩隻地鼠的行動。好吧，那我們再把書分成兩堆，再增加一個火爐。
這樣就比之前的效率高差不多一倍了。現在這個模型就是併發的，因為兩隻地鼠可以獨立完成一件事了，這樣提高了運輸效率，而且在裝書和卸書時不會進行排隊，提高了裝卸的效率。但這個模型不一定是並行的，比如同一時刻可能只有一隻地鼠在幹活。
上面就是第一種併發模型，我們還可以設計更多的併發模型，繼續看漫畫。
這次找了 3 只地鼠，一隻負責把書裝到車上，一隻負責運輸，一隻負責把書卸到火爐焚燒。每隻地鼠做一個獨立的任務，當然三隻地鼠之間需要使用一些諸如消息通信之類的手段進行協調。
裝書和燒書的兩隻地鼠都很輕鬆，負責運輸的這隻地鼠卻很累，系統出現了瓶頸。那我們再找一隻地鼠來，專門負責運回空推車。
我們在一個已有的設計（指三個地鼠的那個設計）中添加一個併發的步驟（第四隻地鼠）增強了系統的性能。這樣一來，兩隻地鼠去搞運輸，如果協調的好，理論情況下工作效率將是一隻地鼠的 4 倍。
總共有 4 個併發的步驟：
- 把書裝到車上；
- 把推車運到火爐旁；
- 把書卸到火爐裡；
- 運回空推車。
可以再增加一個分組，將這個併發模型並行化。
下面我們再來看另外一種併發模型。負責運輸的地鼠抱怨說運輸路程太長，那我們就增加一箇中轉站。
然後再增加一個分組，將這個併發模型並行化，兩個分組並行執行。
可以把上面的併發模型再改進一下。增加中轉站的同時，再增加兩隻地鼠，一隻負責將從書堆運過來的書卸到中轉站，另一隻負責將書從中轉站裝到推車裡，再讓後面的地鼠運輸到火爐旁。
然後再增加一個分組，將這個併發模型並行化。
漫畫到這裡就結束了，總共介紹了三種併發模型，每種模型都可以很容易地並行化。可以看到上面的併發模型每改進一次，其實就是將任務拆的更細了，一旦分解了問題，併發就自然而然產生了，每個人只專注於一個任務。
回到程序中，書就代表著數據，地鼠就是 CPU，而車可能就是序列化、反序列化、網絡等設施，火爐就是代理、瀏覽器或其他的消費者。而上面的併發模型就是一個可擴展的 Web Service。
該演講題目為《Concurrency is not Parallelism》，原文鏈接：
- 演講幻燈片：https://talks.golang.org/2012/waza.slide
- 演講視頻：https://www.youtube.com/watch?v=cN_DpYBzKso&t=550s
參考鏈接
- https://my.oschina.net/3233123/blog/1047239
- https://blog.csdn.net/claram/article/details/52094587
閱讀更多 米開朗基楊 的文章
