這篇文章主要介紹了redis主從復制、哨兵和集群的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

創(chuàng)新互聯(lián)公司致力于互聯(lián)網(wǎng)品牌建設與網(wǎng)絡營銷，包括網(wǎng)站設計制作、網(wǎng)站設計、SEO優(yōu)化、網(wǎng)絡推廣、整站優(yōu)化營銷策劃推廣、電子商務、移動互聯(lián)網(wǎng)營銷等。創(chuàng)新互聯(lián)公司為不同類型的客戶提供良好的互聯(lián)網(wǎng)應用定制及解決方案，創(chuàng)新互聯(lián)公司核心團隊十余年專注互聯(lián)網(wǎng)開發(fā)，積累了豐富的網(wǎng)站經驗，為廣大企業(yè)客戶提供一站式企業(yè)網(wǎng)站建設服務，在網(wǎng)站建設行業(yè)內樹立了良好口碑。

一、主從復制

1. 主從同步的用處

??通過持久化功能，redis 保證了即使在服務器重啟的情況下也不會丟失數(shù)據(jù)，因為持久化會把內存中的數(shù)據(jù)保存到硬盤上，重啟會從硬盤上加載數(shù)據(jù)，但是由于數(shù)據(jù)是存儲在一臺服務器上的，如果這臺服務器出現(xiàn)硬盤故障等問題，也會導致數(shù)據(jù)丟失。為了避免單點故障，通常的做法是將數(shù)據(jù)庫復制多個副本以部署在不同的服務器上，這樣即使有一臺服務器出現(xiàn)故障，其他服務器依然可以繼續(xù)提供服務。為此，redis 提供了復制 replication 功能，可以實現(xiàn)當一臺數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動將更新的數(shù)據(jù)同步到其他數(shù)據(jù)庫上。
??在復制的概念中，數(shù)據(jù)庫分為兩類，一類是主數(shù)據(jù)庫 master，另一類是從數(shù)據(jù)庫 slave。主數(shù)據(jù)庫可以進行讀寫操作，當寫操做導致數(shù)據(jù)變化時自動將數(shù)據(jù)同步給從數(shù)據(jù)庫，而從數(shù)據(jù)庫一般是只讀的，并接收主數(shù)據(jù)庫同步過來的數(shù)據(jù)。一個主數(shù)據(jù)庫可以擁有多個從數(shù)據(jù)庫，而一個從數(shù)據(jù)庫只能擁有一個主數(shù)據(jù)庫。

2. 主從同步原理

2.1 原理詳解

• 若啟動一個 Slave 機器進程，則它會向 Master 機器發(fā)送一個 sync_command 命令，請求同步連接。

• 無論是第一次連接還是重新連接，Master 機器都會啟動一個后臺進程，將數(shù)據(jù)快照（RDB）保存到數(shù)據(jù)文件中（.rdb文件），同時 Master 還會記錄修改數(shù)據(jù)的所有命令并緩存在數(shù)據(jù)文件中。

• 后臺進程完成緩存操作之后，Master 機器就會向 Slave 機器發(fā)送數(shù)據(jù)文件，Slave 端機器將數(shù)據(jù)文件保存到硬盤上，然后將其加載到內存中，接著 Master 機器就會將修改數(shù)據(jù)的所有操作一并發(fā)送給 Slave 端機器。若 Slave 出現(xiàn)故障導致宕機，則恢復正常后會自動重新連接。

• Master 機器收到 Slave 端機器的連接后，將其完整的數(shù)據(jù)文件發(fā)送給 Slave 端機器，如果 Master 同時收到多個 Slave發(fā)來的同步請求則 Master 會在后臺啟動一個進程以保存數(shù)據(jù)文件，然后將其發(fā)送給所有的 Slave 端機器，確保所有的 Slave 端機器都正常。

RDB 做全量同步，AOF 做增量同步

2.2 理論精簡

slave -> master 發(fā)送 sync command 申請同步
master 主進程 -> 調用 fork() 函數(shù) 派生 RDB 子進程進行持久化 -> 生成 RDB 文件
將 RDB 文件推送給 slaves（完成全量同步）#增量同步：使用到了 AOF 持久化（機制：將緩存數(shù)據(jù)保存到緩沖中），所以主從節(jié)點均需要開啟 AOF增量同步是通過 AOF 功能將緩存中的數(shù)據(jù) append（追加）到緩沖中來進行 master 緩沖 -> slave 緩沖的同步
在持續(xù)性的運行過程中，也是增量持續(xù)同步的過程

2.3 最終精簡版

slave -> master 發(fā)送 syncmaster 使用 RDB 生成 .rdb 文件（全量同步）發(fā)送給 slaves
master 使用 AOF 將緩沖區(qū)數(shù)據(jù)同步給 slaves 緩沖區(qū)數(shù)據(jù)（增量）

---

二、哨兵模式

1. 哨兵的作用

哨兵的出現(xiàn)主要是解決了主從復制出現(xiàn)故障時需要人為干預的問題

哨兵模式主要功能：

集群監(jiān)控：負責監(jiān)控 redismaster 和 slave 進程是否正常工作
消息通知：如果某個 redis 實例有故障，那么哨兵負責發(fā)送消息作為報警通知給管理員
故障轉移：如果 master node 掛掉了，會自動轉移到 slave node 上
配置中心：如果故障轉移發(fā)生了，通知 client 客戶端新的 master 地址

??使用一個或者多個哨兵 sentinel 實例組成的系統(tǒng)，對 redis 節(jié)點進行監(jiān)控，在主節(jié)點出現(xiàn)故障的情況下，能將從節(jié)點中的一個升級為主節(jié)點，進行故障轉移，保證系統(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 服務器 id） 
role（職能）
從服務器的復制偏移量 offset
其他

• 通過命令連接向服務器的 sentinel:hello 頻道發(fā)送一條消息，內容包括自己的 IP、端口、run id、配置（后續(xù)投票的時候會用到）等。

• 通過訂閱連接對服務器的 sentinel:hello 頻道做了監(jiān)聽，所有向該頻道發(fā)送的哨兵的消息都能被接受到。

• 解析監(jiān)聽到的消息，進行分析提取，就可以知道還有那些別的哨兵服務節(jié)點也在監(jiān)聽這些主從節(jié)點了，更新結構體將這些哨兵節(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 所有集群信息

• 哨兵會向服務器發(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é)點詳細信息

• 3 個哨兵之間通過 hello 頻道進行消息共享

3. 哨兵模式下的故障遷移

• ① 主觀下線
  哨兵節(jié)點會每秒一次的頻率向建立了命令連接的實例發(fā)送 PING 命令，如果在 down-after-milliseconds 毫秒內沒有做出有效響應包括 PONG/LOADING/MASTERDOWN 以外的響應，哨兵就會將該實例在本結構體中的狀態(tài)標記為 SRI_S_DOWN 主觀下線。

• ② 客觀下線
  當一個哨兵節(jié)點發(fā)現(xiàn)主節(jié)點處于主觀下線狀態(tài)是，會向其他的哨兵節(jié)點發(fā)出詢問，該節(jié)點是不是已經主觀下線了。如果超過配置參數(shù) quorum 個節(jié)點認為是主觀下線時，該哨兵節(jié)點就會將自己維護的結構體中該主節(jié)點標記為 SRIO DOWN 客觀下線詢問命令 SENTINEL is-master-down-by-addr。

• ③ master 選舉
  在認為主節(jié)點客觀下線的情況下，哨兵節(jié)點節(jié)點間會發(fā)起一次選舉，命令為 SENTINEL is-master-down-by-addr ，只是 runid 這次會將自己的 runid 帶進去，希望接受者將自己設置為主節(jié)點。如果超過半數(shù)以上的節(jié)點返回將該節(jié)點標記為 leader 的情況下，會有該 leader 對故障進行遷移。

• ④ 故障轉移

####在從節(jié)點中挑選出新的主節(jié)點通訊正常
優(yōu)先級排序
優(yōu)先級相同時選擇 offset 最大的###將該節(jié)點設置成新的主節(jié)點SLAVEOF no one,并確保在后續(xù)的INGO命令時 該節(jié)點返回狀態(tài)為master ###將其他的從節(jié)點設置成從新的主節(jié)點復制，SLAVEOF命令###將舊的主節(jié)點變成新的主節(jié)點的從節(jié)點PS:優(yōu)缺點#優(yōu)點:高可用，哨兵模式是基于主從模式的，所有主從模式的優(yōu)點，哨兵模式都具有有;主從可以自動切換，系統(tǒng)更健壯，可用性更高#缺點:redis 比較難支持在線擴容，在群集容量達到上限時在線擴容會變得很復雜

---

三、集群

1. redis 集群的含義

主節(jié)點負責讀寫請求和集群信息的維護，從節(jié)點只進行主節(jié)點數(shù)據(jù)和狀態(tài)信息的復制

??redis 的哨兵模式基本已經可以實現(xiàn)高可用、讀寫分離，但是在這種模式每臺 redis 服務器都存儲相同的數(shù)據(jù)，很浪費內存資源，所以在 redis3.0 上加入了 Cluster 群集模式，實現(xiàn)了 redis 的分布式存儲，也就是說每臺 redis 節(jié)點存儲著不同的內容。根據(jù)官方推薦，集群部署至少要 3 臺以上的 master 節(jié)點，最好使用 3 主 3 從六個節(jié)點的模式。
??Cluster 群集由多個 redis 服務器組成的分布式網(wǎng)絡服務群集，群集之中有多個 master 主節(jié)點，每一個主節(jié)點都可讀可寫，節(jié)點之間會相互通信，兩兩相連，redis 群集無中心節(jié)點。

2. redis 集群的特點

• 在 redis-Cluster 群集中，可以給每個一個主節(jié)點添加從節(jié)點，主節(jié)點和從節(jié)點直接尊循主從模型的特性，當用戶需要處理更多讀請求的時候，添加從節(jié)點可以擴展系統(tǒng)的讀性能

• redis-cluster 的故障轉移：redis 群集的主機節(jié)點內置了類似 redis sentinel 的節(jié)點故障檢測和自動故障轉移功能，當群集中的某個主節(jié)點下線時，群集中的其他在線主節(jié)點會注意到這一點，并且對已經下線的主節(jié)點進行故障轉移

• 集群進行故障轉移的方法和 redis sentinel 進行故障轉移的方法基本一樣，不同的是，在集群里面，故障轉移是由集群中其他在線的主節(jié)點負責進行的，所以群集不必另外使用 redis sentinel

---

四、分布式鎖

https://www.zhihu.com/question/300767410/answer/1749442787
??如果在一個分布式系統(tǒng)中，我們從數(shù)據(jù)庫中讀取一個數(shù)據(jù)，然后修改保存，這種情況很容易遇到并發(fā)問題。因為讀取和更新保存不是一個原子操作，在并發(fā)時就會導致數(shù)據(jù)的不正確。這種場景其實并不少見，比如電商秒殺活動，庫存數(shù)量的更新就會遇到。如果是單機應用，直接使用本地鎖就可以避免。如果是分布式應用，本地鎖派不上用場，這時就需要引入分布式鎖來解決。由此可見分布式鎖的目的其實很簡單，就是為了保證多臺服務器在執(zhí)行某一段代碼時保證只有一臺服務器執(zhí)行。

簡單來說：
??現(xiàn)在的業(yè)務應用通常都是微服務架構，這也意味著一個應用會部署多個進程，那么多個進程如果需要修改數(shù)據(jù)庫中的同一行記錄時，為了避免操作亂序導致數(shù)據(jù)錯誤，此時就需要引入分布式鎖解決問題。

為了保證分布式鎖的可用性，至少要確保鎖的實現(xiàn)要同時滿足以下幾點：

• 互斥性。在任何時刻，保證只有一個客戶端持有鎖。

• 不能出現(xiàn)死鎖。如果在一個客戶端持有鎖的期間，這個客戶端崩潰了，也要保證后續(xù)的其他客戶端可以上鎖。

• 保證上鎖和解鎖都是同一個客戶端。

一般來說，實現(xiàn)分布式鎖的方式有以下幾種：

• 使用 MySQL，基于唯一索引。

• 使用 ZooKeeper，基于臨時有序節(jié)點。

• 使用 Redis，基于 setnx 命令。

對 redis 來說注意三點，對 key 的加鎖，如果請求未完成對快要過期的 key 的續(xù)期，請求完成后 key 的解鎖。防止并發(fā)環(huán)境下被讀取的一個 key 可能被多個請求修改，造成無效操作，資源浪費的情況。

五、redis 總結

• redis 可以做為 mysql 的前置緩存數(shù)據(jù)庫，redis 與 mysql 對接的方式需要配置線程池，需要定義后端 mysql 的位置（ IP + port ＋sock 文件的位置）

• redis 基礎功能：用于內存/緩存的快速存儲（讀?。?/p>

• 實現(xiàn)的方式：

默認將數(shù)據(jù)存儲在內存/緩存中
具有豐富的數(shù)據(jù)類型：string list hash set && order set 等
重要數(shù)據(jù)持久化的功能，持久化的方式：AOF RDB

單線程模式 -> 速度快的原因之一：Epoll + I/O 復用（cluster 中的 slots 哈希槽可以充當數(shù)據(jù)讀、取的索引)

• redis 中的算法：

LRU：淘汰策略1) 緩存中的數(shù)據(jù)進行隨機淘汰2) 緩存中被設置了過期時間的數(shù)據(jù)進行隨機淘汰3) 緩存中被設置了過期時間的數(shù)據(jù)，進行惰性刪除（僅當訪問到的數(shù)據(jù)過期了，才會刪除）4) 當數(shù)據(jù)持續(xù)存儲過程中內存將滿，會在設置了過期時間的數(shù)據(jù)中進行近期淘汰

令牌桶 + 漏桶算法：限流
Raft：選舉機制，用于選舉新的主節(jié)點

• redis 緩存高熱數(shù)據(jù)的機制

高熱數(shù)據(jù)：命中次數(shù)高的數(shù)據(jù)
指定提高緩存內數(shù)據(jù)的命中數(shù)，最直接的可以刷腳本，訪問這些數(shù)據(jù)

六、系統(tǒng)優(yōu)化

1. 單例服務器，服務器本身優(yōu)化

硬件資源選擇（系統(tǒng)五大資源）

• 磁盤 固態(tài)盤 SCSI（硬件磁盤陣列）

• 服務器內存條選擇（本地服務器和云服務器）

• CPU 核數(shù)選擇

• 網(wǎng)絡網(wǎng)卡（本地服務器和云服務器），需要考慮負載壓力下的網(wǎng)絡流量 QPS

• 服務器選型（麒麟、曉龍、浪潮英信、華為、華三、戴爾（類型：刀片、塔式、機柜））

以上需要計算費用成本，還需要考慮到該服務器上的服務在運行時消耗的性能比例（需要預留給系統(tǒng)一部分資源）

服務本身環(huán)境的選擇

• 操作系統(tǒng)選擇 Linux 發(fā)行版：centos ubuntu redhat server debian alphon mac SUSE（PS：虛擬化 KVM XEN FUFE）

• 基于操作系統(tǒng)，依賴環(huán)境。選擇最小化安裝還是指定操作系統(tǒng)版本的安裝 + 指定內核版本。軟件是否有依賴（例如：tomcat 需要 JDK，編譯需要 gcc gcc-c++ pcre …）

• 軟件資源優(yōu)化 五大負載＋內核優(yōu)化（TCP協(xié)議相關、隊列相關、路由轉發(fā)、重定向、端口、文件打開數(shù)、系統(tǒng)的軟硬限制等）

2. 單例服務器應用服務本身優(yōu)化

以 redis 為例

首先從啟動讀取的恢復文件來看，基于AOF需要開啟 AOF功能（RDB 默認）

• RDB 中 save M N 觸發(fā)周期的選擇判定，這會影響到磁盤資源的使用

• AOF 中選擇合適的 syncwrite 同步寫入磁盤的策略 everysecond

使用過程中，需要考慮到的是內存的使用量（ OOM ）

• 內存淘汰策略：惰性淘汰＋定期刪除，禁止淘汰＋定期刪除。根據(jù)情況選擇合適的淘汰策略（配置文件中定義）。

持久化方向
持久化的功能在保證數(shù)據(jù)完整性的同時，依然會持續(xù)性的對磁盤產生存儲壓力（壓力來源于 AOF 和 RDB 生成的數(shù)據(jù)文件，AOF 和 RDB 的日志文件）。

• 數(shù)據(jù)/日志文件的定期歸檔

• 日志文件的分割（保存在日志中心）

• 共享存儲 NFS GFS fastDFS

redis主進程

• 可以使用兩個 redis 主進程配合實現(xiàn)備份冗余，提高抗高并發(fā)的能力

感謝你能夠認真閱讀完這篇文章，希望小編分享的“redis主從復制、哨兵和集群的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關知識等著你來學習!

分享名稱：redis主從復制、哨兵和集群的示例分析
鏈接地址：http://biofuelwatch.net/article/jigdce.html