一般來說，數據分片是將整體數據分攤在多個存儲設備上，這樣每個存儲設備的數據量相對就會小很多，以此滿足系統的性能需求。本文主要討論數據分片的三個問題：如何做數據分片、數據分片的特征值以及數據分片元數據的管理。下面請看具體內容~

分布式系統，尤其是分布式存儲系統，需要解決的兩個最主要的問題即數據分片和數據冗余，下圖形象生動地解釋了其概念和區別：

圖 1 來源于：http://book.mixu.net/distsys/intro.html

其中數據A、B即屬于數據分片，原始數據被拆分成兩個正交子集分布在兩個節點上。而數據集C屬于數據冗余，同一份完整的數據在兩個節點都有存儲。當然，在實際的分布式系統中，數據分片和數據冗余一般都是共存的。

本文主要討論數據分片的三個問題：

• 如何做數據分片，即如何將數據映射到節點上；
• 數據分片的特征值，即按照數據中的哪一個屬性（字段）來分片；
• 數據分片的元數據的管理，如何保證元數據服務器的高性能、高可用，如果是一組服務器，如何保證強一致性。

所謂分布式系統，就是利用多個獨立的計算機來解決單個節點（計算機）無法處理的存儲、計算問題，這是非常典型的分而治之的思想。每個節點只負責原問題（即整個系統需要完成的任務）的一個子集，可是原問題如何拆分到多個節點？在分布式存儲系統中，任務的拆分即數據分片。

數據分片（segment，fragment，shard，partition），就是按照一定的規則，將數據集劃分成相互獨立、正交的數據子集，然后將數據子集分布到不同的節點上。

注意，這里提到，數據分片需要按照一定的規則，不同的分布式應用有不同的規則，但都遵循同樣的原則：按照最主要、最頻繁使用的訪問方式來分片。

三種數據分片方式

首先介紹三種分片方式：hash方式、一致性hash（consistent hash）、按照數據范圍（range based）。對于任何方式，都需要思考以下幾個問題：

• 具體如何劃分原始數據集？
• 當原問題的規模變大的時候，能否通過增加節點來動態適應？
• 當某個節點故障的時候，能否將該節點上的任務均衡的分攤到其他節點？
• 對于可修改的數據（比如數據庫數據），如果某節點數據量變大，能否以及如何將部分數據遷移到其他負載較小的節點，達到動態均衡的效果？
• 元數據的管理（即數據與物理節點的對應關系）規模？元數據更新的頻率以及復雜度？

為了后面分析不同的數據分片方式，假設有三個物理節點，編號為N0、N1、N2，有以下幾條記錄：

R0: {id: 95, name: 'aa', tag:'older'}

R1: {id: 302, name: 'bb',}

R2: {id: 759, name: 'aa',}

R3: {id: 607, name: 'dd', age: 18}

R4: {id: 904, name: 'ff',}

R5: {id: 246, name: 'gg',}

R6: {id: 148, name: 'ff',}

R7: {id: 533, name: 'kk',}

1. hash 方式

哈希表（散列表）是最為常見的數據結構，根據記錄（或者對象）的關鍵值將記錄映射到表中的一個槽（slot），便于快速訪問。

絕大多數編程語言都有對hash表的支持，如Python中的dict、C++中的map、Java中的Hashtable，Lua中的table等等。在哈希表中，最為簡單的散列函數是mod N（N為表的大小），即首先將關鍵值計算出hash值（這里是一個整型），通過對N取余，余數即在表中的位置。

數據分片的hash方式也是這個思想，即按照數據的某一特征（key）來計算哈希值，并將哈希值與系統中的節點建立映射關系，從而將哈希值不同的數據分布到不同的節點上。

我們選擇id作為數據分片的key，那么各個節點負責的數據如下：

圖 2

由此可以看到，按照hash方式做數據分片，優點是映射關系非常簡單，需要管理的元數據也非常之少，只需要記錄節點的數目以及hash方式就行了。

但hash方式的缺點也非常明顯：當加入或者刪除一個節點的時候，大量的數據需要移動。比如在這里增加一個節點N3，因此hash方式變為了mod4，數據的遷移如下：

圖 3

這種方式是不滿足單調性（Monotonicity）的：如果已經有一些內容通過哈希分派到了相應的緩沖中，又有新的緩沖加入到系統中，哈希的結果應能夠保證原有已分配的內容可以被映射到原有的或者新的緩沖中去，而不會被映射到舊的緩沖集合中的其他緩沖區。

在工程中，為了減少遷移的數據量，節點的數目可以成倍增長，這樣概率上來講至多有50%的數據遷移。

hash方式還有一個缺點，即很難解決數據不均衡的問題。有兩種情況：

• 原始數據的特征值分布不均勻，導致大量的數據集中到一個物理節點上；
• 對于可修改的記錄數據，單條記錄的數據變大。

在這兩種情況下，都會導致節點之間的負載不均衡，而且在hash方式下很難解決。

2. 一致性 hash

一致性hash是將數據按照特征值映射到一個首尾相接的hash環上，同時也將節點（按照IP地址或者機器名hash）映射到這個環上。對于數據，從數據在環上的位置開始，順時針找到的第一個節點即為數據的存儲節點。

這里仍然以上述的數據為例，假設id的范圍為［0，1000］，N0、N1、N2在環上的位置分別是100、400、800，那么hash環示意圖與數據的分布如下：

圖 4

可以看到相比于上述的hash方式，一致性hash方式需要維護的元數據額外包含了節點在環上的位置，但這個數據量也是非常小的。

一致性hash在增加或者刪除節點的時候，受到影響的數據比較有限，比如這里增加一個節點N3，其在環上的位置為600，因此，原來N2負責的范圍段（400,800］現在由N3（400,600］N2（600,800］負責，因此只需要將記錄R7（id:533）從N2，遷移到N3。

不難發現一致性hash方式在增刪的時候只會影響到hash環上響應的節點，不會發生大規模的數據遷移。

但是，一致性hash方式在增加節點的時候，只能分攤一個已存在節點的壓力；同樣，在其中一個節點掛掉的時候，該節點的壓力也會被全部轉移到下一個節點。我們希望的是“一方有難，八方支援”，因此需要在增刪節點的時候，已存在的所有節點都能參與響應，達到新的均衡狀態。

所以，在實際工程中，一般會引入虛擬節點（virtual node）的概念，即不是將物理節點映射在hash環上，而是將虛擬節點映射到hash環上。虛擬節點的數目遠大于物理節點，因此一個物理節點需要負責多個虛擬節點的真實存儲。操作數據的時候，先通過hash環找到對應的虛擬節點，再通過虛擬節點與物理節點的映射關系找到對應的物理節點。

引入虛擬節點后的一致性hash需要維護的元數據也會增加：第一，虛擬節點在hash環上的問題，且虛擬節點的數目又比較多；第二，虛擬節點與物理節點的映射關系。但帶來的好處是明顯的，當一個物理節點失效時，hash環上多個虛擬節點失效，對應的壓力也就會發散到多個其余的虛擬節點，事實上也就是多個其余的物理節點。在增加物理節點的時候同樣如此。

工程中，Dynamo、Cassandra都使用了一致性hash算法，且在比較高的版本中都使用了虛擬節點的概念。在這些系統中，需要考慮綜合考慮數據分布方式和數據副本，當引入數據副本之后，一致性hash方式也需要做相應的調整，可以參加cassandra的相關文檔。

3. range based

簡單來說，就是按照關鍵值劃分成不同的區間，每個物理節點負責一個或者多個區間。其實這種方式跟一致性hash有點像，可以理解為物理節點在hash環上的位置是動態變化的。

還是以上面的數據舉例，三個節點的數據區間分別是N0（0,200］，N1（200,500］，N2（500,1000］。那么數據分布如下：

圖 5

注意，區間的大小不是固定的，每個數據區間的數據量與區間的大小也是沒有關系的。比如說，一部分數據非常集中，那么區間大小應該是比較小的，即以數據量的大小為片段標準。

在實際工程中，一個節點往往負責多個區間，每個區間成為一個塊（chunk、block），每個塊有一個閾值，當達到這個閾值之后就會分裂成兩個塊。這樣做的目的在于當有節點加入的時候，可以快速達到均衡的目的。

不知道大家有沒有發現，如果一個節點負責的數據只有一個區間，range based與沒有虛擬節點概念的一致性hash很類似；如果一個節點負責多個區間，range based與有虛擬節點概念的一致性hash很類似。

range based的元數據管理相對復雜一些，需要記錄每個節點的數據區間范圍，特別單個節點對于多個區間的情況。而且，在數據可修改的情況下，如果塊進行分裂，那么元數據中的區間信息也需要同步修改。

range based這種數據分片方式應用得非常廣泛，比如MongoDB、PostgreSQL、 HDFS。

4. 小結

在這里對三種分片方式（應該是四種，有沒有virtual node的一致性hash算兩種）進行簡單總結，主要是針對提出的幾個問題：

上面的數據動態均衡，指的是本章內容開頭提出的第四個問題，即如果某節點數據量變大，能否以及如何將部分數據遷移到其他負載較小的節點。

分片特征值的選擇

上面的三種方式都提到了對數據的分片是基于關鍵值、特征值的。這個特征值在不同的系統中有不同的叫法。

比如：

• MongoDB中的sharding key：https://docs.mongodb.com/manual/core/sharding-shard-key/
• Oracle中的Partition Key：https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

不管怎么樣，這個特征值的選擇都是非常非常重要的。

1. 怎么選擇特征值

那么怎么選擇這個特征值，《Distributed systems for fun and profit》給出了言簡意賅的標準：

參考鏈接：

http://book.mixu.net/distsys/intro.html

based on what you think the primary access pattern will be

大概翻譯為：基于最常用的訪問模式。

訪問時包括對數據的增刪改查的。比如上面的列子，我們選擇“id”作為分片的依據，那么就是默認對的數據增刪改查都是通過“id”字段來進行的。

如果在應用中，大量的數據操作都是通過這個特征值進行，那么數據分片就能提供兩個額外的好處：

• 提升性能和并發，操作被分發到不同的分片，相互獨立；
• 提升系統的可用性，即使部分分片不能用，其他分片不會受到影響。

如果大量操作并沒有使用到特征值，那么就很麻煩了。比如在本文的例子中，如果用name去查詢，而元數據記錄的是如何根據按照id映射數據位置，那就尷尬了，需要到多有分片都去查一下，然后再做一個聚合。

另外一個問題，如果以單個字段為特征值（如id），那么不管按照什么分布方式，在多條數據擁有相同的特征值（如id）的情況下，這些數據一定都會分布到同一個節點上。

在這種情況下有兩個問題，一是不能達到節點間數據的均衡，二是如果數據超過了單個節點的存儲能力怎么辦？關鍵在于，即使按照分布式系統解決問題的常規辦法——增加節點——也是于事無補的。

在這個時候，單個字段做特征值就不行了，可能得再增加一個字段作為“聯合特征值”，類似數據庫中的聯合索引。

比如，數據是用戶的操作日志，可以使用id和時間戳一起作為hash函數的輸入，然后算出特征值；但在這種情況下，如果還想以id為查詢關鍵字來查詢，那就得遍歷所有節點了。

所以說沒有最優的設計，只有最符合應用需求的設計。

2. 重要性在于？對數據操作的影響？

下面以MongoDB中的sharding key為例，解釋特征值選擇的重要性以及對數據操作的影響。如果有數據庫操作基礎，即使沒有使用過MongoDB，閱讀下面的內容應該也沒有問題。

以MongoDB sharding key為例：

在我的工作場景中，除了聯合查詢（join）和事務，MongoDB的使用和MySQL還是比較相似的，特別是基本的CRUD操作、數據庫索引。MongoDB中，每一個分片成為一個shard，分片的特征值成為sharding key，每個數據稱之為一個document。

選擇適合的字段作為shardingkey很重要，為什么：

前面也提到，如果使用非sharding key去訪問數據，那么元數據服務器，或者元數據緩存服務器，是沒法知道對應的數據在哪一個shard上的，那么該訪問就得發送到所有的shard，得到所有shard的結果之后再做聚合。

在MongoDB中，由mongos（緩存有元數據信息）做數據聚合。

對于數據讀取（R：read or retrieve），通過同一個字段獲取到多個數據，是沒有問題的，只是效率比較低而已；對于數據更新，如果只能更新一個數據，那么在哪一個shard上更新似乎都不對，這個時候，MongoDB是拒絕的。對應到MongoDB（MongoDD3.0）的命令包括但不限于：

• findandmodify：這個命令只能更新一個document，因此查詢部分必須包含sharding key。

When using findAndModify in a sharded environment, the query must contain the shard key for all operations against the shard cluster for the sharded collections.

• update：這個命令有一個參數multi，默認是false，即只能更新一個document，此時查詢部分必須包含sharding key。

All update() operations for a sharded collection that specify the multi: false option must include theshard key or the _id field in the query specification.

• remove：有一個參數JustOne，如果為True，只能刪除一個document，也必須使用sharidng key。

另外，熟悉SQL的同學都知道，在數據中索引中有unique index（唯一索引），即保證這個字段的值在table中是唯一的。MongoDB中，也可以建立unique index，但是在sharded cluster環境下，只能對sharding key創建unique index。道理也很簡單，如果unique index不是sharidng key，那么插入的時候就得去所有shard上查看，而且還得加鎖。

分片到shard上的數據不均：

接下來，討論分片到shard上的數據不均的問題。如果一段時間內shardkey過于集中（比如按時間增長），那么數據只往一個shard寫入，導致無法平衡集群壓力。

MongoDB為我們提供了：

• range partition：
  https://docs.mongodb.com/manual/core/ranged-sharding/
• hash partition：
  https://docs.mongodb.com/manual/core/hashed-sharding/

它們跟上面提到的分片方式hash方式、ranged based不是一回事兒，而是指對sharding key處理。MongoDB一定是ranged base分片方式，docuemnt中如是說：

MongoDB partitions data in the collection using ranges of shard key values. Each range defines a non-overlapping range of shard key values and is associated with a chunk.

參考鏈接：

https://docs.mongodb.com/manual/core/sharding-shard-key/

那么什么是“range partition”和“hash partition”？官網的一張圖很好說明了二者的區別：

圖 6

圖 7

圖6是range partition，圖7是hash partition。range partition就是使用字段本身作為分片的邊界，比如上圖的x；而hash partition會將字段重新hash到一個更大、更離散的值域區間。

hash partition的最大好處在于保證數據在各個節點上均勻分布（這里的均勻指的是在寫入的時候就均勻，而不是通過MongoDB的balancing功能）。比如MongoDB中默認的_id是objectid，objectid是一個12個字節的BSON類型，前4個字節是機器的時間戳，那么如果在同一時間大量創建以ObjectId為_id的數據會分配到同一個shard上，此時若將_id設置為hash index和hash sharding key，就不會有這個問題。

當然，hash partition相比range partition也有一個很大的缺點，就是范圍查詢的時候效率低，因此到底選用hash partition還是range partition還得根據應用場景來具體討論。

最后得知道，sharding key一但選定，就無法修改。如果應用必須要修改sharidng key，那么只能將數據導出，新建數據庫并創建新的sharding key，最后導入數據。

元數據服務器

在上面討論的三種數據分片分式中，或多或少都會記錄一些元數據：數據與節點的映射關系、節點狀態等等。我們稱記錄元數據的服務器為元數據服務器（metaserver），不同的系統叫法不一樣，比如master、configserver、namenode等。

元數據服務器就像人類的大腦，一只手不能用了還沒忍受，大腦不工作整個人就癱瘓了。因此，元數據服務器的高性能、高可用，要達到這兩個目標，元數據服務器就得高可擴展——以此應對元數據的增長。

元數據的高可用要求元數據服務器不能成為故障單點（single point of failure），因此需要元數據服務器有多個備份，并且能夠在故障的時候迅速切換。

有多個備份，那么問題就來了，怎么保證多個備份的數據一致性？

多個副本的一致性、可用性是CAP理論討論的范疇，這里簡單介紹兩種方案：

• 方案一：主從同步，首先選出主服務器，只有主服務器提供對外服務，主服務器將元數據的變革信息以日志的方式持久化到共享存儲（例如nfs），然后從服務器從共享存儲讀取日志并應用，達到與主服務器一致的狀態，如果主服務器被檢測到故障（比如通過心跳），那么會重新選出新的主服務器。
• 方案二：通過分布式一致性協議來達到多個副本件的一致，比如大名鼎鼎的Paxos協議以及工程中使用較多的Paxos的特化版本——Raft協議，協議可以實現所有備份均可以提供對外服務，并且保證強一致性。

1. HDFS元數據

HDFS中，元數據服務器被稱之為namenode。在hdfs1.0之前，namenode還是單點，一旦namenode掛掉，整個系統就無法工作。在hdfs2.0，解決了namenode的單點問題。

圖 8

上圖中NN即NameNode，DN即DataNode（即實際存儲數據的節點）。從圖中可以看到，兩臺NameNode形成互備，一臺處于Active狀態，為主NameNode；另外一臺處于Standby狀態，為備NameNode，只有主NameNode才能對外提供讀寫服務。

Active NN與standby NN之間的數據同步通過共享存儲實現，共享存儲系統保證了Namenode的高可用。為了保證元數據的強一致性，在進行準備切換的時候，新的Active NN必須要在確認元數據完全同步之后才能繼續對外提供服務。

另外，Namenode的狀態監控以及準備切換都是Zookeeper集群負責，在網絡分割（network partition）的情況下，有可能Zookeeper認為原來的Active NN掛掉了，選舉出新的ActiveNN，但實際上原來的Active NN還在繼續提供服務。這就導致了“雙主”或者腦裂（brain-split）現象。為了解決這個問題，提出了fencing機制，也就是想辦法把舊的Active NameNode隔離起來，使它不能正常對外提供服務。

2. MongoDB元數據

MongoDB中，元數據服務器被稱為config server。在MongoDB3.2中，已經不再建議使用三個鏡像（Mirrored）MongoDB實例作為config server，而是推薦使用復制集（replica set）作為config server，此舉的目的是增強config server的一致性，而且config sever中mongod的數目也能從3個達到replica set的上線（50個節點），從而提高了可靠性。

• 在MongoDB3.0及之前的版本中，元數據的讀寫按照下面的方式進行：

When writing to the three config servers, a coordinator dispatches the same write commands to the three config servers and collects the results. Differing results indicate an inconsistent writes to the config servers and may require manual intervention.

MongoDB的官方文檔并沒有詳細解釋這一過程，不過在stackexchange上，有人指出這個過程是兩階段提交。

• MongoDB3.2及之后的版本，使用了replica set config server，在config server中，使用了WriteConcern：Majority；ReadConcern：Majority；Read References：nearest。

3. 元數據的緩存

即使元數據服務器可以由一組物理機器組成，也保證了副本集之間的一致性問題。但是如果每次對數據的請求都經過元數據服務器的話，元數據服務器的壓力也是非常大的。很多應用場景，元數據的變化并不是很頻繁，因此可以在訪問節點上做緩存，這樣應用可以直接利用緩存數據進行數據讀寫，減輕元數據服務器壓力。

在這個環境下，緩存的元數據必須與元數據服務器上的元數據一致，緩存的元數據必須是準確的、未過時的。相反的例子是DNS之類的緩存，即使使用了過期的DNS緩存也不會有太大的問題。

怎么達到緩存的強一致性呢？比較容易想到的辦法是當metadata變化的時候立即通知所有的緩存服務器（mongos），但問題是通信有延時，不可靠。

解決不一致的問題：

一個比較常見的思路是版本號：比如網絡通信，通信協議可能會發生變化，通信雙方為了達成一致，那么可以使用版本號。在緩存一致性的問題上，也可以使用版本號，基本思路是請求的時候帶上緩存的版本號，路由到具體節點之后比較實際數據的版本號，如果版本號不一致，那么表示緩存信息過舊，此時需要從元數據服務器重新拉取元數據并緩存。在MongoDB中，mongos緩存上就是使用的這種辦法。

另外一種解決辦法，就是Lease機制 ：“An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency”，Lease機制在分布式系統中使用非常廣泛，不僅僅用于分布式緩存，在很多需要達成某種約定的地方都大顯身手，下面會對lease機制進行簡單介紹。

lease機制：

既然lease機制提出的時候是為了解決分布式存儲系統中緩存一致性的問題，那么首先來看看lease機制是怎么保證緩存的強一致性的。注意，為了方便后文描述，在本小節中，我們稱元數據服務器為服務器，緩存服務器為客戶端。

要點：

• 服務器向所有客戶端發送緩存數據的同時，頒發一個lease，lease包含一個有限期（即過期時間）；
• lease的含義是：在這個有效期內，服務器保證元數據不會發生變化；
• 客戶端在這個有效期內可以放心大膽的使用緩存的元數據，如果超過了有效期，就不能使用數據了，就得去服務器請求；
• 如果外部請求修改服務器上的元數據（元數據的修改一定在服務器上進行），那么服務器會阻塞修改請求，直到所有已頒發的lease過期，然后修改元數據，并將新的元數據和新的lease發送到客戶端；
• 如果元數據沒有發生變化，那么服務器也需要在之前已頒發的lease到期之間，重新給客戶端頒發新的lease（只有lease，沒有數據）。

在lease論文的標題中，提到了“Fault-Tolerant”，那么lease是怎么做到容錯的呢。關鍵在于，只要服務器一旦發出數據和lease，不關心客戶端是否收到數據，只要等待lease過期，就可以修改元數據；另外，lease的有效期通過過期時間（一個時間戳）來標識，因此即使從服務器到客戶端的消息延時到達、或者重復發送都是沒有關系的。

不難發現，容錯的前提是服務器與客戶端的時間要一致。

• 如果服務器的時間比客戶端的時間慢，那么客戶端收到lease之后很快就過期了，lease機制就發揮不了作用；
• 如果服務器的時間比客戶端的時間快，那么就比較危險，因為客戶端會在服務器已經開始更新元數據的時候繼續使用緩存，工程中，通常將服務器的過期時間設置得比客戶端的略大，來解決這個問題；
• 為了保持時間的一致，最好的辦法是使用NTP（Network Time Protocol）來保證時鐘同步。

lease機制的本質是頒發者授予的在某一有效期內的承諾，承諾的范圍是非常廣泛的：

• 比如上面提到的cache；
• 比如做權限控制，例如當需要做并發控制時，同一時刻只給某一個節點頒發lease，只有持有lease的節點才可以修改數據；
• 比如身份驗證，例如在primary-secondary架構中，給節點頒發lease，只有持有lease的節點才具有primary身份；
• 比如節點的狀態監測，例如在primary-secondary架構中監測primary是否正常，這個后文再詳細介紹。

工程中，lease機制也有大量的應用：

• GFS中使用lease確定Chuck的Primary副本，lease由Master節點頒發給primary副本，持有lease的副本成為primary副本。
• chubby通過paxos協議實現去中心化的選擇primary節點，然后Secondary節點向primary節點發送lease，該lease的含義是：“承諾在lease時間內，不選舉其他節點成為primary節點”。
• chubby中，primary節點也會向每個client節點頒發lease。該lease的含義是用來判斷client的死活狀態，一個client節點只有有了合法的lease，才能與chubby中的primary進行讀寫操作。

本文主要介紹了分布式系統中的分片相關問題

包括三種分布方式：hash、一致性hash、range based，以及各自的優缺點。

分片都是按照一定的特征值來進行，特征值應該從應用的使用場景來選取，并結合MongoDB展示了特征值（mongodb中的sharding key）對數據操作的影響。

分片信息（即元數據）需要專門的服務器存儲，元數據服務器是分布式存儲系統的核心，因此需要提到其可用性和可靠性，為了減輕元數據服務器的壓力，分布式系統中，會在其他節點緩存元數據，緩存的元數據又帶來了一致性的挑戰，由此引入了lease機制。

參考文獻：

1、劉杰:《分布式系統原理介紹》：

http://blog.sciencenet.cn/home.php?mod=attachment&id=31413

2、《Distributed systems for fun and profit》 ：

http://book.mixu.net/distsys/

3、《Wiki：Consistent_hashing》:

https://en.wikipedia.org/wiki/Consistent_hashing

4、《Hadoop NameNode 高可用 (High Availability) 實現解析》:

https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/

5、《CAP理論與MongoDB一致性、可用性的一些思考》:

http://www.cnblogs.com/xybaby/p/6871764.html

6、《Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency》：

http://web.eecs.umich.edu/~mos

都看到這里了，點個關注再走吧，謝謝哈

另外，國內開源社群加edpstack，數據可視化 datart，以及實時數據平臺，大數據知識系統學習，大佬交流

總結

以上是生活随笔為你收集整理的一文讲透，分布式系统的数据分片难题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。