一、簡介和操作
Redis 讀寫分離的實現非常簡單，就是啟動兩個實例，一個負責讀（稱之為：讀實例），一個負責寫（稱之為：寫實例），讀實例復制寫實例的數據。
這里我以 Windows 環境下舉例，Linux 環境的網上案例更多，它們的思想是一樣的。
首先，准備兩份一模一樣的 Redis 程序，這是 Windows 環境下的目錄，都是免安裝的，拿來即用。
第一個寫實例，我們直接用命令啟動，這里就不演示了，默認的IP和端口號是：127.0.0.1 和 6379。
第二個讀實例，我們就不能用 6379 了，我們換一個用 6380，所以，我們需要修改配置文件，同時，我們需要讀實例去監聽寫實例，所以也要修改這部分內容，改起來特別簡單。
修改默認端口號
指定需要復制的主服務器
修改完以后，我們啟動讀實例，在寫實例上我們 set 一個值，從讀實例上我們就可以 get 到這個數據，這樣就實現了讀寫分離。
二、Redis 讀寫分離是怎么做數據同步的？
進行復制中的主從服務器雙方的數據庫將保存相同的數據，概念上將這種現象稱作“數據庫狀態一致”。
Redis 有兩種持久化數據的方法。一種是：全量持久化（RDB）；另一種是：增量持久化（AOF）。
簡單的形容：全量持久化就是把數據完完全全的復制一遍；增量持久化就是把本次和上次數據進行對比，有差別的地方復制一遍，舊數據+更改數據=現在的數據
Redis 2.8 版本之前使用舊版復制功能 SYNC
SYNC 是一個非常耗費資源的操作。主服務器需要執行 BGSAVE 命令來生成 RDB 文件，這個生成操作會耗主服務器大量的CPU、內存和盤讀寫資源。主服務器將 RDB 文件發送紿從服務器，這個發送操作會耗費主從服務器大量的網絡帶寬和流量，並對主服務器晌應命令請求的時間產生影響：接收到 RDB 文件的從服務器在載入文件的過裎是阻塞的，無法處理命令請求
Redis 2.8 之后使用 PSYNC
PSYNC 命令有完整重同步（full resynchronization 也就是 SYNC）和部分重同步（partial resynchronizationl）兩種模式。部分重同步功能由以下三個部分構成：
- 主服務的復制偏移量（replication offset）和從服務器的復制偏移量。
- 主服務器的復制積壓緩沖區（replication backlog），默認大小為1M。
- 服務器的運行ID（run ID），用於存儲服務器標識，如從服務器斷線重新連接，取到主服務器的運行 ID 與重接后的主服務器運行 ID 進行對比，從而判斷是執行部分重同步還是執行完整重同步。
三、高可用的概念？
高可用HA（High Availability）是分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。
通過三大要點解釋高可用:
- 單點是系統高可用的大敵，應該盡量在系統設計的過程中避免單點。
- 保證系統高可用，架構設計的核心准則是：冗余。
- 每次出現故障需要人工介入恢復勢必會增加系統的不可服務時間，實現自動故障轉移。
- 重啟服務，看服務是否每次都獲取鎖失敗。
四、分布式高可用經典架構環節分析
- 【客戶端層】到【反向代理層】的高可用，是通過反向代理層的冗余來實現的。以 nginx 為例：有兩台 nginx，一台對線上提供服務，另一台冗余以保證高可用， 常見的實踐是 keepalived 存活探測。
- 【反向代理層】到【web 應用】的高可用，是通過站點層的冗余來實現的。假設反向代理層是 nginx，nginx.conf 里能夠配置多個 web 后端，並且 nginx 能夠探測到多個后端的存活性。自動故障轉移：當 web-server 掛了的時候，nginx 能夠探測到，會自動的進行故障轉移，將流量自動遷移到其他的 web-server，整個過程由 nginx 自動完成，對調用方是透明的。
- 【服務層】到【緩存層】的高可用，是通過緩存數據的冗余來實現的。 redis 天然支持主從同步，redis 官方也有 sentinel 哨兵機制，來做 redis 的存活性檢測。
- 【服務層】到【數據庫層】的高可用，數據庫層用“主從同步，讀寫分離”架構，所以數據庫層的高可用，又分為“讀庫高可用”與“寫庫高可用”兩類。讀庫采用冗余的方式實現高可用，寫庫采用 keepalived 存活探測，binlog 進行同步。