Redis的主從配置

1、主從配置過程

關於主從配置的過程，咱們這裏就不作具體詳細解釋了，看這個文章，仍是不錯的：

http://www.javashuo.com/article/p-xqtimvdi-kb.html

2、主從複製的原理

這纔是咱們的主要問題，咱們來看一下

　　Redis的複製功能分爲同步（sync）和命令傳播（command propagate）兩個操做。

　　①、舊版同步

　　當從節點發出 SLAVEOF 命令，要求從服務器複製主服務器時，從服務器經過向主服務器發送 SYNC 命令來完成。該命令執行步驟：

　　一、從服務器向主服務器發送 SYNC 命令

　　二、收到 SYNC 命令的主服務器執行 BGSAVE 命令，在後臺生成一個 RDB 文件，並使用一個緩衝區記錄從開始執行的全部寫命令

　　三、當主服務器的 BGSAVE 命令執行完畢時，主服務器會將 BGSAVE 命令生成的 RDB 文件發送給從服務器，從服務器接收此 RDB 文件，並將服務器狀態更新爲RDB文件記錄的狀態。

　　四、主服務器將緩衝區的全部寫命令也發送給從服務器，從服務器執行相應命令。

　　②、命令傳播

　　當同步操做完成以後，主服務器會進行相應的修改命令，這時候從服務器和主服務器狀態就會不一致。

　　爲了讓主服務器和從服務器保持狀態一致，主服務器須要對從服務器執行命令傳播操做，主服務器會將本身的寫命令發送給從服務器執行。從服務器執行相應的命令以後，主從服務器狀態繼續保持一致。

　　總結：經過同步操做以及命令傳播功能，可以很好的保證了主從一致的特性。

　　可是咱們考慮一個問題，若是從服務器在同步主服務器期間，忽然斷開了鏈接，而這時候主服務器進行了一些寫操做，這時候從服務器恢復鏈接，若是咱們在進行同步，那麼就必須將主服務器重新生成一個RDB文件，而後給從服務器加載，這樣雖然可以保證一致性，可是其實斷開鏈接以前主從服務器狀態是保持一致的，不一致的是從服務器斷開鏈接，而主服務器執行了一些寫命令，那麼從服務器恢復鏈接後能不能只要斷開鏈接的哪些寫命令，而不是整個RDB快照呢？

　　同步操做實際上是一個很是耗時的操做，主服務器須要先經過 BGSAVE 命令來生成一個 RDB 文件，而後須要將該文件發送給從服務器，從服務器接收該文件以後，接着加載該文件，而且加載期間，從服務器是沒法處理其餘命令的。

　　爲了解決這個問題，Redis從2.8版本以後，使用了新的同步命令 PSYNC 來代替 SYNC 命令。該命令的部分重同步功能用於處理斷線後重複製的效率問題。也就是說當從服務器在斷線後從新鏈接主服務器時，主服務器只將斷開鏈接後執行的寫命令發送給從服務器，從服務器只須要接收並執行這些寫命令便可保持主從一致。

3、主從複製的缺點

       主從複製雖然解決了主節點的單點故障問題，可是因爲全部的寫操做都是在 Master 節點上操做，而後同步到 Slave 節點，那麼同步就會有必定的延時，當系統很繁忙的時候，延時問題就會更加嚴重，並且會隨着從節點slave的增多而越發嚴重。