一、主從模式（也有稱為復制的）
主從模式在其他如mysql的數據庫中應該也是有相同原理的應用，大致也可稱為讀寫分離；其中又涉及主數據庫和從數據庫。
寫數據庫一般為主數據庫，讀數據庫則為從數據庫。
目前作者所涉及的項目大部分也都是讀為多，通過讀寫分離，可以有效將負載分擔到不同配置的服務中（由於不清楚讀寫應該如何合理分配CPU、內存、硬盤等，就不亂誤導人了）。
因為上述的原因，一般從數據庫會多一些
缺點：由於寫數據庫的寫入操作和分發給從服務器的同步操作是異步進行的，所以存在主從數據不一致的可能性
* 如果只是一台主數據庫，多台從數據庫，則無法保證高可用性(需要手動維護，切換主數據庫)
大致的原理：
1、主數據庫（寫）是正常配置
2、在從數據庫中配置跟隨的主數據庫
3、主數據庫接收到sync指令后，通過RDB快照當前的數據庫，結束后發送給從服務器，且同時創建一個隊列來保存快照創建期間以及之后產生的操作
4、從數據庫接收到快照后，在本地執行；且接收主數據庫隊列的增量同步數據
5、所有寫的操作都通過主數據庫，而主數據庫通過異步執行的方式向從服務器推送增量數據進行同步
6、大部分的讀操作都從從數據庫中進行
7、雖然redis是單線程的，但是不代表所有的操作都是單線程，只是主線程是單線程模式。而為了保持redis的高性能讀寫，主數據的寫入操作和從數據庫之間的數據同步是異步進行的
如何配置：
配置文件中增加（僅從數據庫配置）：
5.0之后：
REPLICAOF localhost 6379
之前
SLAVEOF localhost 6379
主數據庫掛掉的話，只能手動切換，取消從服務的命令
REPLICAOF no one
二、哨兵模式
顧名思義，哨兵就是站崗-監控的意思。那么監控什么呢？這就要從一主多從說起，一個主數據庫如果崩潰了，那么服務就都中斷了，那么哨兵相對應的就是解決這個問題。
當主數據庫掛了，可以通過哨兵監控（也可以用守護線程來幫助理解），將從服務器轉化為主服務器。哨兵之間也可以互相監控。
配置：
1、我這邊是直接用源碼提供的util目錄中的install腳本，安裝了3個端口的redis-server服務，參考：https://www.cnblogs.com/gabin/p/13652357.html
2、在/etc/redis/對應的配置文件中增加
sentinel monitor master 127.0.0.1 6379 2
最后一個數字表示投票選舉新的主節點的時候，最少的投票數量
3、然后在/etc/init.d/對應的配置中，追加--sentinel 啟動
4、重啟服務：service redis_6XXX restart
ps：哨兵模式下，會自動修改配置文件，且默認應該是輪詢模式，看日志，服務掛掉之后並沒有非常實時地切換主節點
三、集群（Cluster）模式
可以將集群模式當做是在哨兵模式的基礎上，增加了水平擴展和切片的功能。
即使采用了哨兵模式，系統還是可能存在數據量越來越大的情況，這種情況下，可能需要對數據進行服務端切片（客戶端切片一般指，不同的客戶端根據需要連接不同的redis數據庫）
集群模式實現了服務端的分片功能
- 客戶端分區就是在客戶端就已經決定數據會被存儲到哪個redis節點或者從哪個redis節點讀取。大多數客戶端已經實現了客戶端分區。
- 代理分區 意味着客戶端將請求發送給代理，然后代理決定去哪個節點寫數據或者讀數據。代理根據分區規則決定請求哪些Redis實例，然后根據Redis的響應結果返回給客戶端。redis和memcached的一種代理實現就是Twemproxy
- 查詢路由(Query routing) 的意思是客戶端隨機地請求任意一個redis實例，然后由Redis將請求轉發給正確的Redis節點。Redis Cluster實現了一種混合形式的查詢路由，但並不是直接將請求從一個redis節點轉發到另一個redis節點，而是在客戶端的幫助下直接redirected到正確的redis節點。
上述都是比較粗淺的認知，待補充大致的原理部分