為什么需要Sharded cluster？
MongoDB目前3大核心優勢：『靈活模式』+ 『高可用性』 + 『可擴展性』，通過json文檔來實現靈活模式，通過復制集（https://yq.aliyun.com/articles/64?spm=0.0.0.0.9jrPm8）來保證高可用，通過Sharded cluster來保證可擴展性。
當MongoDB復制集遇到下面的業務場景時，你就需要考慮使用Sharded cluster
●存儲容量需求超出單機磁盤容量
●活躍的數據集超出單機內存容量，導致很多請求都要從磁盤讀取數據，影響性能
●寫IOPS超出單個MongoDB節點的寫服務能力
如上圖所示，Sharding Cluster使得集合的數據可以分散到多個Shard（復制集或者單個Mongod節點）存儲，使得MongoDB具備了橫向擴展（Scale out）的能力，豐富了MongoDB的應用場景。
Sharded cluster架構
Sharded cluster由Shard、Mongos和Config server 3個組件構成。
Mongos是Sharded cluster的訪問入口，強烈建議所有的管理操作、讀寫操作都通過mongos來完成，以保證cluster多個組件處于一致的狀態。
Mongos本身并不持久化數據，Sharded cluster所有的元數據都會存儲到Config Server（下一節詳細介紹），而用戶的數據則會分散存儲到各個shard。Mongos啟動后，會從config server加載元數據，開始提供服務，將用戶的請求正確路由到對應的Shard。
數據分布策略
Sharded cluster支持將單個集合的數據分散存儲在多個shard上，用戶可以指定根據集合內文檔的某個字段即shard key來分布數據，目前主要支持2種數據分布的策略，范圍分片（Range based sharding）或hash分片（Hash based sharding）。
范圍分片
如上圖所示，集合根據x字段來分片，x的取值范圍為[minKey, maxKey]（x為整型，這里的minKey、maxKey為整型的最小值和最大值），將整個取值范圍劃分為多個chunk，每個chunk（通常配置為64MB）包含其中一小段的數據。
Chunk1包含x的取值在[minKey, -75)的所有文檔，而Chunk2包含x取值在[-75, 25)之間的所有文檔… 每個chunk的數據都存儲在同一個Shard上，每個Shard可以存儲很多個chunk，chunk存儲在哪個shard的信息會存儲在Config server種，mongos也會根據各個shard上的chunk的數量來自動做負載均衡。
范圍分片能很好的滿足『范圍查詢』的需求，比如想查詢x的值在[-30, 10]之間的所有文檔，這時mongos直接能將請求路由到Chunk2，就能查詢出所有符合條件的文檔。
范圍分片的缺點在于，如果shardkey有明顯遞增（或者遞減）趨勢，則新插入的文檔多會分布到同一個chunk，無法擴展寫的能力，比如使用_id作為shard key，而MongoDB自動生成的id高位是時間戳，是持續遞增的。
Hash分片
Hash分片是根據用戶的shard key計算hash值（64bit整型），根據hash值按照『范圍分片』的策略將文檔分布到不同的chunk。
Hash分片與范圍分片互補，能將文檔隨機的分散到各個chunk，充分的擴展寫能力，彌補了范圍分片的不足，但不能高效的服務范圍查詢，所有的范圍查詢要分發到后端所有的Shard才能找出滿足條件的文檔。
合理的選擇shard key
選擇shard key時，要根據業務的需求及『范圍分片』和『Hash分片』2種方式的優缺點合理選擇，同時還要注意shard key的取值一定要足夠多，否則會出現單個jumbo chunk，即單個chunk非常大并且無法分裂（split）；比如某集合存儲用戶的信息，按照age字段分片，而age的取值非常有限，必定會導致單個chunk非常大。
Mongos
Mongos作為Sharded cluster的訪問入口，所有的請求都由mongos來路由、分發、合并，這些動作對客戶端driver透明，用戶連接mongos就像連接mongod一樣使用。
Mongos會根據請求類型及shard key將請求路由到對應的Shard
查詢請求
●查詢請求不包含shard key，則必須將查詢分發到所有的shard，然后合并查詢結果返回給客戶端
●查詢請求包含shard key，則直接根據shard key計算出需要查詢的chunk，向對應的shard發送查詢請求
寫請求
寫操作必須包含shard key，mongos根據shard key算出文檔應該存儲到哪個chunk，然后將寫請求發送到chunk所在的shard。
更新/刪除請求
更新、刪除請求的查詢條件必須包含shard key或者_id，如果是包含shard key，則直接路由到指定的chunk，如果只包含_id，則需將請求發送至所有的shard。
其他命令請求
除增刪改查外的其他命令請求處理方式都不盡相同，有各自的處理邏輯，比如listDatabases命令，會向每個Shard及Config Server轉發listDatabases請求，然后將結果進行合并。
Config Server
config database
Config server存儲Sharded cluster的所有元數據，所有的元數據都存儲在config數據庫，3.2版本后，Config Server可部署為一個獨立的復制集，極大的方便了Sharded cluster的運維管理。
mongos> use config
switched to db config
mongos> db.getCollectionNames()
[
"shards",
"actionlog",
"chunks",
"mongos",
"collections",
"lockpings",
"settings",
"version",
"locks",
"databases",
"tags",
"changelog"
]
config.shards
config.shards集合存儲各個Shard的信息，可通過addShard、removeShard命令來動態的從Sharded cluster里增加或移除shard。如下所示，cluster目前擁有2個shard，均為復制集。
mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003")
mongos> db.addShard("mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003")
mongos> db.shards.find()
{ "_id" : "mongo-9003", "host" : "mongo-9003/10.1.72.135:9003,10.1.72.136:9003,10.1.72.137:9003" }
{ "_id" : "mongo-9004", "host" : "mongo-9004/10.1.72.135:9004,10.1.72.136:9004,10.1.72.137:9004" }
config.databases
config.databases集合存儲所有數據庫的信息，包括DB是否開啟分片，primary shard信息，對于數據庫內沒有開啟分片的集合，所有的數據都會存儲在數據庫的primary shard上。
如下所示，shtest數據庫是開啟分片的（通過enableSharding命令），primary shard為mongo-9003； 而test數據庫沒有開啟分片，primary shard為mongo-9003。
mongos> sh.enableSharding("shtest") { "ok" : 1 }
mongos> db.databases.find()
{ "_id" : "shtest", "primary" : "mongo-9003", "partitioned" : true }
{ "_id" : "test", "primary" : "mongo-9003", "partitioned" : false }
Sharded cluster在數據庫創建時，為用戶選擇當前存儲數據量最小的shard作為數據庫的primary shard，用戶也可調用movePrimary命令來改變primary shard以實現負載均衡，一旦primary shard發生改變，mongos會自動將數據遷移到的新的primary shard上。
config.colletions
數據分片是針對集合維度的，某個數據庫開啟分片功能后，如果需要讓其中的集合分片存儲，則需調用shardCollection命令來針對集合開啟分片。
如下命令，針對shtest數據里的hello集合開啟分片，使用x字段作為shard key來進行范圍分片。
mongos> sh.shardCollection("shtest.coll", {x: 1})
{ "collectionsharded" : "shtest.coll", "ok" : 1 }
mongos> db.collections.find()
{ "_id" : "shtest.coll", "lastmodEpoch" : ObjectId("57175142c34046c3b556d302"), "lastmod" : ISODate("1970-02-19T17:02:47.296Z"), "dropped" : false, "key" : { "x" : 1 }, "unique" : false }
config.chunks
集合分片開啟后，默認會創建一個新的chunk，shard key取值[minKey, maxKey]內的文檔（即所有的文檔）都會存儲到這個chunk。當使用Hash分片策略時，可以預先創建多個chunk，以減少chunk的遷移。
mongos> db.chunks.find({ns: "shtest.coll"})
{ "_id" : "shtest.coll-x_MinKey", "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9003", "lastmod" : Timestamp(1, 0), "lastmodEpoch" : ObjectId("5717530fc34046c3b556d361") }
當chunk里寫入的數據量增加到一定閾值時，會觸發chunk分裂，將一個chunk的范圍分裂為多個chunk，當各個shard上chunk數量不均衡時，會觸發chunk在shard間的遷移。如下所示，shtest.coll的一個chunk，在寫入數據后分裂成3個chunk。
mongos> use shtest
mongos> for (var i = 0; i < 10000; i++) { db.coll.insert( {x: i} ); }
mongos> use config
mongos> db.chunks.find({ns: "shtest.coll"})
{ "_id" : "shtest.coll-x_MinKey", "lastmod" : Timestamp(5, 1), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : { "$minKey" : 1 } }, "max" : { "x" : 1 }, "shard" : "mongo-9003" }
{ "_id" : "shtest.coll-x_1.0", "lastmod" : Timestamp(4, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 1 }, "max" : { "x" : 31 }, "shard" : "mongo-9003" }
{ "_id" : "shtest.coll-x_31.0", "lastmod" : Timestamp(5, 0), "lastmodEpoch" : ObjectId("5703a512a7f97d0799416e2b"), "ns" : "shtest.coll", "min" : { "x" : 31 }, "max" : { "x" : { "$maxKey" : 1 } }, "shard" : "mongo-9004" }
config.settings
config.settings集合里主要存儲sharded cluster的配置信息，比如chunk size，是否開啟balancer等
mongos> db.settings.find()
{ "_id" : "chunksize", "value" : NumberLong(64) }
{ "_id" : "balancer", "stopped" : false }
其他集合
●config.tags主要存儲sharding cluster標簽（tag）相關的你洗，以實現根據tag來分布chunk的功能；
●config.changelog主要存儲sharding cluster里的所有變更操作，比如balancer遷移chunk的動作就會記錄到changelog里；
●config.mongos存儲當前集群所有mongos的信息；
●config.locks存儲鎖相關的信息，對某個集合進行操作時，比如moveChunk，需要先獲取鎖，避免多個mongos同時遷移同一個集合的chunk。
來源：數據庫內核月報
原文：http://mysql.taobao.org/monthly/2016/05/08/
如有侵權或不周之處，敬請勞煩聯系若飛（微信：1321113940）馬上刪除，謝謝！
