分散式計算是這些年的熱門話題，各種大資料框架層出不窮，容器技術也奮起直追，各類資料庫（Redis、ELasticsearch、MongoDB）也大搞分散式，可以說是好不熱鬧。分散式計算在大熱的同時，也存在著兩臺機器也要硬上 Hadoop 的“面向簡歷程式設計”，接下來我就剖析一下分散式計算的本質，以及我的理解和體會。本文由機器之心經授權轉載自歲寒，未經授權禁止二次轉載。
分散式計算的本質
分散式計算來源於人們日益增長的效能需求與落後的 x86 基礎架構之間的矛盾。恰似設計模式是物件導向對現實問題的一種妥協。
x86 伺服器
x86 伺服器，俗稱 PC 伺服器、微機伺服器，近二十年以迅雷不及掩耳盜鈴之勢全面搶佔了絕大部分的伺服器市場，它和小型機比只有一個優勢，其他的全是缺點，效能、可靠性、可擴充套件性、佔地面積都不如小型機，但是一個優勢就決定了每年 2000 多億美元的 IDC 市場被 x86 伺服器佔領了 90%，這個優勢就是價格。畢竟有錢能使磨推鬼嘛。
現有的分散式計算，無論是 Hadoop 之類的大資料平臺，還是 HBase 這樣的分散式資料庫，無論是 Docker 這種容器排布，還是 Redis 這種樸素分散式資料庫，其本質都是因為 x86 的擴充套件性不夠好，導致大家只能自己想辦法利用網路來自己構建一個宏觀上更強效能更高負載能力的計算機。
x86 分散式計算，是一種新的計算機結構。
基於網路的 x86 伺服器分散式計算，其本質是把網路當做匯流排，設計了一套新的計算機體系結構：
- 每一臺機器就等於一個運算器加一個儲存器
- master 節點就是控制器加輸入裝置、輸出裝置
x86 分散式計算的弱點
上古時代，小型機的擴充套件能力是非常變態的，到今天，基於小型機的 Oracle 資料庫系統依舊能做到驚人的效能和可靠性。實際上單顆 x86 CPU 的效能已經遠超 IBM 小型機用的 PowerPC，但是當數量來到幾百顆，x86 伺服器叢集就敗下陣來，原因也非常簡單：
- 小型機是專門設計的硬體和專門設計的軟體，只面向這種規模（例如幾百顆 CPU）的計算
- 小型機是完全閉源的，不需要考慮擴充套件性，特定的幾種硬體在穩定性上前進了一大步
- x86 的 IO 效能被架構鎖死了，各種匯流排、PCI、PCIe、USB、SATA、乙太網，為了個人計算機的便利性，犧牲了很多的效能和可靠性
- 小型機使用匯流排通訊，可以實現極高的資訊傳遞效率，極其有效的監控以及極高的故障隔離速度
- x86 伺服器基於網路的分散式具有天然的缺陷：
- 作業系統決定了網路效能不足
- 網路需要使用事件驅動處理，比匯流排電路的延遲高几個數量級
- PC 機的硬體不夠可靠，故障率高
- 很難有效監控，隔離故障速度慢
x86 分散式計算的基本套路
Google 系大資料處理框架
2003 年到 2004 年間，Google 發表了 MapReduce、GFS（Google File System）和 BigTable 三篇技術論文，提出了一套全新的分散式計算理論。MapReduce 是分散式計算框架，GFS（Google File System）是分散式檔案系統，BigTable 是基於 Google File System 的資料儲存系統，這三大元件組成了 Google 的分散式計算模型。
Hadoop、Spark、Storm 是目前最重要的三大分散式計算系統，他們都是承襲 Google 的思路實現並且一步一步發展到今天的。
MapReduce 的基本原理也十分簡單：將可以並行執行的任務切分開來，分配到不同的機器上去處理，最終再彙總結果。而 GFS 是基於 Master-Slave 架構的分散式檔案系統，其 master 只扮演控制者的角色，操控著所有的 slave 幹活。
Redis、MongoDB 的分散式
Redis 有兩個不同的分散式方案。Redis Cluster 是官方提供的工具，它透過特殊的協議，實現了每臺機器都擁有資料儲存和分散式調節功能，效能沒有損失。缺點就是缺乏統一管理，運維不友好。Codis 是一個非常火的 Redis 叢集搭建方案，其基本原理可以簡單地描述如下：透過一個 proxy 層，完全隔離掉了分散式調節功能，底層的多臺機器可以任意水平擴充套件，運維十分友好。
MongoDB 官方提供了一套完整的分散式部署的方案，提供了 mongos 控制中心，config server 配置儲存，以及眾多的 shard（其底層一般依然有兩臺互為主從強資料一致性的 mongod）。這三個元件可以任意部署在任意的機器上，MongoDB 提供了 master 選舉功能，在檢測到 master 異常後會自動選舉出新的 master 節點。
問題和瓶頸
人們費這麼大的勁研究基於網路的 x86 伺服器分散式計算，目的是什麼？還不是為了省錢，想用一大票便宜的 PC 機替換掉昂貴的小型機、大型機。雖然人們已經想盡了辦法，但還是有一些頑固問題無法徹底解決。
master 失效問題
無論怎樣設計，master 失效必然會導致服務異常，因為網路本身不夠可靠，所以監控系統的容錯要做的比較高，所以基於網路的分散式系統的故障恢復時間一般在秒級。而小型機的單 CPU 故障對外是完全無感的。
現行的選舉機制主要以節點上的資料以及節點資料之間的關係為依據，透過一頓猛如虎的數學操作，選舉出一個新的 master。邏輯上，選舉沒有任何問題，如果 master 因為硬體故障而失效，新的 master 會自動頂替上，並在短時間內恢復工作。
而自然界總是狠狠地打人類的臉：
- 硬體故障機率極低，大部分 master 失效都不是因為硬體故障
- 如果是流量過大導致的 master 失效，那麼選舉出新的 master 也無濟於事：提升叢集規模才是解決之道
- 即使能夠及時地在一分鐘之內頂替上 master 的工作，那這一分鐘的異常也可能導致雪崩式的 cache miss，從磁碟快取到虛擬記憶體，從 TLB 到三級快取，再到二級快取和一級快取，全部失效。如果每一層的失效會讓系統響應時間增加五倍的話，那最終的總響應時長將是驚人的。
系統規模問題
無論是 Master-Slave 模式還是 Proxy 模式，整個系統的流量最終還是要落到一個特定的資源上。當然這個資源可能是多臺機器，但是依舊無法解決一個嚴重的問題：系統規模越大，其本底效能損失就越大。
這其實是我們所在的這個宇宙空間的一個基本規律。我一直認為，這個宇宙裡只有一個自然規律：熵增。既然我們這個宇宙是一個熵增宇宙，那麼這個問題就無法解決。
超級計算機
超級計算機可以看成一個規模特別巨大的分散式計算系統，他的效能瓶頸從目前的眼光來看，是超多計算核心（數百萬）的調節效率問題。其本質是通訊速率不夠快，資訊傳遞的太慢，讓數百萬核心一起工作，傳遞命令和資料的工作佔據了絕大多數的執行時間。
神經網路
深度學習這幾年大火，其原因就是卷積神經網路（CNN）造就的 AlphaGo 打敗了人類，計算機在這個無法窮舉的遊戲裡徹底贏了。伴隨著 Google 帝國的強大推力，深度學習，機器學習，乃至人工智慧，這幾個詞在過去的兩年大火，特別是在中美兩國。現在拿手機拍張照背後都有機器學習你敢信？
機器學習的瓶頸，本質也是資料交換：機器學習需要極多的計算，而計算速度的瓶頸現在就在運算器和儲存器的通訊上，這也是顯示卡搞深度學習比 CPU 快數十倍的原因：視訊記憶體和 GPU 資訊交換的速度極快。
九九歸一
分散式系統的效能問題，表現為多個方面，但是歸根到底，其原因只是一個非常單純的矛盾：人們日益增長的效能需求和資料一致性之間的矛盾。一旦需要強資料一致性，那就必然存在一個限制速度的瓶頸，這個瓶頸就是資訊傳遞的速度。
同樣，超級計算機和神經網路的瓶頸也都是資訊傳遞的速度。
那麼，資訊傳遞速度的瓶頸在哪裡呢？
我個人認為，資訊傳遞的瓶頸最表層是人類的硬體製造水平決定的，再往底層去是馮·諾依曼架構決定的，再往底層去是圖靈機的邏輯模型決定的。可是圖靈機是計算機可行的理論基礎呀，所以，還是怪這個熵增宇宙吧，為什麼規模越大維護成本越高呢，你也是個成熟的宇宙了，該學會自己把自己變成熵減宇宙了。
本文由機器之心經授權轉載自歲寒，未經授權禁止二次轉載。
原文連結：https://lvwenhan.com/%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F/498.html
【全系列完結】
