在互聯網大行其道的今天，各種分布式系統已經司空見慣。搜索引擎、電商網站、微博、微信、O2O平臺。。凡是涉及到大規模用戶、高并發訪問的，無一不是分布式。

關于分布式系統，并沒有一個標準答案，說某某架構一定是最好的。不同的業務形態所面對的挑戰不一樣，使用的架構設計也不一樣，通常都需要具體業務具體分析。

但不管那種業務，不管何種分布式系統，有一些基本的思想還是相通的。本文將對這些基本思想進行一個梳理匯總。

[[230402]]

分拆

系統分拆

微信的架構師說過一句話：“大系統小做“。對于一個大的復雜系統，首先想到的就是對其分拆，拆成多個子系統。每個子系統自己的存儲/Service/接口層，各個子系統獨立開發、測試、部署、運維。 

從團隊管理角度講，也可以不同團隊用自己熟悉的語言體系，團隊之間基于接口進行協作，職責清晰，各司其職。

子系統分拆

拆成子系統之后，子系統內部又可以分層，分模塊。當然，這里“系統“，“子系統“，“層“，“模塊“ 都只是一個相對概念。在一個系統里面，某個模塊復雜到一定程度，會把它抽出來，單獨做成一個系統；而在初期，很大簡單模塊，可能不回拆分，集中在一個系統里面。 

這就像一個生物組織，自身是在不斷成長、演化、有分有合，不斷變化發展的。

存儲分拆

Nosql：對于Nosql數據庫，比如MongoDB，其天生就是分布式的，很容易實現數據的分片。 

Mysql: 對于Mysql，或者其它關系型數據庫，就會設計到分庫分表。而分庫分表，就會涉及到幾個關鍵性的問題：切分維度，join的處理，分布式事務

計算分拆

計算的分拆有2種思路： 

數據分拆：一個大的數據集，拆分成多個小的數據集，并行計算。 

比如大規模數據歸并排序

任務分拆：把一個長的任務，拆分成幾個環節，各個環節并行計算。

Java中多線程的Fork/Join框架，Hadoop中的Map/Reduce，都是計算分拆的典型框架。其思路都是相似的，先分拆計算，再合并結果。

再比如分布式的搜索引擎中，數據分拆，分別建索引，查詢結果再合并。

并發

最常見的就是多線程，盡可能提高程序的并發度。 

比如多次rpc順序調用，通過異步rpc轉化為并發調用； 

比如數據分片，你的一個Job要掃描全表，跑幾個小時，數據分片，用多線程，性能會加快好幾倍。

緩存

緩存大家都不陌生，遇到性能問題，大家首先想到的就是緩存。關于緩存，一個關鍵點就是：緩存的粒度問題。

比如Tweet的架構，緩存的粒度從小到大，有Row Cache, Vector Cache, Fragment Cache, Page Cache。

粒度越小，重用性越好，但查詢需要多次，需要數據拼裝； 

粒度越大，越容易會失效，任何一個小的地方改動，都可能造成緩存的失效。

在線計算 vs. 離線計算 / 同步 vs. 異步

在實際的業務需求中，并不是所有需要都需要完全實時的： 

比如內部針對產品、運營開發的各種報表查詢、分析系統； 

比如微博的傳播，我發了一個微博，我的粉絲延遲幾秒才看到，這是可以接受的，因為他并不會注意到晚了幾秒； 

比如搜索引擎的索引，我發了一篇博客，可能幾分鐘之后，才會被搜索引擎索引到； 

比如支付寶轉帳、提現，也并非這邊轉出之后，對方立即收到； 

。。。

這類例子很多。這種“非實時也可以接受“的場景，就為架構的設計贏得了充分的回旋余地。

因為非實時，我們就可以做異步，比如使用消息隊列，比如使用后臺的Job，周期性處理某類任務；

也因為非實時，我們可以做讀寫分離，讀和寫不是完全同步，比如Mysql的Master-Slave。

全量 ＋ 增量

全量/增量其實也是在線/離線的思路： 

比如搜索引擎的全量索引 ＋ 增量索引，前者是為了吞吐，后者為了實時； 

比如OceanBase數據庫，每次更新存在一個小表里面，定期merge；

Push vs. Pull

在所有分布式系統中，都涉及到一個基本問題：節點之間（或者2個子系統之間）的狀態通知。比如一個節點狀態變更了，要通知另外一個節點，都有2種策略： 

Push: 節點A狀態變了， push給節點B 

Pull: 也就是輪詢。節點B周期性的去詢問節點A的狀態。

這個問題不光出現在分布式系統中，可以說是編寫代碼的一個基本問題。對應到面向對象的編程中，也就是常說的“雙向關聯”這種耦合問題。

A調用B，B再回調A，這種情形，在系統開發中經常出現。再復雜一點，多個模塊之間，彼此調用，調用關系跟蜘蛛網一樣。

這個問題的出現，就和Push/Pull的策略密切相關： 

A調用B，那邏輯就會寫在B這邊；B調用A，邏輯就會寫在A這邊。所以是采用主動調用的pull方式，還是回調的push方式，會嚴重影響職責在各個模塊或者子系統里面的分配。

批量

批量其實也是在線/離線的一種思想，把實時問題，轉化為一個批量處理的問題，從而降低對系統吞吐量的壓力 

比如Kafka中的批量發消息； 

比如廣告扣費系統中，把多次點擊累積在一起扣費； 

。。

重寫輕讀 vs 重讀輕寫

重寫輕讀，本質就是“空間換時間“。你不是計算起來耗時，延遲高嗎，那我可以提前計算，然后存儲起來。取的時候，直接去取。

我們通常對Mysql的用法，都是重讀輕寫，寫的時候，簡單；查的時候，做復雜的join計算，返回結果。這樣做的好處是容易做到數據的強一致性，不會因為字段冗余，造成數據的不一致。但是性能可能就是問題。

而微博的Feeds架構，就是典型的重寫輕讀。我要去看Feeds，按通常的mysql的做法，我要先去查我關注的所有的人，然后把所有人的消息排序，分頁返回。很顯然，在大數據量下，這個會很耗時。 

而如果采用重寫輕讀，怎么做呢？你不是要看Feeds嗎，那就為每個人準備一個Feeds，或者說收件箱。某個人發了微博之后，把他的微博擴散到所有人的收件箱，這個擴散是異步的，在后臺擴散。這樣每個人看自己的Feeds的時候，直接去自己的收件箱取就可以了。

讀寫分離

同樣，對傳統的單機Mysql數據庫，讀和寫是完全同步的。寫進去的內容，立馬就可以讀到。 

但在很多業務場景下，讀和寫并不需要完全同步。這個時候，就可以分開存儲，寫到一個地方，再異步的同步到另一個地方。這樣就可以實現讀寫分離。 

比如Mysql的Master/Slave就是個典型，Slave上面的數據并不是和Master實時同步的； 

再比如各種報表分析，OLTP/OLAP，線上/線下數據分離，線上數據定期同步到Hive集群，再做分析。

動靜分離

動靜分離的典型例子就是網站的前端，動態的頁面，放在web服務器上；靜態的css/jss/img，直接放到CDN上，這樣既提高性能，也極大的降低服務器壓力。

按照這個思路，很多大型網站都致力于動態內容的靜態化，靜態化之后，就可以很容易的緩存。

冷熱分離

比如定期把mysql中的歷史數據，同步到hive

限流

現在很多電商都會有秒殺活動，秒殺的一個特點就是商品很少，但短時間內流量暴增，服務器完全處理不了這么多請求。

應對這類問題的一個基本思路就是限流，既然處理不了那么多請求，既然很大人進去了，也是搶不到的。那索性不要放那么多人進去。

這個和我們日常生活中，節假日，某個景點人數過多，限制人流量是同樣的道理。

服務熔斷與降級

服務降級是系統的最后一道保險。在一個復雜系統內部，一個系統往往會調用其它很大系統的服務。在大流量的情況下，我們可能會在保證主流程能正常工作的情況下，對其它服務做降級。

所謂降級，也就是當某個服務不可用時，干脆就別讓其提供服務了，直接返回一個缺省的結果。雖然這個服務不可用，但它不至于讓整個主流程癱瘓，這就可以最大限度的保證核心系統可用。

CAP理論

上面講的各種思想，用一個更大的思想來概括的話，就是CAP。

Consistency：數據一致性，這個很容易理解，就是沒有臟數據。我們知道，在Mysql中有一致性的概念，比如參照完整性約束、事務等。但這里的C主要特指同1份數據的多個備份之間的一致性。

Availability：可用性有2重意思，一個是說穩定性，服務可用，不會掛；另外一個是性能，也就是要快，如果延遲很高，經常超時，那和掛了也就區別不大了。

Partition tolerance(分區容錯性)：分區，其實指網絡分區。當你把數據從1個物理設備，分到多個物理設備之后，設備之間必然是通過網絡進行通信。這就會遇到網絡分區，也就是典型的“2將軍問題“，網絡超時時間不定。學術上有個詞，叫“異步通信環境“。

以前說CAP理論，說對于一個分布式系統，上面3個，只能同時滿足2個。但這個其實不準確，P其實一定存在，是你避免不了的。能做的，其實主要是在C和A之間權衡。

比如拿Mysql來說，它的C最強，A次之，P最弱。如果你為了A，給數據做冗余，比如重寫輕讀，那C就很難保證；為了P，給數據做分庫分表，那就做不了事務；

比如Nosql，P最強，可以很好的做數據拆分，但C就不夠，做不了事務；

比如微博系統，對C的要求降低，就可以加很多緩存，提高A；數據分片，提高P；

而支付，交易轉帳，對C的要求很高，就不能簡單的用Cache來提高性能

[[230403]]

在此我向大家推薦一個架構學習交流群。交流學習群號：190713474 點擊原文鏈接加群，里面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

最終一致性

前面提到，在分布式系統中，因為數據的分拆，服務的分拆，強一致性就很難保證。這個時候，用的最多的就是“最終一致性“。

強一致性，弱一致性，最終一致性，是一致性的幾個不同的等級。在傳統的關系型數據庫中，通過事務來保證強一致性。

但在分布式系統中，通常都會把強一致性折中成最終一致性，從而變相的解決分布式事務問題。

典型的轉帳的例子，A給B轉帳1萬塊錢，A的賬號扣1萬，B的賬號加1萬。但這2步未必需要同時發生, A的扣完之后，B的賬號上面未必立馬就有，但只要保證B最終可以收到就可以了。 

最終一致性的實現，通常都需要一個高可靠的消息隊列。關于這個，網上有各種分享文章，后續也會對這個問題單獨闡述。