如果曹操懂分布式，赤壁之戰也許就不會輸

相比於三國演義中「反間計」、「草船借箭」、「舌戰群儒」、「苦肉計」等情節的過度渲染，真實的赤壁之戰則顯得簡單粗暴得多：

建安十三年十二月，周瑜（3萬）率領軍隊在樊口與劉備和劉琦（共1萬＋）會合。

然後兩軍（共4萬＋）逆水而上，行至赤壁，與正在渡江的曹軍（約7萬）相遇。

當時曹軍瘟疫流行，而新編水軍及新收編的荊州水軍難以磨合，士氣明顯不足，因此初戰被周瑜水軍打敗。

曹操不得不把水軍「引次江北」與陸軍會合，把戰船靠到北岸烏林一側，操練水軍，等待良機。

周瑜則把戰船停靠南岸赤壁一側，與曹軍對峙。

由於北方士卒不習慣坐船，水站能力尚弱，於是曹操下令將艦船首尾連接起來，人馬於船上如履平地（三國演義中向曹操獻此餿主意的是龐統，並且用了一個「巧授連環計」的梗，來表明龐統的「身在曹營，心在漢」）。

周瑜部將黃蓋（歷史上，此時的諸葛亮還僅僅是一個小小的傳訊官）於是建議（《三國志·吳書·周瑜魯肅呂蒙傳》）：

今寇眾我寡，難與持久。

然觀操軍船艦首尾相接，可燒而走也。

周瑜採納了黃蓋的火攻計策，並讓黃蓋向曹操詐降，以便於可以接近曹操戰船，為火攻打下基礎。

隨後，便是那場著名的大火，以及後來的三足鼎立。

眾所周知，整個戰役的一個重要的FLAG，就是曹操的「鐵鎖連舟」。

現在，我們就從技術的角度來說說這個鐵甲連舟存在的一個致命弱點。

從形式上，鐵鎖連舟是希望通過一種橫向擴展的方式，船與船之間雖然通過連接形成一個整體，進而解決單個船隻在水面上的搖擺問題，寄希望於形成1+1>2的效果。

這看上去是似乎是一個不錯的方法，並實現了整個系統的快速擴展，但這裡的一個知名缺陷就是：中心化。

實際上，這仍然是一種「煙囪式」的集中部署模式，這種「一竿子插到底」的方式造成了每套硬體（船）與所承載應用（打仗）系統的「專機專用」，整體資源利用率不高。

如果曹操真正理解了分布式的概念，那麼他就應該知道，相比於擴展能力，無中心化、靈活才是分布式系統的核心所在。

以SandStone統一存儲為例，不管是通用硬體還是橫向擴展，其根本都是通過採用無中心化或多中心化的管理結構與已實現的，通過採用分布式哈希數據路由算法，分布式無狀態機頭、無元數據去中心化等技術方式，使得整個存儲系統自控能力更強。

此外，傳統集中式存儲系統雖然在結構上更為穩定，但其一旦發生故障就會造成「塌方式」的影響，而SandStone在靈活性、自我決策等方面的優勢更為明顯，通過對故障域的快速、準確隔離，可以消除單點故障對整個系統的影響。

同時，SandStone的強一致性複製技術確保多個數據副本的一致性，當單點故障後，可在整個集群中範圍內自動並行重建，快速恢復。

如果曹操懂分布式，那麼幾千條戰船就不會付之一炬；如果幾千條戰船沒有付之一炬，那麼赤壁之戰也許就不會輸；如果赤壁之戰沒有輸，那麼......

註：本文圖片來自網絡