Redis 持久化

Redis 為了保證效率，數(shù)據(jù)緩存在了內(nèi)存中，但是會(huì)周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件中，以保證數(shù)據(jù)的持久化?？偟哪康陌褦?shù)據(jù)保存到硬盤，有 RDB 和 AOF 兩種。

RDB 持久化方案: RDB 是一次的全量備份，快照形式是周期性直接把內(nèi)存中的數(shù)據(jù)保存到一個(gè) dump 文件中，定時(shí)保存。是 redis 默認(rèn)的存儲(chǔ)方式，推薦使用。

• 優(yōu)點(diǎn): 性能消耗的比較小，速度快

• 缺點(diǎn): 容易丟失數(shù)據(jù)

AOF 持久化方案：把所有的對(duì) Redis 的服務(wù)器進(jìn)行修改的命令都存到一個(gè)文件里，是命令的集合。

• 優(yōu)點(diǎn): 不容易丟失數(shù)據(jù)

• 缺點(diǎn): 性能差，給客戶的體驗(yàn)度不好

當(dāng) Redis 重啟時(shí)會(huì)優(yōu)先使用 AOF 文件來(lái)還原數(shù)據(jù)集，因?yàn)?AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。甚至可以關(guān)閉持久化功能，讓數(shù)據(jù)只在服務(wù)器運(yùn)行時(shí)存儲(chǔ)。

RDB 持久化

RDB 是默認(rèn)的持久化方案：推薦使用的。Redis 生成二進(jìn)制壓縮的快照文件 xxx.rdb 保存到磁盤。

RDB 工作原理：當(dāng) Redis 需要做持久化時(shí)，Redis 會(huì) fork 一個(gè)子進(jìn)程，子進(jìn)程將數(shù)據(jù)寫到磁盤上一個(gè)臨時(shí) RDB文件中。當(dāng)子進(jìn)程完成寫臨時(shí)文件后，將原來(lái)的 RDB 替換掉，這樣的好處是可以 copy-on-write。

定時(shí)生成 RDB 快照非常便于進(jìn)行數(shù)據(jù)庫(kù)備份，并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度快。Redis4.0支持同時(shí)開啟 RDB 和 AOF，系統(tǒng)重啟后，Redis 會(huì)優(yōu)先使用 AOF 來(lái)恢復(fù)數(shù)據(jù)，這樣丟失的數(shù)據(jù)會(huì)最少。

需要查看配置文件，滿足三個(gè)條件中一個(gè)觸發(fā)生成快照 rdb 文件?？梢耘渲梅峡煺沼|發(fā)條件，默認(rèn)的是 1 分鐘內(nèi)改動(dòng) 1 萬(wàn)次，或者 5 分鐘改動(dòng) 10 次，或者是 15 分鐘改動(dòng)一次

save 900 1

save 300 10

save 60 10000

啟動(dòng)服務(wù)器的時(shí)候需要通過(guò)命令行啟動(dòng)，進(jìn)入 reids 的安裝目錄 redis-server.exe redis.conf

save 命令：save 時(shí)只管保存，其他不管，全部阻塞

bgsave 命令：redis 會(huì)在后臺(tái)進(jìn)行快照操作，快照操作的同時(shí)還可以響應(yīng)客戶端的請(qǐng)求，可以通過(guò) lastsave 命令獲取最后一次成功執(zhí)行快照的時(shí)間。

AOF 持久化

AOF 日志存儲(chǔ)的是 redis 服務(wù)器的順序指令序列，即對(duì)內(nèi)存中數(shù)據(jù)進(jìn)行修改的指令記錄。當(dāng) redis 收到客戶端修改指令后，先進(jìn)行參數(shù)校驗(yàn)，如果校驗(yàn)通過(guò)，把該指令存儲(chǔ)到 AOF 日志文件中，也就是先存到磁盤，然后再執(zhí)行該修改指令。當(dāng) redis 宕機(jī)后重啟后，可以讀取該 AOF 文件中的指令，進(jìn)行數(shù)據(jù)恢復(fù)，恢復(fù)的過(guò)程就是把記錄的指令再順序執(zhí)行一次，這樣就可以恢復(fù)到宕機(jī)之前的狀態(tài)。

打開 AOF 配置 redis.conf 中的 appendonly yes 就可以打開 AOF 功能，例如 appendfsync no 當(dāng)設(shè)置 appendfsync為 no 的時(shí)候，Redis 不會(huì)主動(dòng)調(diào)用 fsync 去將 AOF 日志內(nèi)容同步到磁盤，所以這一切就完全依賴于操作系統(tǒng)的調(diào)試了。對(duì)大多數(shù) Linux 操作系統(tǒng)，是每 30 秒進(jìn)行一次 fsync，將緩沖區(qū)中的數(shù)據(jù)寫到磁盤上。

appendfsync everysec 當(dāng)設(shè)置 appendfsync 為 everysec 的時(shí)候，Redis 會(huì)默認(rèn)每隔一秒進(jìn)行一次 fsync 調(diào)用，將緩沖區(qū)中的數(shù)據(jù)寫到磁盤。但是當(dāng)這一次的 fsync 調(diào)用時(shí)長(zhǎng)超過(guò) 1 秒時(shí)。Redis 會(huì)采取延遲 fsync 的策略，再等一秒鐘。也就是在兩秒后再進(jìn)行 fsync，這一次的 fsync 就不管會(huì)執(zhí)行多長(zhǎng)時(shí)間都會(huì)進(jìn)行。這時(shí)候由于在fsync 時(shí)文件描述符會(huì)被阻塞，所以當(dāng)前的寫操作就會(huì)阻塞。

在絕大多數(shù)情況下，Redis 會(huì)每隔一秒進(jìn)行一次 fsync。在最壞的情況下，兩秒鐘會(huì)進(jìn)行一次 fsync 操作。這一操作在大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)中被稱為 group commit，就是組合多次寫操作的數(shù)據(jù)，一次性將日志寫到磁盤。

appendfsync always 每一次寫操作都會(huì)調(diào)用一次 fsync，這時(shí)數(shù)據(jù)是最安全的，當(dāng)然由于每次都會(huì)執(zhí)行 fsync，所以其性能也會(huì)受到影響

AOF 重寫

因?yàn)?AOF 持久化是通過(guò)保存被執(zhí)行的寫命令來(lái)記錄數(shù)據(jù)庫(kù)狀態(tài)的，那么就會(huì)涉及到很多無(wú)用的命令，如 set a b 和 set a c 以及 set a d，其實(shí)就最后一條有意義。

Redis 會(huì) fork 一個(gè)進(jìn)程來(lái)讀取現(xiàn)在 redis 生成的 AOF 文件，然后在內(nèi)存中去除冗余命令，在此過(guò)程中不會(huì)影響原來(lái) AOF 文件的繼續(xù)寫入，如果有新的命令，會(huì)緩存在重寫緩沖中，當(dāng)重寫完全結(jié)束后會(huì)替換掉原來(lái)的 AOF文件

重寫觸發(fā)條件：手動(dòng)命令 BGREWRITEAOF 和配置自動(dòng)調(diào)用

RDB 與 AOF 的選擇

宕機(jī)后會(huì)優(yōu)先加載 AOF 文件。RDB 保存的數(shù)據(jù)，AOF 保存的命令，RDB 文件比 AOF 小。恢復(fù)速度 RDB 小，更快。RDB 一次寫入的數(shù)據(jù)較多，時(shí)間間隔會(huì)比 AOF 長(zhǎng)，出現(xiàn)宕機(jī)丟失的數(shù)據(jù)會(huì)更多各有優(yōu)劣，如果能綜合就好了，所幸的是在 redis4.0 后，通過(guò)配置 aof-use-rdb-preamble 就可以開啟兩者混合持久化，取長(zhǎng)補(bǔ)短。

單機(jī)性能建議

因?yàn)?RDB 文件只用作后備用途，只要 15 分鐘備份一次就夠了，只保留 save 900 1 這條規(guī)則。

如果 Enable AOF，好處是在最惡劣情況下也只會(huì)丟失不超過(guò)兩秒數(shù)據(jù)，啟動(dòng)腳本較簡(jiǎn)單只 load 自己的 AOF 文件就可以了。 代價(jià)一是帶來(lái)了持續(xù)的 IO，二是 AOF rewrite 的最后將 rewrite 過(guò)程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應(yīng)該盡量減少 AOF rewrite 的頻率，AOF 重寫的基礎(chǔ)大小默認(rèn)值 64M 太小了，可以設(shè)到 5G 以上。 默認(rèn)超過(guò)原大小 100%大小時(shí)重寫可以改到適當(dāng)?shù)臄?shù)值。

混合持久化

Redis4.0 后大部分的使用場(chǎng)景都不會(huì)單獨(dú)使用 RDB 或者 AOF 來(lái)做持久化機(jī)制，而是兼顧二者的優(yōu)勢(shì)混合使用。

其原因是 RDB 雖然快，但是會(huì)丟失比較多的數(shù)據(jù)，不能保證數(shù)據(jù)完整性；AOF 雖然能盡可能保證數(shù)據(jù)完整性，但是性能確實(shí)是一個(gè)詬病，比如重放恢復(fù)數(shù)據(jù)。

混合持久化通過(guò) aof-use-rdb-preamble yes 開啟，Redis 4.0 以上版本默認(rèn)開啟

推薦是 AOF 和 RDB 兩者均開啟

如果對(duì)數(shù)據(jù)不敏感，可以選單獨(dú)用 RDB

不建議單獨(dú)用 AOF，因?yàn)榭赡軙?huì)出現(xiàn) Bug

如果只是做純內(nèi)存緩存，可以都不用

Redis 事務(wù)

事務(wù)是指一個(gè)完整的動(dòng)作，要么全部執(zhí)行，要么什么也沒(méi)有做。redis 事務(wù)相關(guān)的四個(gè) redis 指令，即 multi、exec、discard、watch。這四個(gè)指令構(gòu)成了 redis 事務(wù)處理的基礎(chǔ)。

1、multi 用來(lái)組裝一個(gè)事務(wù)；

2、exec 用來(lái)執(zhí)行一個(gè)事務(wù)；

3、discard 用來(lái)取消一個(gè)事務(wù)；

4、watch 用來(lái)監(jiān)視一些 key，一旦這些 key 在事務(wù)執(zhí)行之前被改變，則取消事務(wù)的執(zhí)行。

redis> multi

redis> INCR id

redis> INCR id

redis> exec

用 multi 組裝事務(wù)時(shí)，每一個(gè)命令都會(huì)進(jìn)入內(nèi)存中緩存起來(lái)，QUEUED 表示緩存成功，在 exec 時(shí)這些被 QUEUED的命令都會(huì)被組裝成一個(gè)事務(wù)來(lái)執(zhí)行。

對(duì)于事務(wù)的執(zhí)行來(lái)說(shuō)，如果 redis 開啟了 AOF 持久化的話，那么一旦事務(wù)被成功執(zhí)行，事務(wù)中的命令就會(huì)通過(guò)write 命令一次性寫到磁盤中去，如果在向磁盤中寫的過(guò)程中恰好出現(xiàn)斷電、硬件故障等問(wèn)題，那么就可能出現(xiàn)只有部分命令進(jìn)行了 AOF 持久化，這時(shí) AOF 文件就會(huì)出現(xiàn)不完整的情況，這時(shí)可以使用 redis-check-aof 工具來(lái)修復(fù)這一問(wèn)題，這個(gè)工具會(huì)將 AOF 文件中不完整的信息移除，確保 AOF 文件完整可用。

遇到的兩類錯(cuò)誤有調(diào)用 EXEC 之前的錯(cuò)誤和調(diào)用 EXEC 之后的錯(cuò)誤。

• 調(diào)用 EXEC 之前的錯(cuò)誤是有可能是由于語(yǔ)法有誤導(dǎo)致的，也可能時(shí)由于內(nèi)存不足導(dǎo)致的。只要出現(xiàn)某個(gè)命令無(wú)法成功寫入緩沖隊(duì)列的情況，redis 都會(huì)進(jìn)行記錄，在客戶端調(diào)用 EXEC 時(shí)，redis2.6.5 版本之后會(huì)拒絕執(zhí)行這一事務(wù)。在 2.6.5 之前的版本中 redis 會(huì)忽略那些入隊(duì)失敗的命令，只執(zhí)行那些入隊(duì)成功的命令。

• 對(duì)于調(diào)用 EXEC 后的錯(cuò)誤 redis 則采取了完全不同的策略，即 redis 不會(huì)理睬這些錯(cuò)誤，而是繼續(xù)向下執(zhí)行事務(wù)中的其他命令。這是因?yàn)閷?duì)于應(yīng)用層面的錯(cuò)誤，并不是 redis 自身需要考慮和處理的問(wèn)題，所以一個(gè)事務(wù)中如果某一條命令執(zhí)行失敗，并不會(huì)影響接下來(lái)的其他命令的執(zhí)行。

127.0.0.1:6379> set age 23

127.0.0.1:6379> watch age //開始監(jiān)視 age

127.0.0.1:6379> set age 24 //在 EXEC 之前，age 的值被修改了

127.0.0.1:6379> multi

127.0.0.1:6379> set age 25

127.0.0.1:6379> get age

127.0.0.1:6379> exec //觸發(fā) EXEC，返回 nil

指令 watch 可以實(shí)現(xiàn)類似于樂(lè)觀鎖的效果，即 CAS。watch 本身的作用是監(jiān)視 key 是否被改動(dòng)過(guò)，而且支持同時(shí)監(jiān)視多個(gè) key，只要還沒(méi)真正觸發(fā)事務(wù)，watch 都會(huì)盡職盡責(zé)的監(jiān)視，一旦發(fā)現(xiàn)某個(gè) key 被修改了，在執(zhí)行exec 時(shí)就會(huì)返回 nil，表示事務(wù)無(wú)法觸發(fā)。

如果在 WATCH 執(zhí)行之后，EXEC 執(zhí)行之前，有其他客戶端修改了 key 值，那么當(dāng)前客戶端的事務(wù)就會(huì)失敗。 程序需要做的， 就是不斷重試這個(gè)操作， 直到?jīng)]有發(fā)生碰撞為止。這種形式的鎖被稱作樂(lè)觀鎖， 它是一種非常強(qiáng)大的鎖機(jī)制。 并且因?yàn)榇蠖鄶?shù)情況下， 不同的客戶端會(huì)訪問(wèn)不同的鍵， 碰撞的情況一般都很少， 所以通常并不需要進(jìn)行重試。

Redis 集群

Redis 單節(jié)點(diǎn)存在單點(diǎn)故障問(wèn)題，為了解決單點(diǎn)問(wèn)題，一般都需要對(duì) Redis 配置從節(jié)點(diǎn)，然后使用哨兵來(lái)監(jiān)聽主節(jié)點(diǎn)的存活狀態(tài)，如果主節(jié)點(diǎn)掛掉，從節(jié)點(diǎn)能繼續(xù)提供緩存功能，主從配置結(jié)合哨兵模式能解決單點(diǎn)故障問(wèn)題，提高 Redis 可用性。從節(jié)點(diǎn)僅提供讀操作，主節(jié)點(diǎn)提供寫操作。對(duì)于讀多寫少的狀況，可給主節(jié)點(diǎn)配置多個(gè)從節(jié)點(diǎn)，從而提高響應(yīng)效率。

redis 主從讀寫

與 mysql 相同，redis 也提供了主從的功能，更加非常簡(jiǎn)單。Mysql 的一主多從不能達(dá)到主高可用，只能提高并發(fā)，高可用不能直接依賴于 mysql 主從復(fù)制，需要依賴于集群；redis 的主從通過(guò)哨兵機(jī)制可以達(dá)到高可用

• 高并發(fā)：單位時(shí)間內(nèi)可以接收的請(qǐng)求數(shù)量

• 高可用：服務(wù)器的服務(wù)質(zhì)量

應(yīng)用場(chǎng)景：

1、在生產(chǎn)中難以避免單臺(tái) redis 出現(xiàn)故障，保證高可用可以用主從

2、單臺(tái) redis 官網(wǎng)說(shuō)能抗住 11w 并發(fā)量，超過(guò)了 10w 高并發(fā)，就可以主從

3、QPS 瓶頸。其中 QPS 每秒處理的查詢次數(shù)、TPS 每秒處理的事務(wù)數(shù)。從請(qǐng)求到獲得數(shù)據(jù)為一個(gè)完整事務(wù)過(guò)程

注意:一個(gè) master 可以有多個(gè) slave，一個(gè) slave 只能有一個(gè) master，數(shù)據(jù)流向是單向的 master 到 slave

主從復(fù)制的作用：

1、讀寫分離：master 寫，slave 讀，提高服務(wù)器的讀寫負(fù)載能力

2、負(fù)載均衡：基于主從架構(gòu)，配合讀寫分離，由 slave 分擔(dān) master 負(fù)載，并根據(jù)需求的變化，改變 slave 的數(shù)量，通過(guò)多個(gè)從節(jié)點(diǎn)分擔(dān)數(shù)據(jù)讀取負(fù)載，大大提高 redis 服務(wù)器并發(fā)量和數(shù)據(jù)吞吐量

3、故障恢復(fù)：當(dāng) master 出現(xiàn)問(wèn)題時(shí)，由 slave 提供服務(wù)，實(shí)現(xiàn)快速的故障恢復(fù)

4、數(shù)據(jù)冗余：實(shí)現(xiàn)數(shù)據(jù)熱備份，是持久化之外的一種數(shù)據(jù)冗余方式

5、高可用基石：基于主從復(fù)制，構(gòu)建哨兵模式與集群，實(shí)現(xiàn) redis 的高可用方案。

主從復(fù)制實(shí)現(xiàn)步驟：

1、復(fù)制 redis 為 2 個(gè)，對(duì)應(yīng)的端口號(hào)分別為 6379 和 6380，通過(guò)啟動(dòng)兩個(gè)進(jìn)程以模擬兩個(gè)節(jié)點(diǎn)的情形

2、設(shè)置主從關(guān)系，例如 6379 為 master，可以通過(guò) info replication 查看節(jié)點(diǎn)角色

3、slaveof localhost 6379 將一個(gè)節(jié)點(diǎn)轉(zhuǎn)換為從節(jié)點(diǎn)。打開從節(jié)點(diǎn)配置文件 redis.conf 文件，找到#slaveof<masterip> <masterport>這個(gè)地方，添加 slaveof master 的 ip 地址 master 的端口

4、從節(jié)點(diǎn)配置文件 slave-read-only 為 yes 則從節(jié)點(diǎn)只能讀。注意如果配置從節(jié)點(diǎn)可以寫的化主節(jié)點(diǎn)不會(huì)獲取數(shù)據(jù)

5、可以在 redis-cli -p 6379 的客戶端使用 shutdown 關(guān)閉主節(jié)點(diǎn)，這時(shí)候從節(jié)點(diǎn)不會(huì)自動(dòng)轉(zhuǎn)換為主節(jié)點(diǎn)，重啟主節(jié)點(diǎn)后它仍舊是 master

主從復(fù)制實(shí)現(xiàn)原理：

主從復(fù)制過(guò)程主要可以分為 3 個(gè)階段：連接建立階段、數(shù)據(jù)同步階段、命令傳播階段

1、連接建立階段：在主從節(jié)點(diǎn)之間建立連接，為數(shù)據(jù)同步做準(zhǔn)備

2、數(shù)據(jù)同步階段：執(zhí)行數(shù)據(jù)的全量（或增量）復(fù)制（復(fù)制 RDB 文件）

3、命令傳播階段：主節(jié)點(diǎn)將已執(zhí)行的命令發(fā)送給從節(jié)點(diǎn)，從節(jié)點(diǎn)接收命令并執(zhí)行，從而實(shí)現(xiàn)主從節(jié)點(diǎn)的數(shù)據(jù)一致性

主從模式中，一個(gè)主節(jié)點(diǎn)可以有多個(gè)從節(jié)點(diǎn)。為了減少主從復(fù)制對(duì)主節(jié)點(diǎn)的性能影響，一個(gè)從節(jié)點(diǎn)可以作為另外一個(gè)從節(jié)點(diǎn)的主節(jié)點(diǎn)進(jìn)行主從復(fù)制。

不足之處：主節(jié)點(diǎn)宕機(jī)之后，需要手動(dòng)拉起從節(jié)點(diǎn)來(lái)提供業(yè)務(wù)，不能達(dá)到高可用

哨兵模式 Sentinel

Redis Sentinel 是 Redis 的高可用實(shí)現(xiàn)方案，它可以實(shí)現(xiàn)對(duì) redis 的監(jiān)控、通知和自動(dòng)故障轉(zhuǎn)移，當(dāng) redis master掛掉之后，可以自動(dòng)拉起 slave 提供業(yè)務(wù)，從而實(shí)現(xiàn) redis 的高可用。為了避免 Sentinel 本身出現(xiàn)單點(diǎn)故障，Sentinel 自己也可采用集群模式

哨兵模式的原理

Sentinel 是一種特殊的 redis 節(jié)點(diǎn)，每個(gè) sentinel 節(jié)點(diǎn)會(huì)維護(hù)與其他 redis 節(jié)點(diǎn)，包括 master、slave、sentinel的心跳。

1、當(dāng)一個(gè) sentinel 節(jié)點(diǎn)與 master 節(jié)點(diǎn)的心跳丟失時(shí)，這個(gè) sentinel 節(jié)點(diǎn)就會(huì)認(rèn)為 master 節(jié)點(diǎn)出現(xiàn)了故障，處于不可用的狀態(tài)，這種判定叫作主觀下線，即 sentinel 節(jié)點(diǎn)自己主觀認(rèn)為 master 下線了。

2、之后，這個(gè) sentinel 節(jié)點(diǎn)會(huì)與其他 sentinel 節(jié)點(diǎn)交換信息，如果發(fā)現(xiàn)認(rèn)為主節(jié)點(diǎn)發(fā)生故障的 sentinel 節(jié)點(diǎn)的個(gè)數(shù)超過(guò)了某個(gè)閾值（通常為 sentinel 節(jié)點(diǎn)總數(shù)的 1/2+1，即超過(guò)半數(shù)），則 sentinel 會(huì)認(rèn)為 master 節(jié)點(diǎn)已經(jīng)處于客觀下線的狀態(tài)，即大家都認(rèn)為 master 故障不可用了。

3、之后，sentinel 節(jié)點(diǎn)中會(huì)選舉處一個(gè) sentinel leader 來(lái)執(zhí)行 redis 主節(jié)點(diǎn)的故障轉(zhuǎn)移。

被選舉出的 Sentinel 領(lǐng)導(dǎo)者進(jìn)行故障轉(zhuǎn)移的具體步驟

1、在從節(jié)點(diǎn)列表中選出一個(gè)節(jié)點(diǎn)作為新的主節(jié)點(diǎn)

• 過(guò)濾不健康或者不滿足要求的節(jié)點(diǎn)

• 選擇 slave-priority 優(yōu)先級(jí)最高的從節(jié)點(diǎn)，如果存在則返回，不存在則繼續(xù)

• 選擇復(fù)制偏移量最大的從節(jié)點(diǎn)，如果存在則返回，不存在則繼續(xù)

• 選擇 runid 最小的從節(jié)點(diǎn)

2、Sentinel 領(lǐng)導(dǎo)者節(jié)點(diǎn)會(huì)對(duì)選出來(lái)的從節(jié)點(diǎn)執(zhí)行 slaveof no one 命令讓其成為主節(jié)點(diǎn)

3、Sentinel 領(lǐng)導(dǎo)者節(jié)點(diǎn)會(huì)向剩余的從節(jié)點(diǎn)發(fā)送命令，讓他們從新的主節(jié)點(diǎn)上復(fù)制數(shù)據(jù)

4、Sentinel 領(lǐng)導(dǎo)者會(huì)將原來(lái)的主節(jié)點(diǎn)更新為從節(jié)點(diǎn)， 并對(duì)其進(jìn)行監(jiān)控， 當(dāng)其恢復(fù)后命令它去復(fù)制新的主節(jié)點(diǎn)。

集群架構(gòu)

Redis 集群使用數(shù)據(jù)分片 sharding 而非一致性哈希 consistency hashing 來(lái)實(shí)現(xiàn)

1、一個(gè) Redis 集群包含 16384 個(gè)哈希槽 hash slot，數(shù)據(jù)庫(kù)中的每個(gè)鍵都屬于這 16384 個(gè)哈希槽的其中一個(gè)

2、集群使用公式 CRC16(key) % 16384 來(lái)計(jì)算鍵 key 屬于哪個(gè)槽， 其中 CRC16(key)語(yǔ)句用于計(jì)算鍵 key的 CRC16 校驗(yàn)和

3、集群中的每個(gè)節(jié)點(diǎn)負(fù)責(zé)處理一部分哈希槽

Redis 集群不支持那些需要同時(shí)處理多個(gè)鍵的 Redis 命令，因?yàn)閳?zhí)行這些命令需要在多個(gè) Redis 節(jié)點(diǎn)之間移動(dòng)數(shù)據(jù)， 并且在高負(fù)載的情況下， 這些命令將降低 Redis 集群的性能， 并導(dǎo)致不可預(yù)測(cè)的錯(cuò)誤。Redis 為了兼容 multi-key 操作，提供了 hash tags 操作，每個(gè) key 可以包含自定義的 tags，在存儲(chǔ)的時(shí)候根據(jù) tags 計(jì)算此 key 應(yīng)該映射到哪個(gè) node 上

1、Redis 集群通過(guò)分區(qū) partition 來(lái)提供一定程度的可用性 availability：即使集群中有一部分節(jié)點(diǎn)失效或者無(wú)法進(jìn)行通訊， 集群也可以繼續(xù)處理命令請(qǐng)求

2、Redis 集群盡可能保證數(shù)據(jù)的強(qiáng)一致性，但在特定條件下會(huì)丟失數(shù)據(jù)，原因有兩點(diǎn)：異步 replication 機(jī)制以及 network partition

3、Redis Cluster 提供了 replicas migration 機(jī)制，當(dāng) Master 節(jié)點(diǎn)發(fā)生 failover 后，集群會(huì)動(dòng)態(tài)重新分配、平衡Slaves 的分布，有效地提高了集群的可用性