分佈式系統 概念 高可用 高併發 學習筆記

分佈式系統 概念 高可用 高併發 學習筆記

0. 分佈式系統基本概念

0.1 背景

分佈式系統是由一組通過網絡進行通信、爲了完成共同的任務而協調工作的計算機節點組成的系統。分佈式系統的出現是爲了用廉價的、普通的機器完成單個計算機無法完成的計算、存儲任務。其目的是利用更多的機器，處理更多的數據。

首先需要明確的是，只有當單個節點的處理能力無法滿足日益增長的計算、存儲任務的時候，且硬件的提升（加內存、加磁盤、使用更好的CPU）高昂到得不償失的時候，應用程序也不能進一步優化的時候，我們才需要考慮分佈式系統。因爲，分佈式系統要解決的問題本身就是和單機系統一樣的，而由於分佈式系統多節點、通過網絡通信的拓撲結構，會引入很多單機系統沒有的問題，爲了解決這些問題又會引入更多的機制、協議，帶來更多的問題。

那麼分佈式系統怎麼將任務分發到這些計算機節點呢，很簡單的思想，分而治之，即分片（partition）。對於計算，那麼就是對計算任務進行切換，每個節點算一些，最終彙總就行了，這就是MapReduce的思想；對於存儲，更好理解一下，每個節點存一部分數據就行了。當數據規模變大的時候，Partition是唯一的選擇，同時也會帶來一些好處：

1. 提升性能和併發，操作被分發到不同的分片，相互獨立

2. 提升系統的可用性，即使部分分片不能用，其他分片不會受到影響

理想的情況下，有分片就行了，但事實的情況卻不大理想。原因在於，分佈式系統中有大量的節點，且通過網絡通信。單個節點的故障（進程crash、斷電、磁盤損壞）是個小概率事件，但整個系統的故障率會隨節點的增加而指數級增加，網絡通信也可能出現斷網、高延遲的情況。在這種一定會出現的“異常”情況下，分佈式系統還是需要繼續穩定的對外提供服務，即需要較強的容錯性。最簡單的辦法，就是冗餘或者複製集（Replication），即多個節點負責同一個任務，最爲常見的就是分佈式存儲中，多個節點複雜存儲同一份數據，以此增強可用性與可靠性。同時，Replication也會帶來性能的提升，比如數據的locality可以減少用戶的等待時間。

0.2 挑戰

分佈式系統需要大量機器協作，面臨諸多的挑戰：

第一，異構的機器與網絡：

分佈式系統中的機器，配置不一樣，其上運行的服務也可能由不同的語言、架構實現，因此處理能力也不一樣；節點間通過網絡連接，而不同網絡運營商提供的網絡的帶寬、延時、丟包率又不一樣。怎麼保證大家齊頭並進，共同完成目標，這四個不小的挑戰。

第二，普遍的節點故障：

雖然單個節點的故障概率較低，但節點數目達到一定規模，出故障的概率就變高了。分佈式系統需要保證故障發生的時候，系統仍然是可用的，這就需要監控節點的狀態，在節點故障的情況下將該節點負責的計算、存儲任務轉移到其他節點

第三，不可靠的網絡：

節點間通過網絡通信，而網絡是不可靠的。可能的網絡問題包括：網絡分割、延時、丟包、亂序。

相比單機過程調用，網絡通信最讓人頭疼的是超時：節點A向節點B發出請求，在約定的時間內沒有收到節點B的響應，那麼B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節點B會不會多次處理同一個請求。

0.3 特性與衡量標準

• 透明性：使用分佈式系統的用戶並不關心繫統是怎麼實現的，也不關心讀到的數據來自哪個節點，對用戶而言，分佈式系統的最高境界是用戶根本感知不到這是一個分佈式系統，在《[Distributed Systems Principles and Paradigms](http://barbie.uta.edu/~jli/Resources/MapReduce&Hadoop/Distributed Systems Principles and Paradigms.pdf)》一書中，作者是這麼說的：

A distributed system is a collection of independent computers that appears to its users as a single coherent system.

• 可擴展性：分佈式系統的根本目標就是爲了處理單個計算機無法處理的任務，當任務增加的時候，分佈式系統的處理能力需要隨之增加。簡單來說，要比較方便的通過增加機器來應對數據量的增長，同時，當任務規模縮減的時候，可以撤掉一些多餘的機器，達到動態伸縮的效果

• 可用性與可靠性：一般來說，分佈式系統是需要長時間甚至7*24小時提供服務的。可用性是指系統在各種情況對外提供服務的能力，簡單來說，可以通過不可用時間與正常服務時間的必知來衡量；而可靠性而是指計算結果正確、存儲的數據不丟失。

• 高性能：不管是單機還是分佈式系統，大家都非常關注性能。不同的系統對性能的衡量指標是不同的，最常見的：高併發，單位時間內處理的任務越多越好；低延遲：每個任務的平均時間越少越好。這個其實跟操作系統CPU的調度策略很像

• 一致性：分佈式系統爲了提高可用性可靠性，一般會引入冗餘（複製集）。那麼如何保證這些節點上的狀態一致，這就是分佈式系統不得不面對的一致性問題。一致性有很多等級，一致性越強，對用戶越友好，但會制約系統的可用性；一致性等級越低，用戶就需要兼容數據不一致的情況，但系統的可用性、併發性很高很多。

1. CAP定理與BASE理論

說到分佈式系統的特性，這裏有個著名的定理可以順便了解一下。

1.1 CAP 定理

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對於一個分佈式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistence） :所有節點訪問同一份最新的數據副本
• 可用性（Availability）:每次請求都能獲取到非錯的響應——但是不保證獲取的數據爲最新數據
• 分區容錯性（Partition tolerance） : 分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

CAP僅適用於原子讀寫的NOSQL場景中，並不適合數據庫系統。現在的分佈式系統具有更多特性比如擴展性、可用性等等，在進行系統設計和開發時，我們不應該僅僅侷限在CAP問題上。

注意：不是所謂的3選2（不要被網上大多數文章誤導了）:

大部分人解釋這一定律時，常常簡單的表述爲：“一致性、可用性、分區容忍性三者你只能同時達到其中兩個，不可能同時達到”。實際上這是一個非常具有誤導性質的說法，而且在CAP理論誕生12年之後，CAP之父也在2012年重寫了之前的論文。

當發生網絡分區的時候，如果我們要繼續服務，那麼強一致性和可用性只能2選1。也就是說當網絡分區之後P是前提，決定了P之後纔有C和A的選擇。也就是說分區容錯性（Partition tolerance）我們是必須要實現的。

1.2 BASE 理論

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，它大大降低了我們對系統的要求。

BASE理論的核心思想： 即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。也就是犧牲數據的一致性來滿足系統的高可用性，系統中一部分數據不可用或者不一致時，仍需要保持系統整體“主要可用”。

BASE理論三要素：

1. 基本可用： 基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性。但是，這絕不等價於系統不可用。 比如： ①響應時間上的損失:正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應時間增加了1~2秒；②系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峯的時候，由於消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面；
2. 軟狀態： 軟狀態指允許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時；
3. 最終一致性： 最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

2. 高可用

基本概念

高可用描述的是一個系統在大部分時間都是可用的，可以爲我們提供服務的。高可用代表系統即使在發生硬件故障或者系統升級的時候，服務仍然是可用的。

一般情況下，我們使用多少個 9 來評判一個系統的可用性，比如 99.9999% 就是代表該系統在所有的運行時間中只有 0.0001% 的時間是不可用的，這樣的系統就是非常非常高可用的了！當然，也會有系統如果可用性不太好的話，可能連 9 都上不了。

除此之外，系統的可用性還可以用某功能的失敗次數與總的請求次數之比來衡量，比如對網站請求 1000 次，其中有 10 次請求失敗，那麼可用性就是 99%。

爲什麼分佈式系統中必須要考慮可用性呢，這是因爲分佈式系統中故障的概率很高。分佈式系統由大量異構的節點和網絡組成，節點可能會crash、斷電、磁盤損壞，網絡可能丟包、延遲、網絡分割。系統的規模放大了出故障的概率，因此分佈式系統中，故障是常態。那麼分佈式系統的其中一個設計目標就是容錯，在部分故障的情況下仍然對外提供服務，這就是可用性。

2.2 高可用策略

冗餘是提高可用性、可靠性的法寶。

冗餘就是說多個節點負責相同的任務，在需要狀態維護的場景，比如分佈式存儲中使用非常廣泛。在分佈式計算，如MapReduce中，當一個worker運行異常緩慢時，master會將這個worker上的任務重新調度到其它worker，以提高系統的吞吐，這也算一種冗餘。但存儲的冗餘相比計算而言要複雜許多，因此主要考慮存儲的冗餘。

維護同一份數據的多個節點稱之爲多個副本。我們考慮一個問題，當向這個副本集寫入數據的時候，怎麼保證併發情況下數據的一致性，是否有一個節點有決定更新的順序，這就是中心化、去中心話副本協議的區別。

• 中心化與去中心化

  中心化就是有一個主節點（primary master）負責調度數據的更新，其優點是協議簡單，將併發操作轉變爲順序操作，缺點是primar可能成爲瓶頸，且在primary故障的時候重新選舉會有一段時間的不可用。

  去中心化就是所有節點地位平等，都能夠發起數據的更新，優點是高可用，缺點是協議複雜，要保證一致性很難。

  提到去中心化，比較有名的是dynamo，cassandra，使用了quorum、vector clock等算法來儘量保證去中心化環境下的一致性。

• 節點更新策略

  primary節點到secondary節點的數據時同步還是異步，即客戶端是否需要等待數據落地到副本集中的所有節點。

  同步的優點在於強一致性，但是可用性和性能（響應延遲）比較差；異步則相反。

• 數據流向

  即數據是如何從Primary節點到secondary節點的，有鏈式和主從模式。

  鏈式的優點時充分利用網絡帶寬，減輕primary壓力，但缺點是寫入延遲會大一些。GFS，MongoDB（默認情況下）都是鏈式。

• 部分節點寫入異常

  理論上，副本集中的多個節點的數據應該保持一致，因此多個數據的寫入理論上應該是一個事務：要麼都發生，要麼都不發生。但是分佈式事務（如2pc）是一個複雜的、低效的過程，因此副本集的更新一般都是best effort 1pc，如果失敗，則重試，或者告訴應用自行處理。

• primary的選舉

  在中心化副本協議中，primary節點是如何選舉出來的，當primary節點掛掉之後，又是如何選擇出新的primary節點呢，有兩種方式：自治系統，依賴其他組件的系統。（ps，這兩個名字是我杜撰的 。。。）

  所謂的自治系統，就是節點內部自行投票選擇，比如mongodb，tfs，zookeeper

  依賴其他組件的系統，是指primary由副本集之後的組件來任命，比如GFS中的primary由master（GFS的元數據服務器）任命，hdfs的元數據namenode由zookeeper心跳選出。

• secondary是否對外提供服務（讀服務）

  中心化複製集中，secondary是否對外提供讀服務，取決於系統對一致性的要求。

  比如前面介紹到節點更新策略時，可能是異步的，那麼secondary上的數據相比primary會有一定延遲，從secondary上讀數據的話無法滿足強一致性要求。

  比如元數據，需要強一致性保證，所以一般都只會從primary讀數據。而且，一般稱主節點爲active（master），從節點爲standby（slave）。在這種情況下，是通過冗餘 加上 快速的failover來保證可用性。

2.3 哪些情況會導致系統不可用？

1. 黑客攻擊；
2. 硬件故障，比如服務器壞掉。
3. 併發量/用戶請求量激增導致整個服務宕掉或者部分服務不可用。
4. 代碼中的壞味道導致內存泄漏或者其他問題導致程序掛掉。
5. 網站架構某個重要的角色比如 Nginx 或者數據庫突然不可用。
6. 自然災害或者人爲破壞。

2.4 提高系統可用性的方法

1. 注重代碼質量，測試嚴格把關

   代碼質量有問題比如比較常見的內存泄漏、循環依賴都是對系統可用性極大的損害。

2. 使用集羣，減少單點故障

3. 限流

   流量控制（flow control），其原理是監控應用流量的 QPS 或併發線程數等指標，當達到指定的閾值時對流量進行控制，以避免被瞬時的流量高峯沖垮，從而保障應用的高可用性。

4. 超時和重試機制設置

   一旦用戶請求超過某個時間的得不到響應，就拋出異常。這個是非常重要的，很多線上系統故障都是因爲沒有進行超時設置或者超時設置的方式不對導致的。我們在讀取第三方服務的時候，尤其適合設置超時和重試機制。一般我們使用一些 RPC 框架的時候，這些框架都自帶的超時重試的配置。如果不進行超時設置可能會導致請求響應速度慢，甚至導致請求堆積進而讓系統無法在處理請求。重試的次數一般設爲 3 次，再多次的重試沒有好處，反而會加重服務器壓力（部分場景使用失敗重試機制會不太適合）。

5. 熔斷機制

   超時和重試機制設置之外，熔斷機制也是很重要的。 熔斷機制說的是系統自動收集所依賴服務的資源使用情況和性能指標，當所依賴的服務惡化或者調用失敗次數達到某個閾值的時候就迅速失敗，讓當前系統立即切換依賴其他備用服務。 比較常用的是流量控制和熔斷降級框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel。

6. 異步調用

   異步調用的話我們不需要關心最後的結果，這樣我們就可以用戶請求完成之後就立即返回結果，具體處理我們可以後續再做，秒殺場景用這個還是蠻多的。但是，使用異步之後我們可能需要 適當修改業務流程進行配合，比如用戶在提交訂單之後，不能立即返回用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單之後，甚至出庫後，再通過電子郵件或短信通知用戶訂單成功。除了可以在程序中實現異步之外，我們常常還使用消息隊列，消息隊列可以通過異步處理提高系統性能（削峯、減少響應所需時間）並且可以降低系統耦合性。

7. 使用緩存

   如果我們的系統屬於併發量比較高的話，如果我們單純使用數據庫的話，當大量請求直接落到數據庫可能數據庫就會直接掛掉。使用緩存緩存熱點數據，因爲緩存存儲在內存中，所以速度相當地快！

8. 其他

   1. 核心應用和服務優先使用更好的硬件
   2. 監控系統資源使用情況增加報警設置。
   3. 注意備份，必要時候回滾。
   4. 灰度發佈： 將服務器集羣分成若干部分，每天只發布一部分機器，觀察運行穩定沒有故障，第二天繼續發佈一部分機器，持續幾天才把整個集羣全部發布完畢，期間如果發現問題，只需要回滾已發佈的一部分服務器即可
   5. 定期檢查/更換硬件： 如果不是購買的雲服務的話，定期還是需要對硬件進行一波檢查的，對於一些需要更換或者升級的硬件，要及時更換或者升級。

3. 高性能 / 高併發

1. 提高硬件能力、增加系統服務器。（當服務器增加到某個程度的時候系統所能提供的併發訪問量幾乎不變，所以不能根本解決問題）

2. 使用緩存（本地緩存：本地可以使用JDK自帶的 Map、Guava Cache.分佈式緩存：Redis、Memcache.本地緩存不適用於提高系統併發量，一般是用處用在程序中。比如Spring是如何實現單例的呢？大家如果看過源碼的話，應該知道，S把已經初始過的變量放在一個Map中，下次再要使用這個變量的時候，先判斷Map中有沒有，這也就是系統中常見的單例模式的實現。）

3. 消息隊列 （解耦+削峯+異步）

4. 採用分佈式開發 （不同的服務部署在不同的機器節點上，並且一個服務也可以部署在多臺機器上，然後利用 Nginx 負載均衡訪問。這樣就解決了單點部署(All In)的缺點，大大提高的系統併發量）

5. 數據庫分庫（讀寫分離）、分表（水平分表、垂直分表）

   當MySQL單表記錄數過大時，數據庫的CRUD性能會明顯下降，一些常見的優化措施如下：

   1. 限定數據的範圍： 務必禁止不帶任何限制數據範圍條件的查詢語句。比如：我們當用戶在查詢訂單歷史的時候，我們可以控制在一個月的範圍內；
   2. 讀/寫分離： 經典的數據庫拆分方案，主庫負責寫，從庫負責讀；
   3. 垂直分區： 根據數據庫裏面數據表的相關性進行拆分。 例如，用戶表中既有用戶的登錄信息又有用戶的基本信息，可以將用戶表拆分成兩個單獨的表，甚至放到單獨的庫做分庫。簡單來說垂直拆分是指數據表列的拆分，把一張列比較多的表拆分爲多張表。 如下圖所示，這樣來說大家應該就更容易理解了。
      垂直拆分的優點： 可以使得行數據變小，在查詢時減少讀取的Block數，減少I/O次數。此外，垂直分區可以簡化表的結構，易於維護。垂直拆分的缺點： 主鍵會出現冗餘，需要管理冗餘列，並會引起Join操作，可以通過在應用層進行Join來解決。此外，垂直分區會讓事務變得更加複雜；
   4. 水平分區： 保持數據表結構不變，通過某種策略存儲數據分片。這樣每一片數據分散到不同的表或者庫中，達到了分佈式的目的。 水平拆分可以支撐非常大的數據量。 水平拆分是指數據錶行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的數據拆成多張表來存放。舉個例子：我們可以將用戶信息表拆分成多個用戶信息表，這樣就可以避免單一表數據量過大對性能造成影響。水平拆分可以支持非常大的數據量。需要注意的一點是:分表僅僅是解決了單一表數據過大的問題，但由於表的數據還是在同一臺機器上，其實對於提升MySQL併發能力沒有什麼意義，所以 水平拆分最好分庫 。水平拆分能夠 支持非常大的數據量存儲，應用端改造也少，但 分片事務難以解決 ，跨界點Join性能較差，邏輯複雜。《Java工程師修煉之道》的作者推薦 儘量不要對數據進行分片，因爲拆分會帶來邏輯、部署、運維的各種複雜度 ，一般的數據表在優化得當的情況下支撐千萬以下的數據量是沒有太大問題的。如果實在要分片，儘量選擇客戶端分片架構，這樣可以減少一次和中間件的網絡I/O。

   下面補充一下數據庫分片的兩種常見方案：

   • 客戶端代理： 分片邏輯在應用端，封裝在jar包中，通過修改或者封裝JDBC層來實現。 噹噹網的 Sharding-JDBC 、阿里的TDDL是兩種比較常用的實現。
   • 中間件代理： 在應用和數據中間加了一個代理層。分片邏輯統一維護在中間件服務中。 我們現在談的 Mycat 、360的Atlas、網易的DDB等等都是這種架構的實現。

6. 採用集羣 （多臺機器提供相同的服務）

7. CDN 加速 (將一些靜態資源比如圖片、視頻等等緩存到離用戶最近的網絡節點)

8. 瀏覽器緩存

9. 使用合適的連接池（數據庫連接池、線程池等等）

10. 適當使用多線程進行開發。

4. 一致性

4.1 系統角度的一致性

1. 強一致性：當更新操作在某個副本上執行成功後，之後所有的讀操作都要能夠獲得最新的數據。對於單副本而言，讀寫操作都是在同一數據上執行，很容易保證一致性；而對於多副本數據，則需要使用分佈式協議如2PC協議。

2. 弱一致性：當更新某數據時，用戶讀到最新的數據需要一段時間。

3. 最終一致性：它是一種特殊形式的弱一致性。它不能保證當某個數據Ｘ更新後，在所有後續對Ｘ的操作能夠看到新數據，而是需要一個時間片段，在經過該時間片段之後，則能保證。在這個時間片段內，數據可能是不一致的，該片段稱“不一致窗口“。

4.2 用戶角度的一致性

1. **單調讀一致性（Monotonic-read Consistency）**當進程從一個地方讀出數據x，那麼以後再讀到的x應該是和當前x相同或比當前更新的版本。也就是說，如果進程遷移到了別的位置，那麼對x的更新應該比進程先到達。以分佈式郵件數據庫系統爲例。每個用戶的郵箱可能分佈式地複製在多臺機器上。郵件可能被插入任何一個位置的郵箱。但是，數據更新是以一種懶惰的方式傳播的。假設用戶在杭州讀取了他的郵件（假定只讀取郵件不會影響其他郵箱，也就是說，消息不會被刪除，甚至不會被標記爲已讀），當用戶飛到惠州後，單調讀一致性可以保證當他在惠州打開他的郵箱時，郵箱中仍然有杭州郵箱裏的那些消息。

2. **單調寫一致性（Monotonic-write Consistency）**跟單調讀相似，如果一個進程寫一個數據 x，那麼它在本地或遷移到別的地方再進行寫操作的時候，原來的寫操作必須先傳播到這個位置。也就是說，進程要在任何地方至少和上一次寫一樣新的數據。

3. **讀寫一致性（Read-your-writes Consistency) **讀寫一致性指一個進程對於數據x的寫操作，進程無論到任何副本上都應該能被後續讀操作看到這個寫操作的影響，也就是看到寫操作的影響或更新的值。也就是說，寫操作總是在同一個進程執行的後續讀操作之前完成的，而不管這個後續讀操作發生在什麼位置。

4. **寫讀一致性（Writes-follow-reads Consistency)**顧名思義，寫讀一致性就是在讀操作後面的寫操作基於至少跟上一次讀出來一樣新的值。也就是說，如果進程在地點1讀了x，那麼在地點2要寫x的副本的話，至少寫的時候應該基於和地點1讀出的一樣新的值。舉個例子，用戶先讀了文章A，然後他回覆了一篇文章B。爲了滿足讀寫一致性，B被寫入任何副本之前，需要保證A必須已經被寫入那個副本。即，當原文章存儲在某個本地副本上時，該文章的迴應文章才能被存儲到這個本地副本上。

5. 可擴展

可擴展性是指當系統的任務（work）增加的時候，通過增加資源來應對任務增長的能力。可擴展性是任何分佈式系統必備的特性，這是由分佈式系統的概念決定的：

分佈式系統是由一組通過網絡進行通信、爲了完成共同的任務而協調工作的計算機節點組成的系統

分佈式系統的出現是爲了解決單個計算機無法完成的計算、存儲任務。那麼當任務規模增加的時候，必然就需要添加更多的節點，這就是可擴展性。

擴展性的目標是使得系統中的節點都在一個較爲穩定的負載下工作，這就是負載均衡，當然，在動態增加節點的時候，需要進行任務（可能是計算，可能是數據存儲）的遷移，以達到動態均衡。

那麼首先要考慮的問題就是，如何對任務進行拆分，將任務的子集分配到每一個節點，我們稱這個過程問題Partition（Sharding）。

1. 分片分式，即按照什麼算法對任務進行拆分

   常見的算法包括：哈希（hash），一致性哈希（consistency hash），基於數據範圍（range based）。每一種算法有各自的優缺點，也就有各自的適用場景。

2. 分片的鍵，partition key

   partition key是數據的特徵值，上面提到的任何分片方式都依賴於這個partition key，那麼該如何選擇呢

   partition key會影響到任務在分片之間的均衡，而且一些系統中（mongodb）幾乎是不能重新選擇partition key的，因此在設計的時候就得想清楚

3. 分片的額外好處

   提升性能和併發：不同的請求分發到不同的分片

   提高可用性：一個分片掛了不影響其他的分片

4. 分片帶來的問題

   如果一個操作需要跨越多個分片，那麼效率就會很低下，比如數據中的join操作

5. 元數據管理

   元數據記錄了分片與節點的映射關係、節點狀態等核心信息，分佈式系統中，有專門的節點（節點集羣）來管理元數據，我們稱之爲元數據服務器。元數據服務器有以下特點：

   高性能：cache

   高可用：冗餘 加 快速failover

   強一致性（同時只有一個節點對外提供服務）

6. 任務的動態均衡

   爲了達到動態均衡，需要進行數據的遷移，如何保證在遷移的過程中保持對外提供服務，這也是一個需要精心設計的複雜問題。

Ref

1. https://www.cnblogs.com/hxsyl/p/4381980.html CAP定理
2. https://www.cnblogs.com/xybaby/p/7787034.html 分佈式系統概念
3. https://www.cnblogs.com/xybaby/p/8544715.html
4. 《億級流量網站架構核心技術》