[toc]

集群方案

• 主從復(fù)制
• 哨兵模
• Redis-Cluster
• ShardedJedisPool
• 中間件

1.主從復(fù)制

主從復(fù)制原理：

image.png

從服務(wù)器連接主服務(wù)器埃疫，發(fā)送SYNC命令；
主服務(wù)器接收到SYNC命名后婶希，開(kāi)始執(zhí)行BGSAVE命令生成RDB文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令狗准；
主服務(wù)器BGSAVE執(zhí)行完后云矫，向所有從服務(wù)器發(fā)送快照文件善涨，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令其骄；
從服務(wù)器收到快照文件后丟棄所有舊數(shù)據(jù)恐疲，載入收到的快照腊满；
主服務(wù)器快照發(fā)送完畢后開(kāi)始向從服務(wù)器發(fā)送緩沖區(qū)中的寫命令；
從服務(wù)器完成對(duì)快照的載入培己，開(kāi)始接收命令請(qǐng)求碳蛋，并執(zhí)行來(lái)自主服務(wù)器緩沖區(qū)的寫命令；（從服務(wù)器初始化完成）
主服務(wù)器每執(zhí)行一個(gè)寫命令就會(huì)向從服務(wù)器發(fā)送相同的寫命令省咨，從服務(wù)器接收并執(zhí)行收到的寫命令（從服務(wù)器初始化完成后的操作）
主從復(fù)制優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：

支持主從復(fù)制肃弟，主機(jī)會(huì)自動(dòng)將數(shù)據(jù)同步到從機(jī)，可以進(jìn)行讀寫分離
為了分載Master的讀操作壓力，Slave服務(wù)器可以為客戶端提供只讀操作的服務(wù)笤受，寫服務(wù)仍然必須由Master來(lái)完成
Slave同樣可以接受其它Slaves的連接和同步請(qǐng)求穷缤，這樣可以有效的分載Master的同步壓力。
Master Server是以非阻塞的方式為Slaves提供服務(wù)箩兽。所以在Master-Slave同步期間津肛，客戶端仍然可以提交查詢或修改請(qǐng)求。
Slave Server同樣是以非阻塞的方式完成數(shù)據(jù)同步汗贫。在同步期間身坐，如果有客戶端提交查詢請(qǐng)求，Redis則返回同步之前的數(shù)據(jù)

缺點(diǎn)：

Redis不具備自動(dòng)容錯(cuò)和恢復(fù)功能落包，主機(jī)從機(jī)的宕機(jī)都會(huì)導(dǎo)致前端部分讀寫請(qǐng)求失敗部蛇，需要等待機(jī)器重啟或者手動(dòng)切換前端的IP才能恢復(fù)。
主機(jī)宕機(jī)咐蝇，宕機(jī)前有部分?jǐn)?shù)據(jù)未能及時(shí)同步到從機(jī)涯鲁，切換IP后還會(huì)引入數(shù)據(jù)不一致的問(wèn)題，降低了系統(tǒng)的可用性嘹害。
Redis較難支持在線擴(kuò)容撮竿，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜吮便。

2.哨兵模式

image.png

image.png

image.png

當(dāng)主服務(wù)器中斷服務(wù)后笔呀，可以將一個(gè)從服務(wù)器升級(jí)為主服務(wù)器，以便繼續(xù)提供服務(wù)髓需，但是這個(gè)過(guò)程需要人工手動(dòng)來(lái)操作许师。 為此，Redis 2.8中提供了哨兵工具來(lái)實(shí)現(xiàn)自動(dòng)化的系統(tǒng)監(jiān)控和故障恢復(fù)功能僚匆。

哨兵的作用就是監(jiān)控Redis系統(tǒng)的運(yùn)行狀況微渠。它的功能包括以下兩個(gè)。

• （1）監(jiān)控主服務(wù)器和從服務(wù)器是否正常運(yùn)行咧擂。
• （2）主服務(wù)器出現(xiàn)故障時(shí)自動(dòng)將從服務(wù)器轉(zhuǎn)換為主服務(wù)器逞盆。

哨兵的工作方式：

每個(gè)Sentinel（哨兵）進(jìn)程以每秒鐘一次的頻率向整個(gè)集群中的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinel（哨兵）進(jìn)程發(fā)送一個(gè) PING 命令松申。
如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過(guò) down-after-milliseconds 選項(xiàng)所指定的值云芦， 則這個(gè)實(shí)例會(huì)被 Sentinel（哨兵）進(jìn)程標(biāo)記為主觀下線（SDOWN）
如果一個(gè)Master主服務(wù)器被標(biāo)記為主觀下線（SDOWN），則正在監(jiān)視這個(gè)Master主服務(wù)器的所有 Sentinel（哨兵）進(jìn)程要以每秒一次的頻率確認(rèn)Master主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)
當(dāng)有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master主服務(wù)器進(jìn)入了主觀下線狀態(tài)（SDOWN）贸桶， 則Master主服務(wù)器會(huì)被標(biāo)記為客觀下線（ODOWN）
在一般情況下舅逸， 每個(gè) Sentinel（哨兵）進(jìn)程會(huì)以每 10 秒一次的頻率向集群中的所有Master主服務(wù)器、Slave從服務(wù)器發(fā)送 INFO 命令皇筛。
當(dāng)Master主服務(wù)器被 Sentinel（哨兵）進(jìn)程標(biāo)記為客觀下線（ODOWN）時(shí)琉历，Sentinel（哨兵）進(jìn)程向下線的 Master主服務(wù)器的所有 Slave從服務(wù)器發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次。
若沒(méi)有足夠數(shù)量的 Sentinel（哨兵）進(jìn)程同意 Master主服務(wù)器下線， Master主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除旗笔。若 Master主服務(wù)器重新向 Sentinel（哨兵）進(jìn)程發(fā)送 PING 命令返回有效回復(fù)彪置，Master主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。
哨兵模式的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

哨兵模式是基于主從模式的换团，所有主從的優(yōu)點(diǎn)悉稠，哨兵模式都具有。
主從可以自動(dòng)切換艘包，系統(tǒng)更健壯的猛，可用性更高。

缺點(diǎn)：

Redis較難支持在線擴(kuò)容想虎，在集群容量達(dá)到上限時(shí)在線擴(kuò)容會(huì)變得很復(fù)雜卦尊。

3.Redis-Cluster集群

image.png

redis的哨兵模式基本已經(jīng)可以實(shí)現(xiàn)高可用，讀寫分離 舌厨，但是在這種模式下每臺(tái)redis服務(wù)器都存儲(chǔ)相同的數(shù)據(jù)岂却，很浪費(fèi)內(nèi)存，所以在redis3.0上加入了cluster模式裙椭，實(shí)現(xiàn)的redis的分布式存儲(chǔ)躏哩，也就是說(shuō)每臺(tái)redis節(jié)點(diǎn)上存儲(chǔ)不同的內(nèi)容。

Redis-Cluster采用無(wú)中心結(jié)構(gòu),它的特點(diǎn)如下：

所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬揉燃。

節(jié)點(diǎn)的fail是通過(guò)集群中超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效扫尺。

客戶端與redis節(jié)點(diǎn)直連,不需要中間代理層.客戶端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

工作方式：

在redis的每一個(gè)節(jié)點(diǎn)上炊汤，都有這么兩個(gè)東西正驻，一個(gè)是插槽（slot），它的的取值范圍是：0-16383抢腐。還有一個(gè)就是cluster姑曙，可以理解為是一個(gè)集群管理的插件。當(dāng)我們的存取的key到達(dá)的時(shí)候迈倍，redis會(huì)根據(jù)crc16的算法得出一個(gè)結(jié)果伤靠，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0-16383 之間的哈希槽啼染，通過(guò)這個(gè)值宴合，去找到對(duì)應(yīng)的插槽所對(duì)應(yīng)的節(jié)點(diǎn)，然后直接自動(dòng)跳轉(zhuǎn)到這個(gè)對(duì)應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作提完。

為了保證高可用形纺，redis-cluster集群引入了主從模式，一個(gè)主節(jié)點(diǎn)對(duì)應(yīng)一個(gè)或者多個(gè)從節(jié)點(diǎn)徒欣，當(dāng)主節(jié)點(diǎn)宕機(jī)的時(shí)候逐样，就會(huì)啟用從節(jié)點(diǎn)。當(dāng)其它主節(jié)點(diǎn)ping一個(gè)主節(jié)點(diǎn)A時(shí)，如果半數(shù)以上的主節(jié)點(diǎn)與A通信超時(shí)脂新，那么認(rèn)為主節(jié)點(diǎn)A宕機(jī)了挪捕。如果主節(jié)點(diǎn)A和它的從節(jié)點(diǎn)A1都宕機(jī)了，那么該集群就無(wú)法再提供服務(wù)了争便。

Redis client Sharding

java redis客戶端驅(qū)動(dòng)jedis级零，已支持Redis Sharding功能，即ShardedJedis以及結(jié)合緩存池的ShardedJedisPool滞乙。

Jedis的Redis Sharding實(shí)現(xiàn)具有如下特點(diǎn)：

采用一致性哈希算法(consistent hashing)奏纪，將key和節(jié)點(diǎn)name同時(shí)hashing，然后進(jìn)行映射匹配斩启，采用的算法是MURMUR_HASH序调。采用一致性哈希而不是采用簡(jiǎn)單類似哈希求模映射的主要原因是當(dāng)增加或減少節(jié)點(diǎn)時(shí)，不會(huì)產(chǎn)生由于重新匹配造成的rehashing兔簇。一致性哈希只影響相鄰節(jié)點(diǎn)key分配发绢，影響量小。

2.為了避免一致性哈希只影響相鄰節(jié)點(diǎn)造成節(jié)點(diǎn)分配壓力垄琐，ShardedJedis會(huì)對(duì)每個(gè)Redis節(jié)點(diǎn)根據(jù)名字(沒(méi)有边酒，Jedis會(huì)賦予缺省名字)會(huì)虛擬化出160個(gè)虛擬節(jié)點(diǎn)進(jìn)行散列。根據(jù)權(quán)重weight狸窘，也可虛擬化出160倍數(shù)的虛擬節(jié)點(diǎn)墩朦。用虛擬節(jié)點(diǎn)做映射匹配，可以在增加或減少Redis節(jié)點(diǎn)時(shí)朦前，key在各Redis節(jié)點(diǎn)移動(dòng)再分配更均勻介杆，而不是只有相鄰節(jié)點(diǎn)受影響鹃操。

3.ShardedJedis支持keyTagPattern模式韭寸，即抽取key的一部分keyTag做sharding，這樣通過(guò)合理命名key荆隘，可以將一組相關(guān)聯(lián)的key放入同一個(gè)Redis節(jié)點(diǎn)恩伺，這在避免跨節(jié)點(diǎn)訪問(wèn)相關(guān)數(shù)據(jù)時(shí)很重要。

中間件

twemproxy處于客戶端和服務(wù)器的中間椰拒，將客戶端發(fā)來(lái)的請(qǐng)求晶渠，進(jìn)行一定的處理后(如sharding)，再轉(zhuǎn)發(fā)給后端真正的Redis服務(wù)器燃观。也就是說(shuō)褒脯，客戶端不直接訪問(wèn)Redis服務(wù)器，而是通過(guò)twemproxy代理中間件間接訪問(wèn)缆毁。

參照Redis Sharding架構(gòu)番川，增加代理中間件的Redis集群架構(gòu)如下：

twemproxy中間件的內(nèi)部處理是無(wú)狀態(tài)的，它本身可以很輕松地集群，這樣可避免單點(diǎn)壓力或故障颁督。

twemproxy又叫nutcracker践啄，起源于twitter系統(tǒng)中redis/memcached集群開(kāi)發(fā)實(shí)踐，運(yùn)行效果良好沉御，后代碼奉獻(xiàn)給開(kāi)源社區(qū)屿讽。其輕量高效，采用C語(yǔ)言開(kāi)發(fā)吠裆，工程網(wǎng)址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

twemproxy后端不僅支持redis伐谈，同時(shí)也支持memcached，這是twitter系統(tǒng)具體環(huán)境造成的试疙。

由于使用了中間件衩婚，twemproxy可以通過(guò)共享與后端系統(tǒng)的連接，降低客戶端直接連接后端服務(wù)器的連接數(shù)量效斑。同時(shí)非春，它也提供sharding功能，支持后端服務(wù)器集群水平擴(kuò)展缓屠。統(tǒng)一運(yùn)維管理也帶來(lái)了方便奇昙。

當(dāng)然，也是由于使用了中間件代理敌完，相比客戶端直連服務(wù)器方式储耐，性能上會(huì)有所損耗，實(shí)測(cè)結(jié)果大約降低了20%左右