前言

今天分享一下Redis的持久化、事務(wù)、管道相關(guān)的知識(shí)點(diǎn)，實(shí)現(xiàn)快速入門，豐富個(gè)人簡(jiǎn)歷，提高面試level，給自己增加一點(diǎn)談資，秒變面試小達(dá)人，BAT不是夢(mèng)。

一、Redis復(fù)制是什么？

Redis復(fù)制就是主從復(fù)制，當(dāng)主服務(wù)器數(shù)據(jù)發(fā)生變化時(shí)，自動(dòng)將新的數(shù)據(jù)同步到從數(shù)據(jù)庫。

讀數(shù)據(jù)庫可以進(jìn)行讀寫操作，從數(shù)據(jù)庫一般指用于讀操作。

Redis復(fù)制可以保證主數(shù)據(jù)庫崩潰時(shí)可以進(jìn)行數(shù)據(jù)恢復(fù)。

二、Redis復(fù)制能干嘛？

1. 讀寫分離
2. 容災(zāi)恢復(fù)
3. 數(shù)據(jù)備份
4. 水平擴(kuò)容支撐高并發(fā)

三、Redis復(fù)制的缺點(diǎn)

1、復(fù)制延遲

由于所有的寫操作都發(fā)生在master數(shù)據(jù)庫，然后同步到slave數(shù)據(jù)庫中，所以會(huì)有一定的數(shù)據(jù)延遲，當(dāng)系統(tǒng)負(fù)擔(dān)過重時(shí)，延遲越大，slave機(jī)器的增加也會(huì)增加數(shù)據(jù)延遲的時(shí)間。

2、master宕機(jī)

如果master宕機(jī)了，默認(rèn)情況下不會(huì)將salve數(shù)據(jù)庫自動(dòng)升級(jí)為master數(shù)據(jù)庫。

四、樂觀復(fù)制策略

Redis采用樂觀復(fù)制策略，容忍一段時(shí)間內(nèi)主從數(shù)據(jù)庫不一致，但保證最終一致性。這個(gè)策略保證了性能，在復(fù)制的時(shí)候，主數(shù)據(jù)庫不會(huì)阻塞，可以繼續(xù)提供服務(wù)。

五、Redis復(fù)制常用命令

1、info replication

查看節(jié)點(diǎn)的主從關(guān)系和配置信息。

2、replicaof 主庫Ip 主庫port

在從數(shù)據(jù)庫的redis.conf中配置。

3、slaveof 主庫IP 主庫port

在運(yùn)行期間修改slave節(jié)點(diǎn)的信息，如果該數(shù)據(jù)庫已經(jīng)是其它主數(shù)據(jù)庫的從數(shù)據(jù)庫了，那么它會(huì)停止與其的主從關(guān)系，轉(zhuǎn)而成為新配置的主庫的從數(shù)據(jù)庫。

4、slaveof no one

使當(dāng)前數(shù)據(jù)庫停止與其它數(shù)據(jù)庫的同步，升級(jí)為主數(shù)據(jù)庫。

六、Redis復(fù)制工作流程

1、slave啟動(dòng)成功后，會(huì)連接master數(shù)據(jù)庫，發(fā)送一個(gè)sync命令，同步數(shù)據(jù)；如果是第一次連接，則會(huì)進(jìn)行一次全量復(fù)制，slave自身的數(shù)據(jù)會(huì)被master數(shù)據(jù)覆蓋清除；

2、master數(shù)據(jù)庫收到sync命令后，通過RDB開始保存快照，同時(shí)將所有接收到的用于修改數(shù)據(jù)庫的命令緩存起來，master數(shù)據(jù)庫執(zhí)行完RDB持久化后，master將RBD文件和所有緩存的命令發(fā)送到所有的slave數(shù)據(jù)庫，完成一次數(shù)據(jù)同步；

3、slave收到RDB文件和命令緩存后，將其加載到內(nèi)存中，從而完成復(fù)制初始化；

4、repl-ping-replica-period 10，表示master發(fā)出ping包的周期默認(rèn)是10秒；

5、完成首次數(shù)據(jù)全量同步后，master繼續(xù)將新的收集到的修改命令定期傳給slave數(shù)據(jù)庫，完成數(shù)據(jù)同步；

6、如果從機(jī)重啟了，master的backlog中會(huì)記錄offset，master會(huì)將offset后面的數(shù)據(jù)復(fù)制給slave。

7187:C 14 Mar 22:14:24.106 # nzbc Redis is starting nzbc
7187:C 14 Mar 22:14:24.107 # Redis version=6.0.8, bits=64, commit=00000000, modified=0, pid=7187, just started
7187:C 14 Mar 22:14:24.108 # Configuration loaded
7188:S 14 Mar 22:14:24.110 * Increased maximum number of open files to 10032 (it was originally set to 256).
                _._
           _.-``__ ''-._
      _.-``    `.  `_.  ''-._           Redis 6.0.8 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6380
 |    `-._   `._    /     _.-'    |     PID: 7188
  `-._    `-._  `-./  _.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |           http://redis.io
  `-._    `-._`-.__.-'_.-'    _.-'
 |`-._`-._    `-.__.-'    _.-'_.-'|
 |    `-._`-._        _.-'_.-'    |
  `-._    `-._`-.__.-'_.-'    _.-'
      `-._    `-.__.-'    _.-'
          `-._        _.-'
              `-.__.-'

7188:S 14 Mar 22:14:24.120 # Server initialized
7188:S 14 Mar 22:14:24.114 * DB loaded from disk: 0.000 seconds
7188:S 14 Mar 22:14:24.122 * Before turning into a slave, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
7188:S 14 Mar 22:14:24.122 * Ready to accept connections
7188:S 14 Mar 22:14:24.123 * Connecting to MASTER 127.0.0.1:6379
7188:S 14 Mar 22:14:24.123 * MASTER <-> SLAVE sync started
7188:S 14 Mar 22:14:24.123 * Non blocking connect for SYNC fired the event.
7188:S 14 Mar 22:14:24.124 * Master replied to PING, replication can continue...
7188:S 14 Mar 22:14:24.124 * Trying a partial resynchronization (request 9b3cs5w9g6x3004fa9a0999361035b71ecf70ab4:30783).
7188:S 14 Mar 22:14:24.130 * Full resync from master: cb4as85df693ad62f09ce4f486e0d43ec8f36334:0
7188:S 14 Mar 22:14:24.130 * Discarding previously cached master state.
7188:S 14 Mar 22:14:24.163 * MASTER <-> SLAVE sync: receiving 5484 bytes from master
7188:S 14 Mar 22:14:24.165 * MASTER <-> SLAVE sync: Flushing old data
7188:S 14 Mar 22:14:24.165 * MASTER <-> SLAVE sync: Loading DB in memory
7188:S 14 Mar 22:14:24.167 * MASTER <-> SLAVE sync: Finished with success

七、Redis哨兵是什么？

Redis提供了哨兵sentinel機(jī)制來監(jiān)控Redis的性能，如果主數(shù)據(jù)庫宕機(jī)了，根據(jù)投票數(shù)自動(dòng)將某一個(gè)從數(shù)據(jù)庫提升為主數(shù)據(jù)庫，繼續(xù)對(duì)外提供服務(wù)。

1、Redis哨兵的作用

1. 主從監(jiān)控，監(jiān)控主從數(shù)據(jù)庫是否運(yùn)行正常；
2. 消息通知，哨兵可以將故障信息發(fā)送給客戶端；
3. 故障轉(zhuǎn)移，如果master異常。哨兵會(huì)進(jìn)行主備切換，將其中一個(gè)slave轉(zhuǎn)為master；
4. 配置中心，客戶端通過連接哨兵獲取Redis服務(wù)集群的主節(jié)點(diǎn)信息；

2、使用哨兵的注意事項(xiàng)：

八、實(shí)戰(zhàn)演練

1、搭建3個(gè)哨兵服務(wù)器

監(jiān)控Redis主從服務(wù)器，不存放數(shù)據(jù)。

2、sentinel.conf參數(shù)選項(xiàng)說明

bind 0.0.0.0
daemonize yes
protected-mode no
port 6391
logfile "/myredis/sentinel1.log"
pidfile /var/run/redis-sentinel6391.pid
dir /myredis
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel auth-pass mymaster 123456

設(shè)置要監(jiān)控的master服務(wù)器，quorum表示至少有幾個(gè)哨兵認(rèn)為客觀下線，同意故障轉(zhuǎn)移的法定票數(shù)，因此哨兵服務(wù)器一般為奇數(shù)個(gè)。

sentinel monitor <master-name> 127.0.0.1 6379 <quorum>。

master服務(wù)器設(shè)置了密碼：

sentinel auth-pass <master-name> <password>

通過命令，完成哨兵sentinel的啟動(dòng)，兩種方式，任選其一：

1. redis-sentinel /path/to/sentinel.conf
2. redis-server /path/to/sentinel.conf --sentinel

九、哨兵運(yùn)行流程和選舉原理

當(dāng)一個(gè)主從配置中的master失效后，sentinel會(huì)選舉出一個(gè)新的master用于接替原master的工作，其它slave服務(wù)器自動(dòng)指向新master，實(shí)現(xiàn)數(shù)據(jù)同步。

1、主觀下線

指定多少毫秒之后，主節(jié)點(diǎn)沒有應(yīng)答哨兵，此時(shí)哨兵會(huì)主觀上認(rèn)為主節(jié)點(diǎn)已經(jīng)下線。

sentinel down-after-millisecnds <master-name> <millisecnds>

2、客觀下線

多個(gè)哨兵sentinel進(jìn)行投票，根據(jù)投票結(jié)果才能確認(rèn)一個(gè)master客觀上已經(jīng)宕機(jī)。

3、選舉master三步走：

（1）先選出一個(gè)master服務(wù)器

當(dāng)master數(shù)據(jù)庫宕機(jī)后，各個(gè)哨兵sentinel節(jié)點(diǎn)會(huì)進(jìn)行協(xié)商，先通過Raft算法選舉出一個(gè)領(lǐng)導(dǎo)者哨兵節(jié)點(diǎn)，再由領(lǐng)導(dǎo)者進(jìn)行master的選舉。

根據(jù)Redis.conf中，優(yōu)先級(jí)slave-priority或者replica-priority最高的從節(jié)點(diǎn)（數(shù)字越小優(yōu)先級(jí)越高）。復(fù)制偏移位置offset最大的從節(jié)點(diǎn)；最小Run ID的從節(jié)點(diǎn)

（2）其它slave服務(wù)器連接到master服務(wù)器

執(zhí)行slaveof no one命令會(huì)選舉出新的master，并通過slaveof命令將其它從節(jié)點(diǎn)成為新master服務(wù)器的從節(jié)點(diǎn)。

（3）如果舊master服務(wù)器恢復(fù)正常了，也要成為新master服務(wù)器的slave從服務(wù)器。

到此這篇關(guān)于圖解Redis主從復(fù)制與Redis哨兵機(jī)制的文章就介紹到這了,更多相關(guān)Redis主從復(fù)制與哨兵機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論