如何分析redis 復制

如何分析redis  復制，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

相對比使用RDS ，NOSQL 數據庫的雖使用，但被忽視的不少，相對于數據庫之間的復制，（物理復制， 邏輯復制）,redis 的復制，不少人認為還是比較簡單的。那下面有一些問題

1 redis 復制對對于內存有什么要求

2 redis 復制到底是推數據還是拉數據

3 如果兩臺 redis 擁有同樣的replicationID 和 offset 是否能他們的數據一致。

4 redis 可以擁有兩個復制ID嗎？

首先有幾個facts 需要別列出來

1 復制是異步的

2 復制不會阻止master 服務器的上的工作

3 master 上可以連接多個slaves

4 復制是可控的

5 Slave 都是只讀的

6 副本可以是master ，也就是具有級聯的概念

復制的配置很簡單，只要在從庫配置了 replicaof 信息，以及master 認證，初步的復制就會工作了。

在Master 和 replica 之間建立復制的關系后，，由master發送指令給replica，并且將所發生的操作，鍵值過期以及處理，等信息發送給replica。

當master和replica主鍵由于某些原因斷開后，進行重新連接后進行重新的同步，將replica中沒有的數據，從主同步到replica,當這樣的復制方式不能進行正常的同步，則要在主中先進行snapshot  當前所有的數據發送給replica然后在將后續復制過程中，master操作的數據在復制并重放到replica.

問題1 

redis 在復制中內存比單機的redis要考慮的更多，通常redis 被分配的內存的60% 用于主要的工作，而剩下的是需要為bgsave 和后期的數據同步服務的。

最后一句話的意思是，reids 的復制其實的數據是要灌入到內存中，而不是和傳統數據庫要進行落盤的操作，在進行數據的硬化。所以redis的數據復制是依賴于內存的，并且內存預留的越大，則復制的速度也越快，所以預留足夠的內存給REDIS 對加速復制是有好處的。

問題2 redis 的數據應該是屬于推的方式

這個問題其實我也查過一些資料，但特別清晰的定義數據是 pull 還是push 的并沒有。但下面的一段官方的文字或許可以回答這個問題。當 replica  連接到主后， 會發送psync命令到主，其中包含如果之前已經有主，并且有復制的話，則發送他目前擁有的主以及復制的offset 偏移量，然后主就會根據這個信息，將他目前的偏移量進行比對，如果可以進行數據的發送則開始發送數據。 如果副本引用的歷史記錄(復制ID)不再已知，則會發生完全重新同步:在這種情況下，副本將從頭獲得數據集的完整副本。

所以根據這段文字我認為redis復制的方式是 從主推送數據。

問題 3  

復制ID基本上標記了給定的數據集歷史。每當一個實例作為主實例從頭開始，或者一個副本被提升為主副本時，都會為這個實例生成一個新的復制ID。連接到主服務器的副本將在握手后繼承其復制ID。因此，具有相同ID的兩個實例之間存在關聯，因為它們擁有相同的數據，但可能在不同的時間。對于保存最新數據集的給定歷史記錄(復制ID)，偏移量作為需要理解的邏輯時間。所以具有相同的復制ID 以及 OFFSET 偏移量的兩個REDIS 數據是同步的。

問題 4  

Redis實例有兩個復制id的原因是將副本提升到主副本。故障轉移之后，提升的副本仍然需要記住它以前的復制ID，因為這樣的復制ID是以前的主副本ID。這樣，當其他副本將與新主副本同步時，它們將嘗試使用舊主副本ID執行部分重新同步。這將像預期的那樣工作，因為當副本被提升為主ID時，它將把它的輔助ID設置為主ID，記住這個ID切換發生時的偏移量。稍后，它將選擇一個新的隨機復制ID，因為一個新的歷史記錄開始了。在處理連接的新副本時，主副本將使用當前ID和輔助ID匹配它們的ID和偏移量(為安全起見，最大偏移量為給定偏移量)。簡而言之，這意味著在故障轉移之后，連接到新提升的主服務器的副本不必執行完全同步。所以一個REDIS 在進行故障轉移后，并且還要掛載其他的新的replica的情況下，是擁有兩個replica ID的。

關于如何分析redis  復制問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。