1.redis集群
數(shù)據(jù)分片規(guī)則：
Redis Cluster使用的時(shí)hash slot算法通過采用固定節(jié)點(diǎn)數(shù)量和可配置映射節(jié)點(diǎn)，來避免取模的不靈活性和一致性哈希的部分影響备燃。
Redis Cluster將所有數(shù)據(jù)按照hash slot算法分布到16384[0-16383]個(gè)哈希槽上面，哈希槽分布在各節(jié)點(diǎn)上猛拴，各節(jié)點(diǎn)維護(hù)自己的哈希槽桩皿。
高可用
master1節(jié)點(diǎn)故障后颂郎，slave1_2被選為master薪铜。如果master2掛掉众弓，因?yàn)闆]有slave，整個(gè)集群就故障了隔箍。
副本數(shù)據(jù)一致性
redis cluster有多種復(fù)制方式，但都不保證嚴(yán)格的數(shù)據(jù)一致性脚乡。
比如：當(dāng)正好有個(gè)write command傳入給master A,A存儲(chǔ)后回應(yīng)客戶端OK(還來不及slave同步),極短的時(shí)間內(nèi)該master down,它的一個(gè)slave 被選舉為master,但是該new master根本不知道剛剛的write command的事情蜒滩。
擴(kuò)容
每個(gè)master把一部分槽和數(shù)據(jù)遷移到新的節(jié)點(diǎn)node04
2.mongodb shard集群
MongoDB分片（Sharding）技術(shù)
分片（sharding）是MongoDB用來將大型集合分割到不同服務(wù)器（或者說一個(gè)集群）上所采用的方法滨达。盡管分片起源于關(guān)系型數(shù)據(jù)庫分區(qū)，但MongoDB分片完全又是另一回事俯艰。
和MySQL分區(qū)方案相比捡遍，MongoDB的最大區(qū)別在于它幾乎能自動(dòng)完成所有事情，只要告訴MongoDB要分配數(shù)據(jù)竹握，它就能自動(dòng)維護(hù)數(shù)據(jù)在不同服務(wù)器之間的均衡画株。
2.1 MongoDB分片介紹
2.1.1 分片的目的
高數(shù)據(jù)量和吞吐量的數(shù)據(jù)庫應(yīng)用會(huì)對(duì)單機(jī)的性能造成較大壓力,大的查詢量會(huì)將單機(jī)的CPU耗盡,大的數(shù)據(jù)量對(duì)單機(jī)的存儲(chǔ)壓力較大,最終會(huì)耗盡系統(tǒng)的內(nèi)存而將壓力轉(zhuǎn)移到磁盤IO上。
為了解決這些問題,有兩個(gè)基本的方法: 垂直擴(kuò)展和水平擴(kuò)展啦辐。
垂直擴(kuò)展：增加更多的CPU和存儲(chǔ)資源來擴(kuò)展容量谓传。
水平擴(kuò)展：將數(shù)據(jù)集分布在多個(gè)服務(wù)器上。水平擴(kuò)展即分片芹关。
2.1.2 分片設(shè)計(jì)思想
分片為應(yīng)對(duì)高吞吐量與大數(shù)據(jù)量提供了方法续挟。使用分片減少了每個(gè)分片需要處理的請(qǐng)求數(shù)，因此侥衬，通過水平擴(kuò)展诗祸，集群可以提高自己的存儲(chǔ)容量和吞吐量。舉例來說轴总，當(dāng)插入一條數(shù)據(jù)時(shí)直颅，應(yīng)用只需要訪問存儲(chǔ)這條數(shù)據(jù)的分片.
使用分片減少了每個(gè)分片存儲(chǔ)的數(shù)據(jù)。
例如怀樟，如果數(shù)據(jù)庫1tb的數(shù)據(jù)集际乘，并有4個(gè)分片，然后每個(gè)分片可能僅持有256 GB的數(shù)據(jù)漂佩。如果有40個(gè)分片脖含，那么每個(gè)切分可能只有25GB的數(shù)據(jù)。
2.1.3 分片機(jī)制提供了如下三種優(yōu)勢(shì)
1.對(duì)集群進(jìn)行抽象投蝉，讓集群“不可見”
MongoDB自帶了一個(gè)叫做mongos的專有路由進(jìn)程养葵。mongos就是掌握統(tǒng)一路口的路由器，其會(huì)將客戶端發(fā)來的請(qǐng)求準(zhǔn)確無誤的路由到集群中的一個(gè)或者一組服務(wù)器上瘩缆，同時(shí)會(huì)把接收到的響應(yīng)拼裝起來發(fā)回到客戶端关拒。
2.保證集群總是可讀寫
MongoDB通過多種途徑來確保集群的可用性和可靠性。將MongoDB的分片和復(fù)制功能結(jié)合使用庸娱，在確保數(shù)據(jù)分片到多臺(tái)服務(wù)器的同時(shí)着绊，也確保了每分?jǐn)?shù)據(jù)都有相應(yīng)的備份，這樣就可以確保有服務(wù)器換掉時(shí)熟尉，其他的從庫可以立即接替壞掉的部分繼續(xù)工作归露。
3.使集群易于擴(kuò)展
當(dāng)系統(tǒng)需要更多的空間和資源的時(shí)候，MongoDB使我們可以按需方便的擴(kuò)充系統(tǒng)容量斤儿。
2.1.4 分片集群架構(gòu)
組件說明
Config Server存儲(chǔ)集群所有節(jié)點(diǎn)剧包、分片數(shù)據(jù)路由信息恐锦。默認(rèn)需要配置3個(gè)Config Server節(jié)點(diǎn)。
Mongos提供對(duì)外應(yīng)用訪問疆液，所有操作均通過mongos執(zhí)行一铅。一般有多個(gè)mongos節(jié)點(diǎn)。數(shù)據(jù)遷移和數(shù)據(jù)自動(dòng)平衡堕油。
Mongod存儲(chǔ)應(yīng)用數(shù)據(jù)記錄潘飘。一般有多個(gè)Mongod節(jié)點(diǎn)，達(dá)到數(shù)據(jù)分片目的掉缺。
分片集群的構(gòu)造
?（1）mongos ：數(shù)據(jù)路由卜录，和客戶端打交道的模塊。mongos本身沒有任何數(shù)據(jù)攀圈，他也不知道該怎么處理這數(shù)據(jù)暴凑，去找config server
（2）config server：所有存、取數(shù)據(jù)的方式赘来，所有shard節(jié)點(diǎn)的信息现喳，分片功能的一些配置信息∪剑可以理解為真實(shí)數(shù)據(jù)的元數(shù)據(jù)嗦篱。
?（3）shard：真正的數(shù)據(jù)存儲(chǔ)位置，以chunk為單位存數(shù)據(jù)幌缝。
Mongos本身并不持久化數(shù)據(jù)灸促，Sharded cluster所有的元數(shù)據(jù)都會(huì)存儲(chǔ)到Config Server，而用戶的數(shù)據(jù)會(huì)議分散存儲(chǔ)到各個(gè)shard涵卵。Mongos啟動(dòng)后浴栽，會(huì)從配置服務(wù)器加載元數(shù)據(jù)，開始提供服務(wù)轿偎，將用戶的請(qǐng)求正確路由到對(duì)應(yīng)的碎片典鸡。
Mongos的路由功能
當(dāng)數(shù)據(jù)寫入時(shí)，MongoDB Cluster根據(jù)分片鍵設(shè)計(jì)寫入數(shù)據(jù)坏晦。
當(dāng)外部語句發(fā)起數(shù)據(jù)查詢時(shí)萝玷，MongoDB根據(jù)數(shù)據(jù)分布自動(dòng)路由至指定節(jié)點(diǎn)返回?cái)?shù)據(jù)。
2.2 集群中數(shù)據(jù)分布
2.2.1 Chunk是什么
在一個(gè)shard server內(nèi)部昆婿，MongoDB還是會(huì)把數(shù)據(jù)分為chunks球碉，每個(gè)chunk代表這個(gè)shard server內(nèi)部一部分?jǐn)?shù)據(jù)。chunk的產(chǎn)生仓蛆，會(huì)有以下兩個(gè)用途：
Splitting：當(dāng)一個(gè)chunk的大小超過配置中的chunk size時(shí)睁冬，MongoDB的后臺(tái)進(jìn)程會(huì)把這個(gè)chunk切分成更小的chunk，從而避免chunk過大的情況
Balancing：在MongoDB中多律，balancer是一個(gè)后臺(tái)進(jìn)程痴突，負(fù)責(zé)chunk的遷移搂蜓，從而均衡各個(gè)shard server的負(fù)載狼荞，系統(tǒng)初始1個(gè)chunk辽装，chunk size默認(rèn)值64M,生產(chǎn)庫上選擇適合業(yè)務(wù)的chunk size是最好的。ongoDB會(huì)自動(dòng)拆分和遷移chunks相味。
分片集群的數(shù)據(jù)分布（shard節(jié)點(diǎn)）
（1）使用chunk來存儲(chǔ)數(shù)據(jù)
（2）進(jìn)群搭建完成之后拾积，默認(rèn)開啟一個(gè)chunk，大小是64M丰涉，
（3）存儲(chǔ)需求超過64M拓巧，chunk會(huì)進(jìn)行分裂，如果單位時(shí)間存儲(chǔ)需求很大一死，設(shè)置更大的chunk
（4）chunk會(huì)被自動(dòng)均衡遷移肛度。
2.2.2 chunksize的選擇
適合業(yè)務(wù)的chunksize是最好的。
chunk的分裂和遷移非常消耗IO資源投慈；chunk分裂的時(shí)機(jī)：在插入和更新承耿，讀數(shù)據(jù)不會(huì)分裂。
chunksize的選擇：
小的chunksize：數(shù)據(jù)均衡是遷移速度快伪煤，數(shù)據(jù)分布更均勻加袋。數(shù)據(jù)分裂頻繁，路由節(jié)點(diǎn)消耗更多資源抱既。大的chunksize：數(shù)據(jù)分裂少职烧。數(shù)據(jù)塊移動(dòng)集中消耗IO資源。通常100-200M
2.2.3 chunk分裂及遷移
隨著數(shù)據(jù)的增長防泵，其中的數(shù)據(jù)大小超過了配置的chunk size蚀之，默認(rèn)是64M，則這個(gè)chunk就會(huì)分裂成兩個(gè)捷泞。數(shù)據(jù)的增長會(huì)讓chunk分裂得越來越多足删。
這時(shí)候，各個(gè)shard 上的chunk數(shù)量就會(huì)不平衡肚邢。這時(shí)候壹堰，mongos中的一個(gè)組件balancer? 就會(huì)執(zhí)行自動(dòng)平衡。把chunk從chunk數(shù)量最多的shard節(jié)點(diǎn)挪動(dòng)到數(shù)量最少的節(jié)點(diǎn)骡湖。
chunkSize?對(duì)分裂及遷移的影響
MongoDB 默認(rèn)的 chunkSize 為64MB贱纠，如無特殊需求，建議保持默認(rèn)值响蕴；chunkSize 會(huì)直接影響到 chunk 分裂谆焊、遷移的行為。
chunkSize 越小浦夷，chunk 分裂及遷移越多辖试，數(shù)據(jù)分布越均衡辜王；反之，chunkSize 越大罐孝，chunk 分裂及遷移會(huì)更少呐馆，但可能導(dǎo)致數(shù)據(jù)分布不均。
chunkSize 太小莲兢，容易出現(xiàn) jumbo chunk（即shardKey 的某個(gè)取值出現(xiàn)頻率很高汹来，這些文檔只能放到一個(gè) chunk 里，無法再分裂）而無法遷移改艇；chunkSize 越大收班，則可能出現(xiàn) chunk 內(nèi)文檔數(shù)太多（chunk 內(nèi)文檔數(shù)不能超過 250000 ）而無法遷移。
chunk 自動(dòng)分裂只會(huì)在數(shù)據(jù)寫入時(shí)觸發(fā)谒兄，所以如果將 chunkSize 改小摔桦，系統(tǒng)需要一定的時(shí)間來將 chunk 分裂到指定的大小。
chunk 只會(huì)分裂承疲，不會(huì)合并邻耕，所以即使將 chunkSize 改大，現(xiàn)有的 chunk 數(shù)量不會(huì)減少纪隙，但 chunk 大小會(huì)隨著寫入不斷增長赊豌，直到達(dá)到目標(biāo)大小。
2.3 數(shù)據(jù)區(qū)分
2.3.1 分片鍵shard key
MongoDB中數(shù)據(jù)的分片是绵咱、以集合為基本單位的碘饼，集合中的數(shù)據(jù)通過片鍵（Shard key）被分成多部分。其實(shí)片鍵就是在集合中選一個(gè)鍵悲伶，用該鍵的值作為數(shù)據(jù)拆分的依據(jù)艾恼。
所以一個(gè)好的片鍵對(duì)分片至關(guān)重要。片鍵必須是一個(gè)索引麸锉，通過sh.shardCollection加會(huì)自動(dòng)創(chuàng)建索引（前提是此集合不存在的情況下）钠绍。一個(gè)自增的片鍵對(duì)寫入和數(shù)據(jù)均勻分布就不是很好，因?yàn)樽栽龅钠I總會(huì)在一個(gè)分片上寫入花沉，后續(xù)達(dá)到某個(gè)閥值可能會(huì)寫到別的分片柳爽。但是按照片鍵查詢會(huì)非常高效。
隨機(jī)片鍵對(duì)數(shù)據(jù)的均勻分布效果很好碱屁。注意盡量避免在多個(gè)分片上進(jìn)行查詢磷脯。在所有分片上查詢，mongos會(huì)對(duì)結(jié)果進(jìn)行歸并排序娩脾。
對(duì)集合進(jìn)行分片時(shí)赵誓，你需要選擇一個(gè)片鍵，片鍵是每條記錄都必須包含的，且建立了索引的單個(gè)字段或復(fù)合字段俩功，MongoDB按照片鍵將數(shù)據(jù)劃分到不同的數(shù)據(jù)塊中幻枉，并將數(shù)據(jù)塊均衡地分布到所有分片中。
為了按照片鍵劃分?jǐn)?shù)據(jù)塊诡蜓，MongoDB使用基于范圍的分片方式或者 基于哈希的分片方式熬甫。
注意：
分片鍵是不可變。
分片鍵必須有索引万牺。
分片鍵大小限制512bytes罗珍。
分片鍵用于路由查詢洽腺。
MongoDB不接受已進(jìn)行collection級(jí)分片的collection上插入無分片
鍵的文檔（也不支持空值插入）
2.3.2 以范圍為基礎(chǔ)的分片Sharded Cluster
Sharded Cluster支持將單個(gè)集合的數(shù)據(jù)分散存儲(chǔ)在多shard上脚粟，用戶可以指定根據(jù)集合內(nèi)文檔的某個(gè)字段即shard key來進(jìn)行范圍分片（range sharding）。
對(duì)于基于范圍的分片蘸朋，MongoDB按照片鍵的范圍把數(shù)據(jù)分成不同部分核无。
假設(shè)有一個(gè)數(shù)字的片鍵:想象一個(gè)從負(fù)無窮到正無窮的直線，每一個(gè)片鍵的值都在直線上畫了一個(gè)點(diǎn)藕坯。MongoDB把這條直線劃分為更短的不重疊的片段团南，并稱之為數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊包含了片鍵在一定范圍內(nèi)的數(shù)據(jù)炼彪。在使用片鍵做范圍劃分的系統(tǒng)中吐根，擁有”相近”片鍵的文檔很可能存儲(chǔ)在同一個(gè)數(shù)據(jù)塊中，因此也會(huì)存儲(chǔ)在同一個(gè)分片中辐马。
2.3.3 基于哈希的分片
分片過程中利用哈希索引作為分片的單個(gè)鍵拷橘，且哈希分片的片鍵只能使用一個(gè)字段，而基于哈希片鍵最大的好處就是保證數(shù)據(jù)在各個(gè)節(jié)點(diǎn)分布基本均勻喜爷。
對(duì)于基于哈希的分片冗疮，MongoDB計(jì)算一個(gè)字段的哈希值，并用這個(gè)哈希值來創(chuàng)建數(shù)據(jù)塊檩帐。在使用基于哈希分片的系統(tǒng)中术幔，擁有”相近”片鍵的文檔很可能不會(huì)存儲(chǔ)在同一個(gè)數(shù)據(jù)塊中，因此數(shù)據(jù)的分離性更好一些湃密。
Hash分片與范圍分片互補(bǔ)诅挑，能將文檔隨機(jī)的分散到各個(gè)chunk，充分的擴(kuò)展寫能力泛源，彌補(bǔ)了范圍分片的不足拔妥，但不能高效的服務(wù)范圍查詢，所有的范圍查詢要分發(fā)到后端所有的Shard才能找出滿足條件的文檔俩由。
2.3.4 分片鍵選擇建議
1毒嫡、遞增的sharding key
數(shù)據(jù)文件挪動(dòng)小。（優(yōu)勢(shì)）
因?yàn)閿?shù)據(jù)文件遞增，所以會(huì)把insert的寫IO永久放在最后一片上兜畸，造成最后一片的寫熱點(diǎn)努释。同時(shí)，隨著最后一片的數(shù)據(jù)量增大咬摇，將不斷的發(fā)生遷移至之前的片上伐蒂。
2、隨機(jī)的sharding key
數(shù)據(jù)分布均勻肛鹏，insert的寫IO均勻分布在多個(gè)片上逸邦。（優(yōu)勢(shì)）
大量的隨機(jī)IO，磁盤不堪重荷在扰。
3缕减、混合型key
大方向隨機(jī)遞增，小范圍隨機(jī)分布芒珠。
為了防止出現(xiàn)大量的chunk均衡遷移桥狡，可能造成的IO壓力。我們需要設(shè)置合理分片使用策略（片鍵的選擇皱卓、分片算法（range裹芝、hash））
分片注意：
?? 分片鍵是不可變、分片鍵必須有索引娜汁、分片鍵大小限制512bytes嫂易、分片鍵用于路由查詢。
?? MongoDB不接受已進(jìn)行collection級(jí)分片的collection上插入無分片鍵的文檔（也不支持空值插入）
擴(kuò)展閱讀：https://www.cnblogs.com/clsn/p/8214345.html#auto-id-32
