Redis全量復制與部分復制示例詳解
更新時間：2019年08月27日 08:35:29 作者：豆子先生
這篇文章主要給大家介紹了關于Redis全量復制與部分復制的相關資料，文中通過示例代碼介紹的非常詳細，對大家學習或者使用Redis爬蟲具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧
Redis 主從復制
- Redis 實例劃分為主節(jié)點(master)和從節(jié)點(slave)
- 默認情況下，Redis都是主節(jié)點
- 每個從節(jié)點只能有一個主節(jié)點，而主節(jié)點可以同時具有多個從節(jié)點
- 復制的數(shù)據(jù)流是單向的，只能由主節(jié)點復制到從節(jié)點
- slaveof 命令在使用時，可以運行期動態(tài)配置，也可以提前寫到配置文件中
- 主從復制
| 步驟 | 詳細描述 |
|---|---|
| 保存主節(jié)點信息 | 執(zhí)行slaveof后從節(jié)點只保存主節(jié)點的地址信息便直接返回 |
| 主從建立socket連接 | 從節(jié)點(slave)內(nèi)部通過每秒運行的定時任務維護復制相關邏輯，當定時任務發(fā)現(xiàn)存在新的主節(jié)點后，會嘗試與該節(jié)點建立網(wǎng)絡連接;從節(jié)點會建立一個socket套接字，專門用于接受住節(jié)點發(fā)送的復制命令；如果從節(jié)點無法建立連接，定時任務會無限重試直到連接成功或者執(zhí)行 slaveof no one 取消復制 |
| 發(fā)送ping命令 | 連接建立成功后從節(jié)點發(fā)送ping請求進行首次通信，ping請求的目的：檢測主從之間套接字是否可用；檢測主節(jié)點當前是否可接受處理命令.如果發(fā)送ping命令后，從節(jié)點沒有收到主節(jié)點的pong回復或者超時，比如網(wǎng)絡超時或者主節(jié)點正在阻塞無法響應命令，從節(jié)點會端口復制連接，下次定時任務會發(fā)起重連 |
| 權限驗證 | 如果主節(jié)點設置了requirepass 參數(shù)，則需要密碼驗證，從節(jié)點必須配置masterauth參數(shù)保證與主節(jié)點相同的密碼才能通過驗證；如果驗證失敗復制將終止，從節(jié)點重新發(fā)起復制流程 |
| 同步數(shù)據(jù)集 | 主從復制連接正常通信后，對于首次建立復制的場景，主節(jié)點會把持有的數(shù)據(jù)全部發(fā)送給從節(jié)點. |
| 命令持續(xù)復制 | 當主節(jié)點把當前的數(shù)據(jù)同步給從節(jié)點后，變成了復制的建立流程，接下來主節(jié)點會持續(xù)地把寫命令發(fā)送給從節(jié)點，保證主從數(shù)據(jù)一致性 |
- 啟動6380、6381
- 6381 執(zhí)行命令
127.0.0.1:6381> slaveof 127.0.0.1 6380 Redis5.0.0 改為 ： replicaof <masterip> <masterport>
- 6380 啟動
6381 啟動
查看info replication
數(shù)據(jù)同步
| 類型 | 描述 |
|---|---|
| 全量復制 | 一般用于初次復制場景，Redis早期支持的復制功能只有全量復制，它會把主節(jié)點全部數(shù)據(jù)一次性發(fā)送給從節(jié)點，當數(shù)據(jù)量較大時，會對主從節(jié)點和網(wǎng)絡造成很大的開銷 |
| 部分復制 | 用于處理在主從復制中因網(wǎng)絡閃斷等原因造成的數(shù)據(jù)丟失場景，當從節(jié)點再次連上主節(jié)點后，如果條件允許，主節(jié)點會補發(fā)丟失數(shù)據(jù)給從節(jié)點。因為補發(fā)的數(shù)據(jù)遠遠小于全量數(shù)據(jù)，可以有效避免全量復制的過高開銷 |
復制偏移量
| 參數(shù) | 描述 |
|---|---|
| master_repl_offset | 參與復制的主從節(jié)點都會維護自身復制偏移量。主節(jié)點(master)在處理完寫入命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計信息在info replication中的master_repl_offset指標中 |
| slave0 | 從節(jié)點(slave) 每秒鐘上報自身的復制偏移量給主節(jié)點，因此主節(jié)點也會保存從節(jié)點的復制偏移量 |
| slave_repl_offset | 從節(jié)點在接收到主節(jié)點發(fā)送的命令后，也會累加記錄自身的偏移量。 |
復制積壓緩沖區(qū)
- 復制積壓緩沖區(qū)是保存在主節(jié)點上的一個固定長度的隊列，默認大小為1MB，當主節(jié)點有連接的從節(jié)點(slave)時被創(chuàng)建，這是主節(jié)點(master)響應寫命令時，不但會把命名發(fā)送給從節(jié)點，還會寫入復制積壓緩沖區(qū)
- 由于緩沖區(qū)本質(zhì)上是先進先出的定長隊列，所以能實現(xiàn)保存最近已復制數(shù)據(jù)的功能，用于部分復制和復制命令丟失的數(shù)據(jù)補救
| 參數(shù) | 描述 |
|---|---|
| repl_backlog_active:1 | 開啟復制緩沖區(qū) |
| repl_backlog_size:1048576 | 緩沖區(qū)最大長度 |
| repl_backlog_first_byte_offset:1 | 起始偏移量，計算當前緩沖區(qū)可用范圍 |
| repl_backlog_histlen:2301 | 已保存數(shù)據(jù)的有效長度 |
| master_replid | 主節(jié)點實例的master_replid相同 |
| master_replid2 | 未發(fā)生切換，即主實例未發(fā)生過變化，所以初始值為0 |
psync 命令
從節(jié)點使用psync命令完成部分復制和全量復制功能
30227:M 05 Aug 2019 18:52:44.698 * Replica 127.0.0.1:6381 asks for synchronization 30227:M 05 Aug 2019 18:52:44.698 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'e7d71fb600183a175afadbd1354e97edddb2541a', my replication IDs are 'e24f6e42917e7c162ec45a713b0ee3872005ee8b' and '0000000000000000000000000000000000000000')
6381 從節(jié)點打印分析
31771:S 06 Aug 2019 12:21:40.213 * DB loaded from disk: 0.000 seconds 31771:S 06 Aug 2019 12:21:40.213 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer. #啟動成功 31771:S 06 Aug 2019 12:21:40.213 * Ready to accept connections # 開始連接主節(jié)點 31771:S 06 Aug 2019 12:21:40.214 * Connecting to MASTER 127.0.0.1:6380 # 開始同步 31771:S 06 Aug 2019 12:21:40.214 * MASTER <-> REPLICA sync started 31771:S 06 Aug 2019 12:21:40.214 * Non blocking connect for SYNC fired the event. 31771:S 06 Aug 2019 12:21:40.214 * Master replied to PING, replication can continue... # 嘗試增量同步 31771:S 06 Aug 2019 12:21:40.214 * Trying a partial resynchronization (request 668b25f85e84c5900e1032e4b5e1f038f01cfa49:5895). # 全量同步 31771:S 06 Aug 2019 12:21:40.215 * Full resync from master: c88cd043d66193e867929d9d5fadc952954371e5:0 31771:S 06 Aug 2019 12:21:40.215 * Discarding previously cached master state. 31771:S 06 Aug 2019 12:21:40.240 * MASTER <-> REPLICA sync: receiving 224 bytes from master 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Flushing old data 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Loading DB in memory 31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Finished with success
全量復制
- 全量復制是Redis最早支持的復制方式，也是主從第一次建立復制時必須經(jīng)歷的階段。觸發(fā)全量復制的命令是sync和psync
- 發(fā)送psync命令進行數(shù)據(jù)同步，由于是第一次進行復制，從節(jié)點沒有復制偏移量和主節(jié)點的運行ID，所以發(fā)送psync-1
- 主節(jié)點根據(jù)psync-1解析出當前為全量復制，回復+FULLRESYNC響應
- 從節(jié)點接收主節(jié)點的響應數(shù)據(jù)保存運行ID和偏移量offset
- 主節(jié)點執(zhí)行bgsave保存RDB文件到本地
31651:M 06 Aug 2019 11:08:40.802 * Starting BGSAVE for SYNC with target: disk 31651:M 06 Aug 2019 11:08:40.802 * Background saving started by pid 31676 31676:C 06 Aug 2019 11:08:40.805 * DB saved on disk 31676:C 06 Aug 2019 11:08:40.806 * RDB: 0 MB of memory used by copy-on-write 31651:M 06 Aug 2019 11:08:40.886 * Background saving terminated with success 31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
- 主節(jié)點發(fā)送RDB給從節(jié)點，從節(jié)點把接收的RDB文件保存在本地并直接作為從節(jié)點的數(shù)據(jù)文件,接收完RDB后從節(jié)點打印相關日志
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: receiving 224 bytes from master
- 對于從節(jié)點開始接收RDB快照到接收完成期間，主節(jié)點仍然響應讀寫命令，因此主節(jié)點會把這期間寫命令數(shù)據(jù)保存在復制客戶端緩沖區(qū)內(nèi)，當從節(jié)點加載完RDB文件后，主節(jié)點再把緩沖區(qū)內(nèi)的數(shù)據(jù)發(fā)送個從節(jié)點，保證主從之間數(shù)據(jù)一致性。
- redis.conf 配置
client-output-buffer-limit replica 256mb 64mb 60
- 如果主節(jié)點創(chuàng)建和傳輸RDB的時間過長，對于高流量寫入場景非常容易造成主節(jié)點復制客戶端緩沖區(qū)溢出。默認配置如上所示，如果60秒內(nèi)緩沖區(qū)消耗持續(xù)大于64MB或者直接超過256MB時，主節(jié)點將直接關閉復制客戶端連接，造成全量同步失敗
- 對于主節(jié)點，當發(fā)送完所有的數(shù)據(jù)后就認為全量復制完成.
31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded
- 從節(jié)點接收完主節(jié)點傳送來的全部數(shù)據(jù)后會清空自身舊數(shù)據(jù)
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Flushing old data
- 從節(jié)點清空數(shù)據(jù)后開始加載RDB文件，對于較大的RDB文件，這一步操作依然比較耗時，可以通過計算日志之間的時間差來判斷加載RDB的總耗時
31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Loading DB in memory 31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Finished with success
- 從節(jié)點成功加載完RDB后，如果當前節(jié)點開啟了AOF持久化功能，它會立刻做bgrewriteaof操作，為了保證全量復制后AOF持久化文件立刻可用。
- 全量復制耗時的原因：
- 主節(jié)點bgsave時間
- RDB文件網(wǎng)絡傳輸時間
- 從節(jié)點清空數(shù)據(jù)時間
- 可能的AOF重寫時間
- 以下為Redis 3.0才會有
| 標識 | 含義 |
|---|---|
| M | 當前為主節(jié)點日志 |
| S | 當前為從節(jié)點日志 |
| C | 子進程日志 |
部分復制
- 部分復制主要是Redis針對全量復制的過高開銷做出的一種優(yōu)化措施，使用psync {runId}{offset}命令實現(xiàn)。當從節(jié)點(slave)正在復制主節(jié)點(master)時，如果出現(xiàn)網(wǎng)絡閃斷或者命令丟失等異常情況時，從節(jié)點會向主節(jié)點要求補發(fā)丟失的命令數(shù)據(jù)，如果主節(jié)點的復制積壓緩沖區(qū)內(nèi)存咋這部分數(shù)據(jù)則直接發(fā)送給從節(jié)點，這樣就可以保持主從節(jié)點復制的一致性。補發(fā)的這部分數(shù)據(jù)一般遠遠小于全量數(shù)據(jù).
- 當主節(jié)點直接網(wǎng)絡出現(xiàn)中斷是，如果超過repl-timeout時間，主節(jié)點會認為從節(jié)點故障并中斷復制連接
31767:M 06 Aug 2019 14:13:26.096 # Connection with replica 127.0.0.1:6381 lost.
- 主從連接中斷期間主節(jié)點依然響應命令，但因復制連接中斷命令無法發(fā)送給從節(jié)點，不過主節(jié)點內(nèi)部存在的復制積壓緩沖區(qū)，依然可以保存最近一段時間的寫命令數(shù)據(jù)，默認最大緩存1MB，可以通過into replication 查看
- 當從節(jié)點網(wǎng)絡恢復后，從節(jié)點會再次連上主節(jié)點
從節(jié)點打?。? 31934:S 06 Aug 2019 14:20:54.745 * MASTER <-> REPLICA sync started 31934:S 06 Aug 2019 14:20:54.745 * Non blocking connect for SYNC fired the event. 31934:S 06 Aug 2019 14:20:54.745 * Master replied to PING, replication can continue... 31934:S 06 Aug 2019 14:20:54.745 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:9996). 31934:S 06 Aug 2019 14:20:54.746 * Successful partial resynchronization with master. 31934:S 06 Aug 2019 14:20:54.746 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization. 主節(jié)點打?。? 31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization 31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.
- 當主從連接恢復后，由于從節(jié)點之前保存了自身已復制的偏移量和主節(jié)點的運行ID。因此會把它們當做psync參數(shù)發(fā)送個主節(jié)點，要求進行部分復制操作.從節(jié)點對應日志：
31938:S 06 Aug 2019 14:21:49.065 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:10066).
- 主節(jié)點接到psync命令后首先核對參數(shù)runId是否與自身一致，如果一致，說明之前復制的是當前主節(jié)點；之后根據(jù)參數(shù)offset在自身復制積壓緩沖區(qū)查找，如果偏移量之后的數(shù)據(jù)存在緩沖區(qū)中，則對從節(jié)點發(fā)送+COUTINUE響應，表示可以進行部分復制。從節(jié)點接到回復打印如下：
31938:S 06 Aug 2019 14:21:49.066 * Successful partial resynchronization with master. 31938:S 06 Aug 2019 14:21:49.066 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.
- 主節(jié)點根據(jù)偏移量把復制積壓緩沖區(qū)里的數(shù)據(jù)發(fā)送給從節(jié)點，保證主從復制進入正常狀態(tài)。發(fā)送的數(shù)據(jù)量可以在主節(jié)點的日志獲取
31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization 31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.
心跳
- 主從節(jié)點在建立復制后,它們之間維護著長連接并彼此發(fā)送心跳命令
- 主從心跳判斷機制：
- 主從節(jié)點彼此都有心跳檢測機制，各自模擬對方的客戶端進行通信，主節(jié)點的連接狀態(tài)為flags=M,從節(jié)點連接狀態(tài)為flags=S
- 主節(jié)點默認每隔10秒對從節(jié)點發(fā)送ping命令，判斷從節(jié)點的存活性和連接狀態(tài)?？梢酝ㄟ^repl-ping-replica-period 10 控制發(fā)送頻率
- 從節(jié)點在主線程中每隔一秒發(fā)送replconf ack{offset} 命令，給主節(jié)點上報自身當前的復制偏移量。主節(jié)點根據(jù)replconf命令判斷從節(jié)點超時時間，體現(xiàn)在info replication 統(tǒng)計中的lag信息中，lag表示從節(jié)點最后一次通信延遲的秒數(shù)，正常延遲應該在0到1之間。如果超過repl-timeout配置的值(默認60秒),則判定從節(jié)點下線并斷開復制客戶端連接。即使主節(jié)點判定從節(jié)點下線后，如果從節(jié)點重新恢復，心跳檢測和繼續(xù)執(zhí)行.
異步復制
- 主節(jié)點不但負責數(shù)據(jù)讀寫，還負責把寫命令同步給從節(jié)點。寫命令的發(fā)送過程是異步完成，也就是說主節(jié)點自身處理完寫命令后直接返回給客戶端，并不等待從節(jié)點復制完成。
讀寫分離
- 對于讀占比較高的場景，可以通過把一部分讀流量分攤到從節(jié)點(slave)來減輕主節(jié)點(master)壓力，同時需要注意永遠只對主節(jié)點執(zhí)行寫操作
- 建議大家在做讀寫分離之前，可以考慮使用Redis Cluster 等分布式解決方案
總結
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。
相關文章
這篇文章主要介紹了Redis中如何設置日志問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-12-12
在本篇內(nèi)容中我們給大家整理了關于redis端口號的相關知識點內(nèi)容，有興趣的朋友們學習下。2019-06-06
在實際項目中,我們可能需要根據(jù)一定的條件來刪除部分key,這時候就需要用到模糊刪除操作這,下面篇文章主要給大家介紹了關于Redis如何批量刪除指定模糊的key的相關資料,需要的朋友可以參考下2024-08-08
在本篇文章里小編給大家整理的是關于Redis分布式鎖的正確實現(xiàn)方式介紹，有興趣的朋友們可以學習下。2020-02-02
Redis是一個高性能的數(shù)據(jù)存儲框架，在高并發(fā)的系統(tǒng)設計中，Redis也是一個比較關鍵的組件，是我們提升系統(tǒng)性能的一大利器，本文詳細的介紹了Redis線程模型，感興趣的可以了解一2021-11-11
這篇文章主要介紹了redis服務如何啟動問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2023-08-08
Redis基本數(shù)據(jù)類型List常用操作命令
這篇文章主要為大家介紹了Redis數(shù)據(jù)類型List常用命令操作，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪2022-05-05
這篇文章主要介紹了詳解Redis實現(xiàn)限流的三種方式，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2021-04-04
集群技術是構建高性能網(wǎng)站架構的重要手段，下面這篇文章主要介紹了Redis 集群搭建和簡單使用教程，文中通過示例代碼和圖片介紹的很想，對大家具有一定的參考價值，有需要的朋友們下面來一起看看吧。2017-02-02
這篇文章主要給大家介紹了關于使用寶塔在服務器上配置Redis的相關資料,包括下載和安裝Redis,開放端口,修改配置文件以允許遠程訪問和設置密碼,該過程對于理解Redis在項目部署中的配置提供了實用指導,需要的朋友可以參考下2024-11-11