分布式是個很大的概念和領域，它涉及到眾多相關的知識，比如分布式鎖，分布式事務，訊息機制，資料庫分片，複製，容災，分布式檔案系統等等。
那麼它為什麼值得我們研究呢？以及未來還會有哪些發展趨勢，和其他領域的知識有**是相通的呢？這篇文章將給你介紹一下。
說起分布式，大家可能最熟悉不過的就是2pc和3pc了，2pc即二階段提交，它是為了解決分布式環境下，資料的強一致性衍生出的概念。具體實現原理是第一階段用於確認每個節點是否都處於準備階段，確認完成後再進行提交。這樣雖然保證了每個節點資料的強一致性，卻帶來了吞吐量的下降和阻塞，而且還會有問題。假如在第一階段完成之後，中心節點掛了，那麼其他節點返回的狀態必然得不到確認，那也就無從談及下一階段的事情了。
後來又衍生出了著名的raft和paxos，利用選舉和提案的方法才解決了這個問題，但是效能損耗過大導致它不能應用於高併發且效能要求高的場景之下。
這些都屬於為了滿足cap原理而創造出的理論，而分布式領域還有乙個很重要的原理就是base，也就是最終一致性原理。它只需要保證在分布式環境下，資料的最終一致性就可以，可以忍受一時的不一致，就比方支付訂單後，客戶只需要等待東西送上門即可，而這背後的銀行入賬，減庫存，記錄訂單，列印發票，配送服務對接這些都不需要立刻就讓客戶看到，可以「緩慢」在後台進行。
之後可能會想到redis實現的分布式鎖，其實相比較於資料庫鎖，zk的分布式鎖，redis的實現比較簡單，主要實現了加鎖和解鎖的是同乙個requestid。
當然還有資料庫領域的水平擴充套件和垂直擴充套件，也屬於分布式的領域問題，典型的當屬mysql的水平擴充套件，我們都知道其分為分庫，複製以及sharding。
總結的話，分布式系統分為三個方向：
1 分布式儲存
2 分布式計算
3 分布式管理
***分布式儲存***
分布式儲存中又分為幾個子方向：
1 結構化儲存
2 非結構化儲存
3 半結構化儲存
4 in-memory儲存
除了這四個子方向外，分布式儲存還有一系列演算法和理論支撐，例如前文提到的paxos，cap，consistenthash，timing，2pc，3pc等等。
結構化儲存最多提到的就是關係型資料庫（rdbms）。大家最熟悉的就是mysql，postgresql了，然而結構化儲存的可擴充套件性都不是很好。
非結構化儲存最典型的系統就是分布式檔案系統，比如谷歌推出的gfs，主要思想是：
1 用master來管理metadata
2 檔案使用64mb的chunks來儲存，並且在不同的server上儲存多個副本
3 自動容錯，自動錯誤恢復
谷歌設計其的目的就是為了儲存海量日誌和網頁等文字資訊，並對其進行批量處理。雖然分布式檔案系統可擴充套件性和吞吐量都非常好，但他們不支援隨機訪問，只能對檔案進行追加操作。這使得非結構化儲存很難面對低延遲，實時性強的應用。
半結構化儲存是為了解決非結構化儲存隨機訪問效能差的問題。其中以nosql、k-v store、thrift（一種物件儲存）為代表。nosql不僅具備分布式檔案系統的可擴充套件性，而且延續了結構化儲存的隨機訪問能力，可以簡單k-v進行儲存，而摒棄了sql查詢和acid事務，比較代表的產品是谷歌的bigtable，amazon的dynamo，hbase等。他們的底層都是採用比較成熟的儲存引擎，比如leveldb，底層資料結構採用lsm-tree。
最後講到的是in-memory儲存。由於業務併發越來越高以及低延遲的需求，同時記憶體**不斷下降，基於記憶體的儲存系統也開始普及。比較出名的是memecached，redis。主要目的是為基於磁碟的儲存系統做cache。
另外需要提到的一點是，前文說過結構化儲存在可擴充套件性方面做的不是太好，非結構化儲存又不具備關係模型。綜合這兩點，在2023年谷歌發表了spanner以及2023年的f1奠定了newsql的基礎，但打造這樣的nosql和rdbms的融合的大型資料中心必須得到大公司的支援。
***分布式計算***
那麼首先思考這個問題：分布式計算和平行計算有什麼區別嗎？
一句話概括：平行計算追求的是速度，而分布式計算追求的是資料量
分布式計算可以分為以下幾個方向：
1 傳統基於msg的系統
2 mapreduce-like系統
3 圖計算系統
4 基於狀態的系統
5 streaming系統
基於msg的系統比較有代表性的要屬mpi（message passing inte***ce）。它除了提供訊息傳遞介面之外，其框架還實現了資源管理和分配以及排程的功能。
mr-like系統又叫做dataflow系統，以hadoop和spark為代表。這一類系統的特點是將計算抽象稱為high-level operator比如map,reduce,filter等等。它比mpi最有優勢的地方就是他具備比較完備的容錯機制，在任何時候的出錯系統框架都可以從上乙個狀態恢復。但缺點也比較明顯，支援的機器學習模型通常都不是很大且集群效率很低。
最後要講的是streaming系統，這裡比較典型的系統是storm、spark和flink等。flink通過jobclient、jobmanager和taskmanager實現了任務在工作流中的狀態變換和控制，以及工作流程的排程，效率很高，而且在最近的發布版本中引入了akka作為其actor模型框架，在支援併發的方面上更上乙個台階。
分布式管理留著下次再更新。
未來的併發和分布式程式設計
世界是併發的，我們周圍的一切都是非同步和事件驅動的。在最近召開的倫敦qcon大會上，joe duffy在他的主題演講裡宣稱，未來每乙個開發者都需要同併發和雲打交道。其中的核心在於通訊，它對於併發和分布式系統都至關重要。duffy曾任微軟的語言和編譯器工程總監，他認為分布式的就是併發的 本質上就是很多...
未來的併發和分布式程式設計
世界是併發的，我們周圍的一切都是非同步和事件驅動的。在最近召開的倫敦qcon大會上，joe duffy在他的主題演講裡宣稱，未來每乙個開發者都需要同併發和雲打交道。其中的核心在於通訊，它對於併發和分布式系統都至關重要。duffy曾任微軟的語言和編譯器工程總監，他認為分布式的就是併發的 本質上就是很多...
分布式技術之分布式ID和分布式事務
mycat不支援只能使用在sharding jdbc中 public class mysharding implements preciseshardingalgorithm spring.shardingsphere.sharding.tables.t order.actual data node...