架構演進中單體架構的高難度演進和技術公升級我可能沒有經歷過，目前很多場景很多需求，都需要分布式系統去解決，不過大多數情況下我們可能不需要使用分布式相關的服務，但是業務的發展可能需要我們提前了解相關的技術作為技術儲備，隨時迎難而上。本篇文章作為分布式理論的一篇隨筆完全自己手敲去理解分布式系統需要解決的問題，後面可能會深入某些分布式系統做一些理論上的闡述。分布式系統的特性導致每個處於分布式系統中的節點都可能時刻處於不同的狀態，因此如果需要設計乙個分布式系統或者需要學習研究乙個分布式系統，其首要問題就是要解決
或者了解每個節點之間如何保證互相能夠訪問到，直接來說就是集群節點之間能否相互ping通，當節點之間需要就某乙個問題或者某些資料做一致性的處理的時候就需要解決這個問題，
也就是說當a,b兩個節點要提交同一條修改記錄的時候需要使用分布式鎖去保證a,b兩個節點中只有乙個能提交成功，而分布式鎖的作用也可以看做節點協調的功能。另乙個例子，
比如節點a需要訪問b,c,d，當b掛了的時候，或者b由於網路變慢出現問題，節點a要很快知道，否則a可能無法工作，如果將a,b兩個節點看做兩個分割槽，當a,b處於乙個分割槽同時由於網路問題變成
兩個分割槽的時候，怎麼對a,b兩個分割槽進行處理其實也是一種節點信任，比如a分割槽節點數量多a分割槽繼續提供服務，b節點數量少b中的節點停止服務。
實現節點之間的信任嚴重網路和資料傳輸，一旦出現問題則節點信任就可能無法完成。
第三個例子，我們可以從分布式id生成器來闡述這個問題，比如當a節點向分布式id生成器系統請求乙個id,那麼當a請求成功的時候b不可能再請求到同乙個id,不管時間如何變化，
同一時刻節點a和節點b都不能同時拿到同乙個id,也就是說a，b兩個節點已經根據分布式id生成器系統做了乙個默契的相互信任。
第四個例子，跟資料庫事務有關，比如分布式情況下如何保證資料事務的acid特性，以及如何保證對乙個分布式事務做一致性的處理，由於有不同的集群節點參與。那麼，
一旦事務提交或者事務回滾，後面需要處理相應資料的節點需要很快知道結果，如果事務回滾了一半或者事務執行了一半導致其他節點拿到不一致的錯誤資料那麼分布式的事務就做的很爛。
也就是說節點之間要對資料，對狀態做相互的信任。保證相關節點拿到的資料，知道的狀態都是盡量一致的。
由於是分布式系統，因此分布式系統必然需要有資料去承載業務，因此分布式系統的乙個要考慮的問題就是如何基於網路做一些協議來傳輸資料，因此談資料之前先把網路協議吃透，
很多分布式框架基於netty或者mina做網路通訊元件，可以自定義資料傳輸協議，rpc中可以使用http或者基於netty做自研的二進位制協議或者使用json等更易於操作的協議，當然，除此之外，
如redis,kafka,hadoop等都對其使用場景做了特別的資料協議和網路協議的研發和處理，這裡一方面指的是資料本身的協議可以在不同的節點之間通用，在應用層上做解析封裝等，另一方面指的是
網路協議，比如是基於tcp長連線的還是http長連線的，又或者是基於udp協議的。分布式系統的協議方面如果不是特別的場景或者對資料傳輸效率，資料處理效率不太敏感則一般採用通用的或者公開的
協議做底層互動元件。當然大多數情況下一單達到分布式的系統的話，資料網路協議如果處理不好很容易拖後腿，造成效能，安全，穩定性等問題。需要針對特定場景做特定的資料處理，
舉個例子，序列化與反序列化作為分布式系統的資料解析和封裝的理論可以有很多種實現。如json,xml,hession以及自定義的二進位制資料協議。
我認為資料儲存是分布式系統需要面臨的最後乙個問題，很多分布式系統面臨的問題都有資料儲存，由於單體系統無法解決海量資料，高併發的問題，導致資料儲存不能存在於單庫和單檔案，單資料容器中。
資料儲存，資料變更，資料發布都涉及分布式系統對其按規則做的一些處理，如果資料組織儲存協議，資料儲存中介軟體的選型不對或者不合適，那麼對於其設計的出來的
分布式系統肯定無法提供更完善更健壯的服務。後期對其進行迭代也很困難。比如hadoop，hbase,以及kafka等，當然還有redis,mongodb.對其資料儲存方面做了很多精妙的設計和技術改進來
適應更複雜的場景。當然，有些分布式系統可以不關注資料儲存，但是也不能忽略。比如nginx,dubbo,mycat,等偏服務偏響應的框架也需要對其存在的元資料和配置資料等做儲存，由於是分布式的，
這會導致資料儲存存在很多情況，比如資料庫層面的分片，分割槽，水平切分，垂直切分等。比如hadoop的大資料儲存，另外資料儲存的設計也決定著分布式系統能支撐多少量級的資料來滿足業務需求。
比如redis,其定位是基於記憶體的nosql資料庫，或者也可以當快取資料庫使用，由於是在記憶體，因此無法儲存更多或者更複雜的資料，即使使用多個節點也不能儲存tb級別的資料，即使可以，其他方面也會制約其
效能和穩定性。資料儲存的另乙個例子就是元資料，比如hadoop依賴zookeeper的內建資料庫做其ip等資訊的儲存，kafka依賴zookeeper做集群分割槽元資料的儲存。
如果是自研的分布式配置服務，那麼很多k-v的資料也需要考慮如何儲存如何保證資料的一致性。
總結：這裡只在巨集觀層面對分布式系統需要解決的問題做一些個人的理解和理論的總結，更多的情況下我們需要考慮相對細緻垂直的方向，比如分布式下的事務，快取，訊息，資料配置資料庫等。以及集群的執行原理，內在的是單執行緒的還是多執行緒的，能處理多少併發，能儲存多少資料等。每個方向上的方案和業界實現也有很多，但是重點是要以業務場景為基礎進行方案設計
研發，技術選型等。有能力的可以自研，沒能力的可以參考開源，八仙過海，各顯神通。
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...
解決分布式事務的問題
理論說明 1 資料庫的2階段提交協議 2pc或者稱為xa transactions 第一階段 事務協調器要求涉及事務的資料庫都預提交，並反饋是否可以提交 第二階段 事務協調器要求每個資料庫提交 回滾資料 2 base理論 對cap進一步補充 3 xa xa 是指由 x open 組織提出的分布式事務...
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...