Redis主從配置

redis主從複製過程  

Redis使用異步複製，當配置好slave後，slave與master創建鏈接，而後發送sync命令。不管是第一次鏈接仍是從新鏈接，master都會啓動一個後臺進程，將 數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令並緩存。後臺進程完成寫文件後，master就發送文件給slave，slave將 文件保存到硬盤上，再加載到內存中，接着master就會把緩存的命令轉發給slave，後續master將收到的寫命令發送給slave。

若是master同時收到多個slave發來的同步鏈接命令，master只會啓動一個進程來寫數據庫鏡像，而後發送給全部的slave。master同步數據時是非阻塞式的，能夠接收用戶的讀寫請求。然而在slave端是阻塞模式的，slave在同步master數據時，並不可以響應客戶端的查詢。從服務器會週期性的應答從複製流中處理的數據量。

能夠一主多從，從服務器是隻讀的（

從Redis 2.6開始，從服務器支持只讀模式，而且是默認模式。這個行爲是由Redis.conf文件中的slave-read-only 參數控制的，能夠在運行中經過CONFIG SET來啓用或者禁用。從服務器像DEBUG或者CONFIG這樣的管理命令仍是能夠運行的。不過你能夠經過使用rename-command命令來爲這些命令更名來增長安全性），主服務器進行讀寫時，會轉移到從讀，減輕服務器壓力，主從均可以設置密碼，也能夠密碼不一致

當主從服務器之間的鏈接因爲某些緣由斷開時，從服務器能夠自動進行重鏈接。當有多個從服務器同時請求同步時，主服務器只進行一個後臺存儲。

 

從Redis 2.8版本開始，能夠配置主服務器鏈接N個以上從服務器才容許對主服務器進行寫操做。可是，由於Redis使用的是異步主從複製，

沒辦法確保從服務器確實收到了要寫入的數據，因此仍是有必定的數據丟失的可能性。

工做原理以下：

1）從服務器每秒鐘ping一次主服務器，確認處理的複製流數量。

2）主服務器記住每一個從服務器最近一次ping的時間。

3）用戶能夠配置最少要有N個服務器有小於M秒的確認延遲。

4）若是有N個以上從服務器，而且確認延遲小於M秒，主服務器接受寫操做。

 

還能夠把這看作是CAP原則（一致性，可用性，分區容錯性）不嚴格的一致性實現，雖然不能百分百確保一致性，但至少保證了丟失的數據不會超過M秒內的數據量。

 

若是條件不知足，主服務器會拒絕寫操做並返回一個錯誤。

1）min-slaves-to-write（最小從服務器數）

2）min-slaves-max-lag（從服務器最大確認延遲）

當鏈接斷開又從新連上以後，通常都會進行一個完整的從新同步，可是從Redis2.8開始，只從新同步一部分也能夠。

部分從新同步工做原理是這樣：

主服務器端爲複製流維護一個內存緩衝區（in-memory backlog）。主從服務器都維護一個複製偏移量（replication offset）和master run id ，

當鏈接斷開時，從服務器會從新鏈接上主服務器，而後請求繼續複製，假如主從服務器的兩個master run id相同，而且指定的偏移量在內存緩衝

區中還有效，複製就會從上次中斷的點開始繼續。若是其中一個條件不知足，就會進行徹底從新同步（在2.8版本以前就是直接進行徹底從新同步）。

由於主運行id不保存在磁盤中，若是從服務器重啓了的話就只能進行徹底同步了。

 

部分從新同步這個新特性內部使用PSYNC命令，舊的實現中使用SYNC命令。Redis2.8版本能夠檢測出它所鏈接的服務器是否支持PSYNC命令，不支持的

話使用SYNC命令。

一個徹底從新同步須要在磁盤上建立一個RDB文件，而後加載這個文件以便爲從服務器發送數據。

 

若是使用比較低速的磁盤，這種操做會給主服務器帶來較大的壓力。Redis從2.8.18版本開始嘗試支持無磁盤的複製。

使用這種設置時，子進程直接將RDB經過網絡發送給從服務器，不使用磁盤做爲中間存儲。

使用repl-diskless-sync配置參數來啓動無磁盤複製。使用repl-diskless-sync-delay 參數來配置傳輸開始的延遲時間，以便等待

更多的從服務器鏈接上來。

配置

我這裏是一臺機器上多實例配置主從，採用一主三從，經過haproxy作從的分發。

master:6379

slave:6380、638一、6382

haproxy:6378

master

[root@localhost redis]# cat etc/redis6379.conf |grep -v "#"|sed "/^[[:space:]]*$/d"
daemonize yes
pidfile /var/run/redis_6379.pid
port 6379
logfile /app/redis/logs/redis6379.log
databases 16
save 900 1
save 300 10
save 60 10000
dbfilename 6379.rdb
dir /app/redis/data/
requirepass ywbz@4.117
......
[root@localhost bin]# ./redis-cli -p 6379 -a ywbz@4.117
127.0.0.1:6379> info
......
# Replication
role:master
connected_slaves:3
slave0:ip=127.0.0.1,port=6381,state=online,offset=128886182724,lag=0
slave1:ip=127.0.0.1,port=6380,state=online,offset=128886182724,lag=0
slave2:ip=127.0.0.1,port=6382,state=online,offset=128886120626,lag=1
master_replid:9744431b03d430d64ace5aefd18aa54d3d99b317
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:128886182724
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:128885134149
repl_backlog_histlen:1048576
......
127.0.0.1:6379> quit
[root@localhost bin]#

slave

[root@localhost redis]# cat etc/redis6380.conf |grep -v "#"|sed "/^[[:space:]]*$/d"
daemonize yes
pidfile /var/run/redis_6380.pid
port 6380
logfile /app/redis/logs/redis6380.log
databases 16
save 900 1
save 300 10
save 60 10000
dbfilename 6380.rdb
dir /app/redis/data/
slaveof 127.0.0.1 6379
masterauth ywbz@4.117
requirepass ywbz@4.117
[root@localhost bin]# ./redis-cli -p 6380 -a ywbz@4.117
127.0.0.1:6380> info
......
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:128890251317
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:9744431b03d430d64ace5aefd18aa54d3d99b317
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:128890251317
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:128889202742
repl_backlog_histlen:1048576
......
127.0.0.1:6380> quit
[root@localhost bin]#