Redis 主從複製、讀寫分離、高可用（七）-part 1
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）
那麼接下來就是修改配置了
1.主機配置介紹（為了說明在主從複製的時候訪問的不是同一個資料庫檔案，將資料庫檔名也相應的修改）
2.從機配置介紹
OK配置完成了，那麼接下來就是啟動redis服務並連線，檢視配置是否有效
通過info replication命令檢視資訊
我們可以看到，3臺伺服器的redis服務成功啟動，角色都是master，那麼接下來就是要區分主從庫了，通過命令slaveof 主機IP 主機redis埠
slaveof 127.0.0.1 6379
那麼這個時候在主庫中執行寫的操作
在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的操作，因為中間的那個依舊是從庫的角色
ps:若主宕機了，從會一直等待（後面會用 哨兵解決這個問題）