1.redis replication的核心機制

(1).redis採用非同步方式複製資料到slave節點，不過redis 2.8開始，slave node會週期性地確認自己每次複製的資料量
(2).一個master node是可以配置多個slave node的
(3).slave node也可以連線其他的slave node
(4).slave node做複製的時候，是不會阻止 master node的正常工作的
(5).slave node在做複製的時候，也不會阻止對自己的查詢操作，它會用舊的資料集來提供服務; 但是複製完成的時候，需要刪除舊資料集，載入新資料集，這個時候就會暫停對外服務了
(6).slave node主要用來進行橫向擴容，做讀寫分離，擴容的slave node可以提高讀的吞吐量
 

2.master持久化對於主從架構的安全保障的意義

如果採用了主從架構，那麼建議必須開啟master node的持久化！不建議用slave node作為master node的資料熱備，因為那樣的話，如果你關掉master的持久化，可能在master宕機重啟的時候資料是空的，然後可能一經過複製，salve node資料也丟了
master一定要做備份方案，萬一本地的所有檔案丟失了; 從備份中挑選一份rdb去恢復master; 這樣才能確保master啟動的時候，是有資料的。即使採用了高可用機制，slave node可以自動接管master node，但是也可能sentinal還沒有檢測到master failure，master node就自動重啟了，還是可能導致上面的所有slave node資料清空故障
 

3.Redis主從架構的核心原理

當啟動一個slave node的時候，它會發送一個PSYNC命令給master node，如果這時候slave node重新連線master node，那麼master node僅僅會複製給slave部分缺少的資料; 否則如果是slave node第一次連線master node，那麼會觸發一次full resynchronization。
開始full resynchronization的時候，master會啟動一個後臺執行緒，開始生成一份RDB快照檔案，同時還會將從客戶端收到的所有寫命令快取在記憶體中。RDB檔案生成完畢之後，master會將這個RDB傳送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到記憶體中。然後master會將記憶體中快取的寫命令非同步的傳送給slave，slave也會同步這些資料。
slave node如果跟master node有網路故障，斷開了連線，會自動重連。master如果發現有多個slave node都來重新連線，僅僅會啟動一個rdb save操作，用一份資料服務所有slave node。
 

4.主從複製的斷點續傳

從redis 2.8開始，就支援主從複製的斷點續傳，如果主從複製過程中，網路連線斷掉了，那麼可以接著上次複製的地方，繼續複製下去，而不是從頭開始複製一份。master node會在記憶體中建立一個backlog，master和slave都會儲存一個replica offset還有一個master id，offset就是儲存在backlog中的。如果master和slave網路連線斷掉了，slave會讓master從上次的replica offset開始繼續複製，但是如果沒有找到對應的offset，那麼就會執行一次全量複製。

5.無磁碟化複製（增量複製的策略）

slave node如果跟master node有網路故障，斷開了連線，這時候又重新連線，master最近增加的資料可以通過無磁碟化的方式複製到slave。

master在記憶體中直接建立rdb，然後傳送給slave，不會在自己本地落地磁碟了
repl-diskless-sync=yes
repl-diskless-sync-delay 5，等待一定時長再開始複製，因為要等更多slave重新連線過來

6.過期key處理

slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令傳送給slave。

7.複製的完整流程

(1).slave node啟動，僅僅儲存master node的資訊，包括master node的host和ip(redis.conf裡面的slaveof配置的)，但是複製流程沒開始
(2).slave node內部有個定時任務，每秒檢查是否有新的master node要連線和複製，如果發現，就跟master node建立socket網路連線
(3).slave node傳送ping命令給master node
(4).口令認證，如果master設定了requirepass，那麼salve node必須傳送masterauth的口令過去進行認證
(5).master node第一次執行全量複製，將所有資料發給slave node
(6).master node後續持續將寫命令，非同步複製給slave node

8.資料同步相關的核心機制(指的就是第一次slave連線msater的時候，執行的全量複製，那個過程裡面你的一些細節的機制)

(1).master和slave都會維護一個offset，master會在自身不斷累加offset，slave也會在自身不斷累加offset，slave每秒都會上報自己的offset給master，同時master也會儲存每個slave的offset（這個倒不是說特定就用在全量複製的，主要是master和slave都要知道各自的資料的offset，才能知道互相之間的資料不一致的情況）
(2).backlog
    master node有一個backlog，預設是1MB大小
    master node給slave node複製資料時，也會將資料在backlog中同步寫一份
    backlog主要是用來做全量複製中斷後的增量複製的
(3).master run id
    info server，可以看到master run id
    如果根據host+ip定位master node，是不靠譜的，如果master node重啟或者資料出現了變化，那麼slave node應該根據不同的run id區分，run id不同就做全量複製
    如果需要不更改run id重啟redis，可以使用redis-cli debug reload命令
(4).psync
    從節點使用psync從master node進行復制，psync runid offset
    master node會根據自身的情況返回響應資訊，可能是FULLRESYNC runid offset觸發全量複製，可能是CONTINUE觸發增量複製

9.全量複製

(1).master執行bgsave，在本地生成一份rdb快照檔案
(2).master node將rdb快照檔案傳送給salve node，如果rdb複製時間超過60秒（repl-timeout），那麼slave node就會認為複製失敗，可以適當調節大這個引數
(3).對於千兆網絡卡的機器，一般每秒傳輸100MB，6G檔案，很可能超過60s
(4).master node在生成rdb時，會將所有新的寫命令快取在記憶體中，在salve node儲存了rdb之後，再將新的寫命令複製給salve node
(5).client-output-buffer-limit slave 256MB 64MB 60，如果在複製期間，記憶體緩衝區持續消耗超過64MB，或者一次性超過256MB，那麼停止複製，複製失敗
(6).slave node接收到rdb之後，清空自己的舊資料，然後重新載入rdb到自己的記憶體中，salve none在接收的過程中仍然基於舊的資料版本對外提供服務
(7).如果slave node開啟了AOF，那麼會立即執行BGREWRITEAOF，重寫AOF

rdb生成、rdb通過網路拷貝、slave舊資料的清理、slave aof rewrite，很耗費時間,如果複製的資料量在4G~6G之間，那麼很可能全量複製時間消耗到1分半到2分鐘

10.增量複製

(1).如果全量複製過程中，master-slave網路連線斷掉，那麼salve重新連線master時，會觸發增量複製
 (2).master直接從自己的backlog中獲取部分丟失的資料，傳送給slave node，預設backlog就是1MB
 (3).msater就是根據slave傳送的psync中的offset來從backlog中獲取資料的

11.heartbeat

主從節點互相都會發送heartbeat資訊,master預設每隔10秒傳送一次heartbeat，salve node每隔1秒傳送一個heartbeat

12.非同步複製

master每次接收到寫命令之後，先在內部寫入資料，然後非同步傳送給slave node

13.啟用複製，部署slave node

wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd  /usr/local/tcl8.6.1/unix/
./configure  
make && make install

使用redis-3.2.8.tar.gz（截止2017年4月的最新穩定版）
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test && make install

(1).redis utils目錄下，有個redis_init_script指令碼
(2).將redis_init_script指令碼拷貝到linux的/etc/init.d目錄中，將redis_init_script重新命名為redis_6379，6379是我們希望這個redis例項監聽的埠號
(3).修改redis_6379指令碼的第6行的REDISPORT，設定為相同的埠號（預設就是6379）
(4).建立兩個目錄：/etc/redis（存放redis的配置檔案），/var/redis/6379（存放redis的持久化檔案）
(5).修改redis配置檔案（預設在根目錄下，redis.conf），拷貝到/etc/redis目錄中，修改名稱為6379.conf
 (6).修改redis.conf中的部分配置為生產環境

daemonize    yes                            讓redis以daemon程序執行
pidfile        /var/run/redis_6379.pid     設定redis的pid檔案位置
port        6379                        設定redis的監聽埠號
dir         /var/redis/6379                設定持久化檔案的儲存位置

(7).讓redis跟隨系統啟動自動啟動
    在redis_6379指令碼中，最上面，加入兩行註釋
    # chkconfig:   2345 90 10
    # description:  Redis is a persistent key-value database
    chkconfig redis_6379 on
    在slave node上配置：slaveof 192.168.1.1 6379，即可,也可以使用slaveof命令

14.強制讀寫分離

基於主從複製架構，實現讀寫分離
redis slave node只讀，預設開啟，slave-read-only
開啟了只讀的redis slave node，會拒絕所有的寫操作，這樣可以強制搭建成讀寫分離的架構

15.叢集安全認證

master上啟用安全認證，requirepass
master連線口令，masterauth

16.讀寫分離架構的測試

先啟動主節點，eshop-cache01上的redis例項
再啟動從節點，eshop-cache02上的redis例項

如果redis slave node一直說沒法連線到主節點的6379的埠,在搭建生產環境的叢集的時候，不要忘記修改一個配置(bind)
bind 127.0.0.1 -> 本地的開發除錯的模式，就只能127.0.0.1本地才能訪問到6379的埠

每個redis.conf中的bind 127.0.0.1 -> bind自己的ip地址
在每個節點上都: iptables -A INPUT -ptcp --dport  6379 -j ACCEPT

redis-cli -h ipaddr
info replication

17.對redis讀寫分離架構進行壓測，單例項寫QPS+單例項讀QPS

你如果要對自己剛剛搭建好的redis做一個基準的壓測，測一下你的redis的效能和QPS（query per second）
redis自己提供的redis-benchmark壓測工具，是最快捷最方便的，當然啦，這個工具比較簡單，用一些簡單的操作和場景去壓測
redis-3.2.8/src
./redis-benchmark -h 192.168.31.187

-c <clients>       Number of parallel connections (default 50)
-n <requests>      Total number of requests (default 100000)
-d <size>          Data size of SET/GET value in bytes (default 2)

根據你自己的高峰期的訪問量，在高峰期，瞬時最大使用者量會達到10萬+，-c 100000，-n 10000000，-d 50

1核1G，虛擬機器

====== PING_INLINE ======
                    100000 requests completed in 1.28 seconds
                    50 parallel clients
                    3 bytes payload
                    keep alive: 1

99.78% <= 1 milliseconds
99.93% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds
78308.54 requests per second

引用於：https://www.cnblogs.com/z-3FENG/p/9603294.html