Redis主從複製
主從複製，是指將一臺Redis服務器的數據，複製到其他的Redis服務器。前者稱爲主節點
(master/leader)，後者稱爲從節點(slave/follower)；數據的複製是單向的，只能由主節點到從節點。
Master以寫爲主，Slave 以讀爲主。
默認情況下，每臺Redis服務器都是主節點。
且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點。
主從複製的作用
1、數據冗餘：主從複製實現了數據的熱備份，是持久化之外的一種數據冗餘方式。
2、故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務的冗餘。
3、負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務
（即寫Redis數據時應用連接主節點，讀Redis數據時應用連接從節點），分擔服務器負載；尤其是在寫少讀多的場景下，通過多個從節點分擔讀負載，可以大大提高Redis服務器的併發量。
4、高可用（集羣）基石：除了上述作用以外，主從複製還是哨兵和集羣能夠實施的基礎，因此說主從複製是Redis高可用的基礎。
一般來說，要將Redis運用於工程項目中，只使用一臺Redis是萬萬不能的（宕機），原因如下：
1、從結構上，單個Redis服務器會發生單點故障，並且一臺服務器需要處理所有的請求負載，壓力較
大。
2、從容量上，單個Redis服務器內存容量有限，就算一臺Redis服務器內存容量爲256G，也不能將所有內存用作Redis存儲內存，一般來說，單臺Redis最大使用內存不應該超過20G。
電商網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是"多讀少寫"。對於這種場景，我們可以使如下這種架構：
主從複製，讀寫分離！80%的情況下都是進行讀操作，用於減緩服務器的壓力，架構中經常使用。至少要保證一主二從，在公司中，主從複製是必須要使用的。
查看當前庫的信息
127.0.0.1:6379> info replication # 查看當前庫的信息
# Replication
role:master # 角色master - 表示是主機
connected_slaves:0 # 0表示沒有從機
master_replid:b63c90e6c501143759cb0e7f450bd1eb0c70882a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
Linux - Redis集羣環境搭建
這裏是在一臺服務器上進行集羣，並且配置模式爲一主二從，因此複製3份redis.conf文件，並別改名爲redis79.conf、redis80.conf、redis81.conf，命令如下：
先進入到redis.conf所在目錄下
cp redis.conf redis79.conf
cp redis.conf redis80.conf
cp redis.conf redis81.conf
在複製完配置文件之後，需要對每個配置文件進行修改（因爲是在同一臺服務器裏，即單機多服務，如果是多臺服務器可以不用修改），這裏以redis79.conf爲例
port 6379 # 啓動端口
daemonzie yes # 守護態運行
pidfile /var/run/redis_6379.pid # pid_file
logfile "6379.log" # 日誌文件名
dbfilename dump6379.rdb # rdb文件名
啓動3個redis服務
redis-server kconfig/redis79.conf
redis-server kconfig/redis80.conf
redis-server kconfig/redis81.conf
查看進程信息
ps -ef|grep redis
配置一主二從
分別連接客戶端，建議開三個Linux遠程連接來操作
redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381
使用命令進行配置
真實開發中，從主配置應該在配置文件中配置，這樣的話是永久的，這裏使用的是命令，只是暫時的！
因爲默認情況下，每臺Redis服務器都是主節點，所以我們只需要配置從節點即可。通俗點說，就是讓從機去認主機(小弟認大哥)。
我們這裏是讓6380和6381作爲從機，所以操作這兩個即可，以6380爲例：
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 # SLAVEOF host 6379，找主機(認大哥)
OK
127.0.0.1:6380> info replication # 查看當前庫的信息
# Replication
role:slave # slave，當前角色是從機
master_host:127.0.0.1 # 主機IP
master_port:6379 # 主機端口
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14
修改配置文件進行配置
修改從機的redis.conf配置文件，真實開發中的配置方式。
# 將註釋打開，配置主機ip和端口
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379
# 如果主機有密碼，則還需配置密碼，打開註釋
# masterauth <master-password>
masterauth 123456
讀寫分離細節
主機可以寫，但是從機不能寫只能讀。主機中的所有信息和數據，都會自動被從機保存。
當主機斷開連接，從機依舊連接到主機，但是沒有寫操作，如果主機回來了，從機依舊可以直接獲取到主機寫的信息。
當從機斷開連接，主機進行了寫操作，此時從機再連接回來，從機還是可以讀取到斷開這段時間主機寫的信息。
如果是使用命令行來配置主從的話，主機重啓之後依然是主機，但是從機重啓之後不再是從機，需要從新配置，一旦變回從機，依舊可以從主機中獲取信息。
從機複製原理
Slave 啓動成功連接到 master 後會發送一個sync同步命令。
Master 接到命令，啓動後臺的存盤進程，同時收集所有接收到的用於修改數據集命令，在後臺進程執行完畢之後，master將傳送整個數據文件到slave，並完成一次完全同步。
全量複製：而slave服務在接收到數據庫文件數據後，將其存盤並加載到內存中。
增量複製：Master 繼續將新的所有收集到的修改命令依次傳給slave，完成同步。
但是只要是重新連接master，一次完全同步（全量複製）將被自動執行！ 我們的數據一定可以在從機中看到！
鏈表式主從複製
哨兵模式
上面所說的兩種主從方式在實際開發中都不會用。
如果主機down掉了，這個時候可不可以選擇一個一個從機變成主機(謀權篡位)呢？
在哨兵模式出來之前，可以通過手動的方式來實現。
使用SLAVEOF no one命令可以讓自己變成主機，其他從機就可以手動連接到最新的這個主機(手動連接)。如果原來的主機回來了，沒辦法，也只能重新配置和連接了。
哨兵模式概述
即自動選舉主機的模式。
主從切換技術的方法是：當主服務器宕機後，需要手動把一臺從服務器切換爲主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵） 架構來解決這個問題。
謀權篡位的自動版，能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換爲主庫。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作爲進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
這裏的哨兵有兩個作用：
1、通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
2、當哨兵監測到master宕機，會自動將slave切換成master，然後通過發佈訂閱模式通知其他的從服
務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，爲此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。（類似於Eureka集羣）
假設主服務器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認爲主服務器不可用，這個現象成爲主觀下線。當後面的哨兵也檢測到主服務器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。切換成功後，就會通過發佈訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱爲客觀下線。
哨兵模式配置
文中是使用一主二從的方式，因此哨兵也可以選擇3個(如果服務器是學生機的配置，可能承受不了，則可以只做一個)。
分別給6379、6380、6381配置一個sentinel.conf。即sentinel26379.conf、sentinel26380.conf、sentinel26381.conf。
這裏以sentinel26380.conf爲例進行配置：
port 26379 # 哨兵端口
daemonize yes # 守護態運行
logfile "26379.log" # 日誌文件
dir "./" # 哨兵工作目錄
bind 127.0.0.1 # 綁定ip 多個ip使用空格隔開
# 告訴sentinel去監聽地址爲ip:port的一個master，這裏的master-name可以自定義，quorum是一個數字，指明當有多少個sentinel認爲一個master失效時，master纔算真正失效
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 設置連接master和slave時的密碼，注意的是sentinel不能分別爲master和slave設置不同的密碼，因此master和slave的密碼應該設置相同。如果沒有密碼，可以不寫。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 指定多少毫秒之後 主節點沒有應答哨兵sentinel 此時 哨兵主觀上認爲主節點下線 默認30秒,單位毫秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步，這個數字越小，完成failover所需的時間就越長，但是如果這個數字越大，就意味着越多的slave因爲replication而不可用。可以通過將這個值設爲 1 來保證每次只有一個slave 處於不能處理命令請求的狀態。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障轉移的超時時間 failover-timeout 可以用在以下這些方面：
# 1.同一個sentinel對同一個master兩次failover之間的間隔時間。
# 2.當一個slave從一個錯誤的master那裏同步數據開始計算時間。直到slave被糾正爲向正確的master那裏同步數據時。
# 3.當想要取消一個正在進行的failover所需要的時間。
# 4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時，slaves依然會被正確配置爲指向master，但是就不按parallel-syncs所配置的規則來了
# 默認三分鐘,單位毫秒
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout 180000
配置完畢之後，分別啓動sentinel
redis-sentinel kconfig/sentinel23679.conf
redis-sentinel kconfig/sentinel23680.conf
redis-sentinel kconfig/sentinel23681.conf
此時，哨兵模式配置完畢，此外還可以再配置文件裏配置一些額外信息如：
# SCRIPTS EXECUTION
#配置當某一事件發生時所需要執行的腳本，可以通過腳本來通知管理員，例如當系統運行不正常時發郵件通知相關人員。
#對於腳本的運行結果有以下規則：
#若腳本執行後返回1，那麼該腳本稍後將會被再次執行，重複次數目前默認爲10
#若腳本執行後返回2，或者比2更高的一個返回值，腳本將不會重複執行。
#如果腳本在執行過程中由於收到系統中斷信號被終止了，則同返回值爲1時的行爲相同。
#一個腳本的最大執行時間爲60s，如果超過這個時間，腳本將會被一個SIGKILL信號終止，之後重新執行。
#通知型腳本:當sentinel有任何警告級別的事件發生時（比如說redis實例的主觀失效和客觀失效等等），
#將會去調用這個腳本，這時這個腳本應該通過郵件，SMS等方式去通知系統管理員關於系統不正常運行的信
#息。調用該腳本時，將傳給腳本兩個參數，一個是事件的類型，一個是事件的描述。如果sentinel.conf配
#置文件中配置了這個腳本路徑，那麼必須保證這個腳本存在於這個路徑，並且是可執行的，否則sentinel無
#法正常啓動成功。
#通知腳本
# shell編程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客戶端重新配置主節點參數腳本
# 當一個master由於failover而發生改變時，這個腳本將會被調用，通知相關的客戶端關於master地址已
# 經發生改變的信息。
# 以下參數將會在調用腳本時傳給腳本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>總是“failover”,
# <role>是“leader”或者“observer”中的一個。
# 參數 from-ip, from-port, to-ip, to-port是用來和舊的master和新的master(即舊的slave)通信的
# 這個腳本應該是通用的，能被多次調用，不是針對性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由運維來配置
更多可以參考博客：Redis高可用之哨兵模式Sentinel配置與啓動(五)