主從復制
如果 Redis 的讀寫請求量很大，那么單個 Redis 實例很有可能承擔不了這么大的請求量，如何提高Redis的性能呢？我們可以部署多個副本節點，業務采用讀寫分離的方式，把讀請求分擔到多個副本節點上，提高訪問性能。要實現讀寫分離，就必須部署多個副本，每個副本需要實時同步主節點的數據。
單可用區（節點全部在一個可用區）：無法應對機房級別的故障
如果上海可用區機房出現故障，整個Redis服務全部癱瘓，所以我們在平時部署時，需要把節點分散在不同的可用區，如果有小伙伴公司對可用性要求極高，可以研究下異地多活方案，在這里我就不展開了。
主從復制的三種方式：
①全量復制
②增量復制
③無盤復制
1.全量復制
假設我們有兩個節點，A節點是 Master 節點，B節點是 Slave 節點。
當我們在節點B上執行slaveof命令后，節點B會與節點A建立一個TCP連接，然后發送psync ${runid} ${offset}命令，告知節點A需要開始同步數據。
參數介紹：
-
runid：每個 Redis 實例啟動時都會自動生成的一個隨機 ID，用來唯一標記這個實例 -
offset：偏移量，slave需要從哪個位置開始同步數據
由于是第一次同步，Slave 節點不知道 Master節點的runid，所以 Slave 節點會發送psync ? -1，表示需要全量同步數據。
Master 節點在收到 Slave 節點發來的psync后，會給slave回復+fullresync ${runid} ${offset}，這個runid就是master的唯一標識，slave會記錄這個runid，用于后續斷線重連同步請求。
Master 執行 bgsave 命令，生成 RDB 文件，接著將文件發給 Slave。Slave 接收到 RDB 文件后，會先清空當前數據庫，然后加載 RDB 文件。這是因為Slave在通過 replicaof 命令開始和 Master 同步前，可能保存了其他數據。為了避免之前數據的影響，Slave 需要先把當前數據庫清空。
在 Master 將數據同步給 Slave 的過程中，Master 不會被阻塞，仍然可以正常接收請求。否則，Redis 的服務就被中斷了。但是，這些請求中的寫操作并沒有記錄到剛剛生成的 RDB 文件中。為了保證主 Slave 的數據一致性，Master 會在內存中用 repl_backlog_buffer 記錄 RDB 文件生成后收到的所有寫操作。
最后，Master 會把 repl_backlog_buffer數據再發送給從庫。這樣一來，主從庫就實現同步了。
全量復制的開銷：
主節點：生成RDB文件會占用內存、硬盤資源，網絡傳輸RDB的時候會占用一定的網絡帶寬資源
從節點：清空數據，若數據量大，需要消耗一定的時間，加載RDB也需要一定的時間
2.增量同步
在 Redis 2.8 之前，如果主從庫在命令傳播時出現了網絡閃斷，從庫就會和主庫重新進行一次全量復制，開銷非常大。
在Redis在這方面進行了改進，在2.8版本之后，Redis支持增量同步。
主從因為故障斷開，故障恢復后，他們重新建立連接，Slave 節點向 Master 節點發送數據 同步請求：psync ${runid} ${offset}，Master 收到psync命令之后，檢查slave發來的runid與自身的runid一致，如果一致，說明之前已經同步過數據，這次只需要同步部分數據即可。
這里分為兩種情況：
①如果offset在repl_backlog_buffer范圍內，那么 Master 節點給 Slave 節點回復+continue，表示這次只同步部分數據。之后 Master 節點把復制緩沖區offset之后的數據給 Slave 節點，接下來 Slave 節點執行這些命令后就與 Master 數據一致了。
②如果offset不在repl_backlog_buffer范圍內，說明斷開連接很久了，如果offset在repl_backlog_buffer的內容已經被新的內容覆蓋了，此時只能觸發全量數據同步。
3.無盤復制
通常，全量復制需要在磁盤上創建RDB文件，然后加載到內存中，Redis支持無盤復制，生成的RDB文件不保存到磁盤而是直接通過網絡發送給從節點。無盤復制適用于主節點所在機器磁盤性能較差但網絡寬帶較充裕的場景。需要注意的是，無盤復制目前依然處于實驗階段。
