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

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

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

主從複製

考慮如下一種場景：

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

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

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

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

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

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

配置：

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

例：

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

然後加上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個以上的從伺服器連線到了主伺服器，主伺服器才會寫操作，否則返回出錯

第二個引數表示允許從伺服器失去連線的最長時間，該選項預設是關閉的，在分散式中，開啟併合理的配置該選項可以降低主從架構因為網路分割槽導致資料不一致問題。

圖結構

從資料庫不僅可以接收主資料庫的資料，同時也可以作為主資料庫存在，形成類似圖的結構，如下圖：

A中的資料會同步到B,C中，C中的資料會同步到D,E中。