Redis叢集主從複製,讀寫分離（上）

前言：隨著web2.0的進一步發展，網民的生產力進一步提升，儲存總量開始增加。 此時雖然仍然是讀多寫少的模式，但寫入量已經大大提升。 原有的緩衝技術不能緩解寫入壓力，而且原有的空間也受硬碟限制，因此開始出現分庫分表，實現讀寫分離。 集線模式的資料庫就這樣開始逐漸分化：由一個集中的、穩定的、強關係的結構，朝一個分化的、容錯的、弱關係的結構發展。 資料的儲存空間與資料訪問時間也進一步分離。 即原來是資料存在什麼地方，就去什麼地方訪問。現在是資料還是存在老地方(硬碟)，但是訪問卻在另一個地方(比如記憶體，或另一個伺服器)。其目的，就在於縮短IO路徑或分離IO，實現高效訪問。

Redis主機資料更新後根據配置和策略，自動同步到備機的master/slaver機制，Master以寫為主，Slave以讀為主，這樣就可以減輕伺服器的壓力了。

redis主從複製之配置介紹

複製的原理介紹

slave啟動成功串連到master後會發送一個sync命令，Master接到命令啟動背景存檔進程，同時收集所有接收到的用於修改資料集命令，在後台進程執行完畢之後，master將傳送整個資料檔案到slave,以完成一次完全同步 全量複製：而slave服務在接收到資料庫檔案資料後，將其存檔並載入到記憶體中。 差異複寫：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步

但是只要是重新串連master,一次完全同步（全量複製)將被自動執行

case 1：一主N從

（在這裡我只使用了一台Linux機器，但是通過配置同樣可以達到Redis叢集的需求，如果有多個伺服器，配置是一樣的）

首先從拷貝3個redis.conf檔案（拷貝兩個也是可以的，這裡我是為了區分Master/Slave）

那麼接下來就是修改配置了 主機配置介紹（為了說明在主從複製的時候訪問的不是同一個資料庫檔案，將資料庫檔案名也相應的修改） 

從機配置介紹

從機6380配置 

從機6381配置 

OK配置完成了，那麼接下來就是啟動redis服務並串連，查看配置是否有效

 

通過info replication命令查看資訊

我們可以看到，3台伺服器的redis服務成功啟動，角色都是master，那麼接下來就是要區分主從庫了，通過命令slaveof 主機IP 主機redis連接埠

slaveof 127.0.0.1 6379

這樣就可以了，然後再次通過info replication命令查看，發現這個時候連接埠號碼為6380,6381的redis從主庫變成了從庫

那麼這個時候在主庫中執行寫的操作

在set k4之前做了set k1，k2，k3操作，然後6380，6381作為從庫串連主庫，發現主庫中所有的資料在從庫中都有，而且每個從庫都有資料庫檔案

那麼在這個時候我們在從庫執行write操作的時候，發現是無法正確執行的

因為有了從庫之後，讀寫就已經分離了，所以在從庫中只能執行讀的操作

上面呢我是通過命令的方式實現主從庫的分離的，那麼大家就會發現，這樣子是很麻煩的，萬一從庫redis服務掛了之後，再次啟動redis服務之後還要執行

slaveof 127.0.0.1 6369

這樣子是很不人性化的，而且也是非常的麻煩，那麼接下來就通過設定檔的方式實現主從庫的分離

其他的從庫也是這樣配置，OK，配置已經好了，那麼接下來就是啟動redis服務了

我們可以看到，當redis服務啟動之後，角色立馬變成從庫了，而不要向我們之前的需要手動敲命令，這樣也是挺方便的

上面的case 1呢講到了一主N從得模式

那麼redis從庫是否可以讓其他的redis服務串連呢。

case 2：傳宗接代

傳宗接代的意思呢就是說一個主庫下只有一個從庫，而這個從庫下又有其他的redis從庫跟著。一個跟著一個，而不是一個主庫下有跟著N個從庫，這樣子呢就可以去中心化，但是這樣子呢會出現資料複製的延時，因為你是一個跟著一個，在主庫中有資料的變化，那麼下面的從庫就會立即複製，但是這個時候只有一個從庫，要等當前從庫複製完成才可以再次向下複製

配置

將其中一台的配置修改

啟動redis服務

服務啟動成功，那麼中間那一台連著主庫的那個redis（也就是直連主庫然後下面又跟著從庫的那台）是什麼角色呢。

可以看到，中間的那個redis從庫依然是從庫的角色，但是下面又跟著小弟。但是呢這個時候還是無法執行write的操作，因為中間的那個依舊是從庫的角色

redis的主從複製，讀寫分離就到告一段落了，下一次為大家繼續講解redis叢集的哨兵模式