共計 5955 個字符，預(yù)計需要花費 15 分鐘才能閱讀完成。
這篇文章主要介紹了 redis 中主從復(fù)制、哨兵、集群的原理是什么的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇 redis 中主從復(fù)制、哨兵、集群的原理是什么文章都會有所收獲，下面我們一起來看看吧。
一、主從復(fù)制
1. 主從同步的用處
??通過持久化功能，redis 保證了即使在服務(wù)器重啟的情況下也不會丟失數(shù)據(jù)，因為持久化會把內(nèi)存中的數(shù)據(jù)保存到硬盤上，重啟會從硬盤上加載數(shù)據(jù)，但是由于數(shù)據(jù)是存儲在一臺服務(wù)器上的，如果這臺服務(wù)器出現(xiàn)硬盤故障等問題，也會導(dǎo)致數(shù)據(jù)丟失。為了避免單點故障，通常的做法是將數(shù)據(jù)庫復(fù)制多個副本以部署在不同的服務(wù)器上，這樣即使有一臺服務(wù)器出現(xiàn)故障，其他服務(wù)器依然可以繼續(xù)提供服務(wù)。為此，redis 提供了復(fù)制 replication 功能，可以實現(xiàn)當(dāng)一臺數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫上。
??在復(fù)制的概念中，數(shù)據(jù)庫分為兩類，一類是主數(shù)據(jù)庫 master，另一類是從數(shù)據(jù)庫 slave。主數(shù)據(jù)庫可以進(jìn)行讀寫操作，當(dāng)寫操做導(dǎo)致數(shù)據(jù)變化時自動將數(shù)據(jù)同步給從數(shù)據(jù)庫，而從數(shù)據(jù)庫一般是只讀的，并接收主數(shù)據(jù)庫同步過來的數(shù)據(jù)。一個主數(shù)據(jù)庫可以擁有多個從數(shù)據(jù)庫，而一個從數(shù)據(jù)庫只能擁有一個主數(shù)據(jù)庫。
2. 主從同步原理
2.1 原理詳解
若啟動一個 Slave 機器進(jìn)程，則它會向 Master 機器發(fā)送一個 sync_command 命令，請求同步連接。
無論是第一次連接還是重新連接，Master 機器都會啟動一個后臺進(jìn)程，將數(shù)據(jù)快照（RDB）保存到數(shù)據(jù)文件中（.rdb 文件），同時 Master 還會記錄修改數(shù)據(jù)的所有命令并緩存在數(shù)據(jù)文件中。
后臺進(jìn)程完成緩存操作之后，Master 機器就會向 Slave 機器發(fā)送數(shù)據(jù)文件，Slave 端機器將數(shù)據(jù)文件保存到硬盤上，然后將其加載到內(nèi)存中，接著 Master 機器就會將修改數(shù)據(jù)的所有操作一并發(fā)送給 Slave 端機器。若 Slave 出現(xiàn)故障導(dǎo)致宕機，則恢復(fù)正常后會自動重新連接。
Master 機器收到 Slave 端機器的連接后，將其完整的數(shù)據(jù)文件發(fā)送給 Slave 端機器，如果 Master 同時收到多個 Slave 發(fā)來的同步請求則 Master 會在后臺啟動一個進(jìn)程以保存數(shù)據(jù)文件，然后將其發(fā)送給所有的 Slave 端機器，確保所有的 Slave 端機器都正常。
RDB 做全量同步，AOF 做增量同步
2.2 理論精簡
slave - master 發(fā)送 sync command 申請同步
master 主進(jìn)程 - 調(diào)用 fork() 函數(shù) 派生 RDB 子進(jìn)程進(jìn)行持久化 - 生成 RDB 文件
將 RDB 文件推送給 slaves（完成全量同步）#增量同步：使用到了 AOF 持久化（機制：將緩存數(shù)據(jù)保存到緩沖中），所以主從節(jié)點均需要開啟 AOF
增量同步是通過 AOF 功能將緩存中的數(shù)據(jù) append（追加）到緩沖中來進(jìn)行 master 緩沖 - slave 緩沖的同步
在持續(xù)性的運行過程中，也是增量持續(xù)同步的過程 2.3 最終精簡版
slave - master 發(fā)送 sync
master 使用 RDB 生成 .rdb 文件（全量同步）發(fā)送給 slaves
master 使用 AOF 將緩沖區(qū)數(shù)據(jù)同步給 slaves 緩沖區(qū)數(shù)據(jù)（增量）二、哨兵模式
1. 哨兵的作用
哨兵的出現(xiàn)主要是解決了主從復(fù)制出現(xiàn)故障時需要人為干預(yù)的問題
哨兵模式主要功能：
集群監(jiān)控：負(fù)責(zé)監(jiān)控 redismaster 和 slave 進(jìn)程是否正常工作
消息通知：如果某個 redis 實例有故障，那么哨兵負(fù)責(zé)發(fā)送消息作為報警通知給管理員
故障轉(zhuǎn)移：如果 master node 掛掉了，會自動轉(zhuǎn)移到 slave node 上
配置中心：如果故障轉(zhuǎn)移發(fā)生了，通知 client 客戶端新的 master 地址 ??使用一個或者多個哨兵 sentinel 實例組成的系統(tǒng)，對 redis 節(jié)點進(jìn)行監(jiān)控，在主節(jié)點出現(xiàn)故障的情況下，能將從節(jié)點中的一個升級為主節(jié)點，進(jìn)行故障轉(zhuǎn)移，保證系統(tǒng)的可用性。
2. 哨兵原理
2.1 原理詳解
首先主節(jié)點的信息是配置在哨兵 sentinel 的配置文件中。
哨兵節(jié)點會和配置的主節(jié)點建立起兩條連接命令連接和訂閱連接
PS：redis 發(fā)布訂閱（pub/sub）是一種消息通信模式: 發(fā)送者（pub）發(fā)送消 息，訂閱者（sub）接收消息。
哨兵會通過命令連接每 10s 發(fā)送一次 INFO 命令，通過 INFO 命令，主節(jié)點會返回自己的 run_id 和自己的從節(jié)點信息。
哨兵會對這些從節(jié)點也建立兩條連接命令連接和訂閱連接。
哨兵通過命令連接向從節(jié)點發(fā)送 INFO 命令，獲取到他的一些信息：
run id（redis 服務(wù)器 id）
role（職能）從服務(wù)器的復(fù)制偏移量 offset
其他 通過命令連接向服務(wù)器的 sentinel:hello 頻道發(fā)送一條消息，內(nèi)容包括自己的 IP、端口、run id、配置（后續(xù)投票的時候會用到）等。
通過訂閱連接對服務(wù)器的 sentinel:hello 頻道做了監(jiān)聽，所有向該頻道發(fā)送的哨兵的消息都能被接受到。
解析監(jiān)聽到的消息，進(jìn)行分析提取，就可以知道還有那些別的哨兵服務(wù)節(jié)點也在監(jiān)聽這些主從節(jié)點了，更新結(jié)構(gòu)體將這些哨兵節(jié)點記錄下來。
向觀察到的其他的哨兵節(jié)點建立命令連接（此時沒有訂閱連接）。
2.2 原理精簡
3 個哨兵 3 個 redis
三個哨兵之間建立命令連接，周期檢測“隊友”狀態(tài)
哨兵會向 master 節(jié)點（己在配置文件中指定）發(fā)送兩條連接，分別是命令連接和訂閱連接（為了周期性獲取 master 節(jié)點的數(shù)據(jù) )
哨兵向 master 周期性發(fā)送 info 命令，master（活著的情況下）會返回 redis-cli info replication master 節(jié)點的信息 + 從節(jié)點位置
哨兵通過 master 返回的信息，再向 slaves 節(jié)點發(fā)送 info 命令，slaves 返回數(shù)據(jù)，從而哨兵集群就可以獲取到 redis 所有集群信息
哨兵會向服務(wù)器發(fā)送命令連接，建立自己的 hello 頻道，哨兵會向這個 hello 頻道建立訂閱，用于哨兵之間的消息共享
2.3 思路
3 個哨兵互相監(jiān)聽，使用 ping 互相檢測存活
3 個哨兵分別向數(shù)據(jù)節(jié)點 master 發(fā)送命令連接和訂閱連接（info 命令）獲取數(shù)據(jù)節(jié)點信息（包含主從節(jié)點）3 個哨兵再向其他從節(jié)點發(fā)送 info，用于獲取從節(jié)點詳細(xì)信息
3 個哨兵之間通過 hello 頻道進(jìn)行消息共享
3. 哨兵模式下的故障遷移
① 主觀下線
哨兵節(jié)點會每秒一次的頻率向建立了命令連接的實例發(fā)送 PING 命令，如果在 down-after-milliseconds 毫秒內(nèi)沒有做出有效響應(yīng)包括 PONG/LOADING/MASTERDOWN 以外的響應(yīng)，哨兵就會將該實例在本結(jié)構(gòu)體中的狀態(tài)標(biāo)記為 SRI_S_DOWN 主觀下線。
② 客觀下線
當(dāng)一個哨兵節(jié)點發(fā)現(xiàn)主節(jié)點處于主觀下線狀態(tài)是，會向其他的哨兵節(jié)點發(fā)出詢問，該節(jié)點是不是已經(jīng)主觀下線了。如果超過配置參數(shù) quorum 個節(jié)點認(rèn)為是主觀下線時，該哨兵節(jié)點就會將自己維護的結(jié)構(gòu)體中該主節(jié)點標(biāo)記為 SRIO DOWN 客觀下線詢問命令 SENTINEL is-master-down-by-addr。
③ master 選舉
在認(rèn)為主節(jié)點客觀下線的情況下，哨兵節(jié)點節(jié)點間會發(fā)起一次選舉，命令為 SENTINEL is-master-down-by-addr，只是 runid 這次會將自己的 runid 帶進(jìn)去，希望接受者將自己設(shè)置為主節(jié)點。如果超過半數(shù)以上的節(jié)點返回將該節(jié)點標(biāo)記為 leader 的情況下，會有該 leader 對故障進(jìn)行遷移。
④ 故障轉(zhuǎn)移
#### 在從節(jié)點中挑選出新的主節(jié)點
優(yōu)先級排序
優(yōu)先級相同時選擇 offset 最大的
### 將該節(jié)點設(shè)置成新的主節(jié)點 SLAVEOF no one, 并確保在后續(xù)的 INGO 命令時 該節(jié)點返回狀態(tài)為 master
### 將其他的從節(jié)點設(shè)置成從新的主節(jié)點復(fù)制，SLAVEOF 命令
### 將舊的主節(jié)點變成新的主節(jié)點的從節(jié)點
PS: 優(yōu)缺點
高可用，哨兵模式是基于主從模式的，所有主從模式的優(yōu)點，哨兵模式都具有有; 主從可以自動切換，系統(tǒng)更健壯，可用性更高
redis 比較難支持在線擴容，在群集容量達(dá)到上限時在線擴容會變得很復(fù)雜 三、集群
1. redis 集群的含義
主節(jié)點負(fù)責(zé)讀寫請求和集群信息的維護，從節(jié)點只進(jìn)行主節(jié)點數(shù)據(jù)和狀態(tài)信息的復(fù)制
??redis 的哨兵模式基本已經(jīng)可以實現(xiàn)高可用、讀寫分離，但是在這種模式每臺 redis 服務(wù)器都存儲相同的數(shù)據(jù)，很浪費內(nèi)存資源，所以在 redis3.0 上加入了 Cluster 群集模式，實現(xiàn)了 redis 的分布式存儲，也就是說每臺 redis 節(jié)點存儲著不同的內(nèi)容。根據(jù)官方推薦，集群部署至少要 3 臺以上的 master 節(jié)點，最好使用 3 主 3 從六個節(jié)點的模式。
??Cluster 群集由多個 redis 服務(wù)器組成的分布式網(wǎng)絡(luò)服務(wù)群集，群集之中有多個 master 主節(jié)點，每一個主節(jié)點都可讀可寫，節(jié)點之間會相互通信，兩兩相連，redis 群集無中心節(jié)點。
2. redis 集群的特點
在 redis-Cluster 群集中，可以給每個一個主節(jié)點添加從節(jié)點，主節(jié)點和從節(jié)點直接尊循主從模型的特性，當(dāng)用戶需要處理更多讀請求的時候，添加從節(jié)點可以擴展系統(tǒng)的讀性能
redis-cluster 的故障轉(zhuǎn)移：redis 群集的主機節(jié)點內(nèi)置了類似 redis sentinel 的節(jié)點故障檢測和自動故障轉(zhuǎn)移功能，當(dāng)群集中的某個主節(jié)點下線時，群集中的其他在線主節(jié)點會注意到這一點，并且對已經(jīng)下線的主節(jié)點進(jìn)行故障轉(zhuǎn)移
集群進(jìn)行故障轉(zhuǎn)移的方法和 redis sentinel 進(jìn)行故障轉(zhuǎn)移的方法基本一樣，不同的是，在集群里面，故障轉(zhuǎn)移是由集群中其他在線的主節(jié)點負(fù)責(zé)進(jìn)行的，所以群集不必另外使用 redis sentinel
四、分布式鎖
https://www.zhihu.com/question/300767410/answer/1749442787
??如果在一個分布式系統(tǒng)中，我們從數(shù)據(jù)庫中讀取一個數(shù)據(jù)，然后修改保存，這種情況很容易遇到并發(fā)問題。因為讀取和更新保存不是一個原子操作，在并發(fā)時就會導(dǎo)致數(shù)據(jù)的不正確。這種場景其實并不少見，比如電商秒殺活動，庫存數(shù)量的更新就會遇到。如果是單機應(yīng)用，直接使用本地鎖就可以避免。如果是分布式應(yīng)用，本地鎖派不上用場，這時就需要引入分布式鎖來解決。由此可見分布式鎖的目的其實很簡單，就是為了保證多臺服務(wù)器在執(zhí)行某一段代碼時保證只有一臺服務(wù)器執(zhí)行。
簡單來說：
??現(xiàn)在的業(yè)務(wù)應(yīng)用通常都是微服務(wù)架構(gòu)，這也意味著一個應(yīng)用會部署多個進(jìn)程，那么多個進(jìn)程如果需要修改數(shù)據(jù)庫中的同一行記錄時，為了避免操作亂序?qū)е聰?shù)據(jù)錯誤，此時就需要引入分布式鎖解決問題。
為了保證分布式鎖的可用性，至少要確保鎖的實現(xiàn)要同時滿足以下幾點：
互斥性。在任何時刻，保證只有一個客戶端持有鎖。
不能出現(xiàn)死鎖。如果在一個客戶端持有鎖的期間，這個客戶端崩潰了，也要保證后續(xù)的其他客戶端可以上鎖。
保證上鎖和解鎖都是同一個客戶端。
一般來說，實現(xiàn)分布式鎖的方式有以下幾種：
使用 MySQL，基于唯一索引。
使用 ZooKeeper，基于臨時有序節(jié)點。
使用 Redis，基于 setnx 命令。
對 redis 來說注意三點，對 key 的加鎖，如果請求未完成對快要過期的 key 的續(xù)期，請求完成后 key 的解鎖。防止并發(fā)環(huán)境下被讀取的一個 key 可能被多個請求修改，造成無效操作，資源浪費的情況。
五、redis 總結(jié)
redis 可以做為 mysql 的前置緩存數(shù)據(jù)庫，redis 與 mysql 對接的方式需要配置線程池，需要定義后端 mysql 的位置（IP + port +sock 文件的位置）
redis 基礎(chǔ)功能：用于內(nèi)存 / 緩存的快速存儲（讀取）
實現(xiàn)的方式：
默認(rèn)將數(shù)據(jù)存儲在內(nèi)存 / 緩存中
具有豐富的數(shù)據(jù)類型：string list hash set order set 等
重要數(shù)據(jù)持久化的功能，持久化的方式：AOF RDB單線程模式 – 速度快的原因之一：Epoll + I/O 復(fù)用（cluster 中的 slots 哈希槽可以充當(dāng)數(shù)據(jù)讀、取的索引 )
redis 中的算法：
LRU：淘汰策略
1) 緩存中的數(shù)據(jù)進(jìn)行隨機淘汰
2) 緩存中被設(shè)置了過期時間的數(shù)據(jù)進(jìn)行隨機淘汰
3) 緩存中被設(shè)置了過期時間的數(shù)據(jù)，進(jìn)行惰性刪除（僅當(dāng)訪問到的數(shù)據(jù)過期了，才會刪除）4) 當(dāng)數(shù)據(jù)持續(xù)存儲過程中內(nèi)存將滿，會在設(shè)置了過期時間的數(shù)據(jù)中進(jìn)行近期淘汰
令牌桶 + 漏桶算法：限流
Raft：選舉機制，用于選舉新的主節(jié)點 redis 緩存高熱數(shù)據(jù)的機制
高熱數(shù)據(jù)：命中次數(shù)高的數(shù)據(jù)
指定提高緩存內(nèi)數(shù)據(jù)的命中數(shù)，最直接的可以刷腳本，訪問這些數(shù)據(jù) 六、系統(tǒng)優(yōu)化
1. 單例服務(wù)器，服務(wù)器本身優(yōu)化
硬件資源選擇（系統(tǒng)五大資源）
磁盤 固態(tài)盤 SCSI（硬件磁盤陣列）
服務(wù)器內(nèi)存條選擇（本地服務(wù)器和云服務(wù)器）
CPU 核數(shù)選擇
網(wǎng)絡(luò)網(wǎng)卡（本地服務(wù)器和云服務(wù)器），需要考慮負(fù)載壓力下的網(wǎng)絡(luò)流量 QPS
服務(wù)器選型（麒麟、曉龍、浪潮英信、華為、華三、戴爾（類型：刀片、塔式、機柜））
以上需要計算費用成本，還需要考慮到該服務(wù)器上的服務(wù)在運行時消耗的性能比例（需要預(yù)留給系統(tǒng)一部分資源）
服務(wù)本身環(huán)境的選擇
操作系統(tǒng)選擇 Linux 發(fā)行版：centos ubuntu redhat server debian alphon mac SUSE（PS：虛擬化 KVM XEN FUFE）
基于操作系統(tǒng)，依賴環(huán)境。選擇最小化安裝還是指定操作系統(tǒng)版本的安裝 + 指定內(nèi)核版本。軟件是否有依賴（例如：tomcat 需要 JDK，編譯需要 gcc gcc-c++ pcre …）
軟件資源優(yōu)化 五大負(fù)載+內(nèi)核優(yōu)化（TCP 協(xié)議相關(guān)、隊列相關(guān)、路由轉(zhuǎn)發(fā)、重定向、端口、文件打開數(shù)、系統(tǒng)的軟硬限制等）
2. 單例服務(wù)器應(yīng)用服務(wù)本身優(yōu)化
以 redis 為例
首先從啟動讀取的恢復(fù)文件來看，基于 AOF 需要開啟 AOF 功能（RDB 默認(rèn)）
RDB 中 save M N 觸發(fā)周期的選擇判定，這會影響到磁盤資源的使用
AOF 中選擇合適的 syncwrite 同步寫入磁盤的策略 everysecond
使用過程中，需要考慮到的是內(nèi)存的使用量（OOM）
內(nèi)存淘汰策略：惰性淘汰+定期刪除，禁止淘汰+定期刪除。根據(jù)情況選擇合適的淘汰策略（配置文件中定義）。
持久化方向
持久化的功能在保證數(shù)據(jù)完整性的同時，依然會持續(xù)性的對磁盤產(chǎn)生存儲壓力（壓力來源于 AOF 和 RDB 生成的數(shù)據(jù)文件，AOF 和 RDB 的日志文件）。
數(shù)據(jù) / 日志文件的定期歸檔
日志文件的分割（保存在日志中心）
共享存儲 NFS GFS fastDFS
redis 主進(jìn)程
可以使用兩個 redis 主進(jìn)程配合實現(xiàn)備份冗余，提高抗高并發(fā)的能力
關(guān)于“redis 中主從復(fù)制、哨兵、集群的原理是什么”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“redis 中主從復(fù)制、哨兵、集群的原理是什么”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
