一般來說，要將redis應用於一臺服務器是萬萬不能的，原因如下：

1.從結構上，單個redis服務器會發生單點故障，並且一臺服務器需要處理所有的請求負載，壓力較大

2.從容量上看，單個redis服務器內存容量有限，就算一臺redis服務器內容容量爲256G，也不能所有內容用作redis存儲內存，一般來說，單臺redis最大使用內存不應該超過20G

主從複製

考慮如下一種場景：

電子商務網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是”多讀少寫”。

對於這種場景，我們可以使如下這種架構：

如圖中所示，我們將一臺Redis服務器作主庫，其他三臺作爲從庫，主庫只負責寫數據，每次有數據更新都會將更新的數據同步到它所有的從庫，而從庫只負責讀數據，這樣一來，就有了2個好處：

1.讀寫分離，不僅可以提高服務器的負載能力，並且可以根據讀請求的規模自由增加或減少從庫的數量；

2.數據被賦值了好幾份，就算有一臺機器出現故障，也可以使用其他的機器的數據快速恢復

需要注意的是：在Redis主從模式中，一臺主庫可以擁有多臺從服務器，而從從服務器只能屬於一臺主服務器

配置：

在redis中，要實現主從配置非常簡單，只需要在從服務器配置中把salveof 主庫地址主庫端口就行，主服務器不需要修改。

例：

下面將演示怎麼實現一個簡單的複製系統。我們在一臺機器上起兩個Redis實例，監聽不同的端口，其中一個作爲主庫，另外一個作爲從庫。首先不加任何參數來啓動一個Redis實例作爲主數據庫：

可以看到，主庫監聽的是6379端口。

然後加上slaveof參數啓動另一個Redis實例作爲從庫，並且監聽6380端口：

接下里驗證一把

首先在主服務器上設置一個鍵值

set a 1;

現在到從服務器檢查該值是否同步到了了從庫：

get a;

可以看到主庫同步到了從庫。

原理：

上面說了配置主從複製系統的方法，並且舉例詳細說明，本節將介紹redi主從複製的原理：

當一個從數據庫啓動時，會向主服務器發送sync命令，主數據收到命令之後會開始在後臺保存快照（即RDB持久化過程）。並將保存快照期間接受到的命令緩存起來，當快照完成後，redis會將快照文件和緩存命令發給從服務器，從服務器接收到數據後，會載入快照文件並執行緩存命令，以上過程稱爲複製初始化，複製初始化之結束後，主數據庫每收到寫命令時就會將命令同步到從服務器，從服務器保證主從數據一致，這一過程稱爲複製同步過程。

有2點需要注意：

1.當主從服務器之間的連接斷開後，redis2.8之前的版本會重新進行復制初始化過程，這樣就使主從服務器斷開連接之後數據恢復過程很低，redis2.8後，當從服務器再次連接主服務器的時候，主服務器只需要將斷線期間執行的命令發給從服務器即可，大大提高了redis主從複製的實用性;

2.複製同步階段貫穿了整個主從複製過程，直到主從關係終止。在複製過程中，即時把rdb持久化關閉，依舊會執行快照操作。

樂觀複製：

Redis採用了複製的策略，容忍一段時間內主從數據庫的內容是不同的，但是2個數據最終還是保持一致的，具體來說，redis主從複製之間的複製數據的過程本身就是異步的，這意味着，主數據庫執行完客戶端寫請求之後立即會把執行的結果告訴給客戶端，而不會等到從服務器收到該命令後再返回給客戶端，這一特性保證了複製後主從服務器性能不能受影響的。但另一方面也會產生主從數據不一樣的情況，當主服務器執行一條命令之後，主服務器的數據已經發生了變化，然而在主服務器將該命令傳送給從服務器的之前，如果2個服務器之間連接斷開了，此時二者間的數據不一致的。從這個角度看，從這個角度看，主服務器無法得知最終同步了幾個從服務器，不過redis提供了2個配置選項來限定只有至少同步到了指定數量的從服務器，主服務器纔會操作

min-salve-to-write 3

min-salve2-max-lag 10

第一個參數表示，至少只有3個或者3個以上的從服務器連接到了主服務器，主服務器纔會寫操作，否則返回出錯

第二個參數表示允許從服務器失去連接的最長時間，該選項默認是關閉的，在分佈式中，打開併合理的配置該選項可以降低主從架構因爲網絡分區導致數據不一致問題。