ip分布情況：

sentinel-1/redis 主	10.11.11.5
sentinel-2/redis 從	10.11.11.7
sentinel-3/redis 從	10.11.11.8
haproxy	10.11.11.10

?

軟件版本：

redis-2.8.20-3.el6.art.x86_64.rpm

haproxy-1.5.4-3.el6.x86_64

?

開始配置：

一 、redis配置

1.1 redis 主配置： /etc/redis.conf，詳細參考http://yijiebuyi.com/blog/bc2b3d3e010bf87ba55267f95ab3aa71.html

daemonize yes  #Redis默認不是以守護進程的方式運行，可以通過該配置項修改，使用yes啟用守護進程
pidfile "/var/run/redis/redis.pid" #當Redis以守護進程方式運行時，Redis默認會把pid寫入/var/run/redis.pid文件，可以通過pidfile指定
port 6379  #指定Redis監聽端口，默認端口為6379
tcp-backlog 511 # TCP接收隊列長度，受/proc/sys/net/core/somaxconn和tcp_max_syn_backlog這兩個內核參數的影響
bind 10.11.11.5 #綁定的主機地址
timeout 0 #當 客戶端閑置多長時間后關閉連接，如果指定為0，表示關閉該功能
tcp-keepalive 0 # 如果非零，則設置SO_KEEPALIVE選項來向空閑連接的客戶端發送ACK
loglevel notice
## debug （大量信息，對開發/測試有用）
## verbose （很多精簡的有用信息，但是不像debug等級那么多）
## notice （適量的信息，基本上是你生產環境中需要的）
## warning （只有很重要/嚴重的信息會記錄下來

logfile "/var/log/redis/redis.log" #日志名
databases 16 #設置數據庫的數量，可以使用SELECT <dbid>命令在連接上指定數據庫id
save 900 1
save 300 10
save 60 10000
#指定在多長時間內，有多少次更新操作，就將數據同步到數據文件，可以多個條件配合save <seconds> <changes>
#分別表示900秒（15分鐘）內有1個更改，300秒（5分鐘）內有10個更改以及60秒內有10000個更改。
stop-writes-on-bgsave-error yes
# 默認如果開啟RDB快照(至少一條save指令)并且最新的后臺保存失敗，Redis將會停止接受寫操作
# 這將使用戶知道數據沒有正確的持久化到硬盤，否則可能沒人注意到并且造成一些災難
rdbcompression yes #指定存儲至本地數據庫時是否壓縮數據，默認為yes，Redis采用LZF壓縮，如果為了節省CPU時間，可以關閉該選項，但會導致數據庫文件變的巨大
rdbchecksum yes
dbfilename "dump.rdb"  #指定本地數據庫文件名，默認值為dump.rdb
dir "/var/lib/redis"  #指定本地數據庫存放目錄
slave-serve-stale-data yes# 當從庫同主機失去連接或者復制正在進行，從機庫有兩種運行方式：
#
# 1) 如果slave-serve-stale-data設置為yes(默認設置)，從庫會繼續相應客戶端的請求
# 
# 2) 如果slave-serve-stale-data是指為no，出去INFO和SLAVOF命令之外的任何請求都會返回一個
#    錯誤"SYNC with master in progress"
slave-read-only yes
##你可以配置salve實例是否接受寫操作?？蓪懙膕lave實例可能對存儲臨時數據比較有用(因為寫入salve
##的數據在同master同步之后將很容易被刪除
repl-disable-tcp-nodelay no # 從庫會按照一個時間間隔向主庫發送PINGs.可以通過repl-ping-slave-period設置這個時間間隔，默認是10秒

slave-priority 100
# slave的優先級是一個整數展示在Redis的Info輸出中。如果master不再正常工作了，哨兵將用它來
# 選擇一個slave提升=升為master。
# 優先級數字小的salve會優先考慮提升為master，所以例如有三個slave優先級分別為10，100，25，
# 哨兵將挑選優先級最小數字為10的slave。
# 0作為一個特殊的優先級，標識這個slave不能作為master，所以一個優先級為0的slave永遠不會被
# 哨兵挑選提升為master
appendonly no# 默認情況下，redis會在后臺異步的把數據庫鏡像備份到磁盤，但是該備份是非常耗時的，而且備份也不能很頻繁，如果發生諸如拉閘限電、拔插頭等狀況，那么將造成比較大范圍的數據丟失。
# 所以redis提供了另外一種更加高效的數據庫備份及災難恢復方式。
# 開啟append only模式之后，redis會把所接收到的每一次寫操作請求都追加到appendonly.aof文件中，當redis重新啟動時，會從該文件恢復出之前的狀態。
# 但是這樣會造成appendonly.aof文件過大，所以redis還支持了BGREWRITEAOF指令，對appendonly.aof 進行重新整理。
# 你可以同時開啟asynchronous dumps 和 AOF
appendfilename "appendonly.aof" # AOF文件名稱 (默認: "appendonly.aof")
appendfsync everysec
# Redis支持三種同步AOF文件的策略:
#
# no: 不進行同步，系統去操作 . Faster.
# always: always表示每次有寫操作都進行同步. Slow, Safest.
# everysec: 表示對寫操作進行累積，每秒同步一次. Compromise.
#
# 默認是"everysec"，按照速度和安全折中這是最好的。
# 如果想讓Redis能更高效的運行，你也可以設置為"no"，讓操作系統決定什么時候去執行
# 或者相反想讓數據更安全你也可以設置為"always"
#
# 如果不確定就用 "everysec".# appendfsync always
no-appendfsync-on-rewrite no
# AOF策略設置為always或者everysec時，后臺處理進程(后臺保存或者AOF日志重寫)會執行大量的I/O操作
# 在某些Linux配置中會阻止過長的fsync()請求。注意現在沒有任何修復，即使fsync在另外一個線程進行處理
#
# 為了減緩這個問題，可以設置下面這個參數no-appendfsync-on-rewrite

auto-aof-rewrite-percentage 100  #自動重寫AOF文件
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000 # Lua 腳本的最大執行時間，毫秒為單位
slowlog-log-slower-than 10000   # Redis慢查詢日志可以記錄超過指定時間的查詢
slowlog-max-len 128 # 這個長度沒有限制。只是要主要會消耗內存。你可以通過 SLOWLOG RESET 來回收內存。
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# 當hash只有少量的entry時，并且最大的entry所占空間沒有超過指定的限制時，會用一種節省內存的
# 數據結構來編碼。可以通過下面的指令來設定限制

list-max-ziplist-entries 512
list-max-ziplist-value 64
# 與hash似，數據元素較少的list，可以用另一種方式來編碼從而節省大量空間。
# 這種特殊的方式只有在符合下面限制時才??以用

set-max-intset-entries 512
# set有一種特殊編碼的情況：當set數據全是十進制64位有符號整型數字構成的字符串時。
# 下面這個配置項就是用來設置set使用這種編碼來節省內存的最大長度。

zset-max-ziplist-entries 128
zset-max-ziplist-value 64
# 與hash和list相似，有序集合也可以用一種特別的編碼方式來節省大量空間。
# 這種編碼只適合長度和元素都小于下面限制的有序集合

hll-sparse-max-bytes 3000
# HyperLogLog稀疏結構表示字節的限制。該限制包括
# 16個字節的頭。當HyperLogLog使用稀疏結構表示
# 這些限制，它會被轉換成密度表示。
# 值大于16000是完全沒用的，因為在該點
# 密集的表示是更多的內存效率。
# 建議值是3000左右，以便具有的內存好處, 減少內存的消耗

activerehashing yes # 啟用哈希刷新，每100個CPU毫秒會拿出1個毫秒來刷新Redis的主哈希表（頂級鍵值映射表）

hz 10
# 默認情況下，“hz”的被設定為10。提高該值將在Redis空閑時使用更多的CPU時，但同時當有多個key
# 同時到期會使Redis的反應更靈敏，以及超時可以更精確地處理
aof-rewrite-incremental-fsync yes  # 當一個子進程重寫AOF文件時，如果啟用下面的選項，則文件每生成32M數據會被同步
unixsocket "/var/run/redis/redis.sock"
unixsocketperm 755
maxclients 4064

1.2 redis 從服務器配置

scp 主節點上的/etc/redis.conf配置到從節點的/etc下，然后增加如下配置：

slaveof 10.11.11.5 6379

# 主從復制. 設置該數據庫為其他數據庫的從數據庫. 
# 設置當本機為slav服務時，設置master服務的IP地址及端口，在Redis啟動時，它會自動從master進行數據同步
#
# slaveof <masterip> <masterport>

?

?

?

 1.3 啟動redis 主從上的服務，查看主從狀態

redis-cli -h 10.11.11.5 info Replication，可以看到主從狀態，此時redis主從己配置完成

?

?

二、redis sentinel配置

sentinel介紹請參考：https://segmentfault.com/a/1190000002680804

安裝部署：

編輯sentinel配置文件 ，主要如下

grep -Ev '^#|^$'  /etc/sentinel.conf
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2 #配置master名、ip、port、需要多少個sentinel才能判斷[客觀下線]（2）
sentinel down-after-milliseconds mymaster 30000 #配置sentinel向master發出ping，最大響應時間、超過則認為主觀下線
sentinel parallel-syncs mymaster 1 #配置在進行故障轉移時，運行多少個slave進行數據備份同步(越少速度越快)
sentinel failover-timeout mymaster 180000  #配置當出現failover時下一個sentinel與上一個sentinel對[同一個master監測的時間間

?

sentinel-1 sentinel-2 sentinel-3節點上的配置文件一樣

啟動sentinel，sentinel啟動后中，sentinel.conf和redis.conf都由sentinel來控制，主從切換時會寫入相關配置（redis.conf配置文件從節點會添加slaveof? master ip?? port,主節點去掉slavvof項），啟動后，sentinel.conf配置文件變化：

redis-server?? /etc/sentinel.conf? --sentinel >> /var/log/redis/sentinel.log &

可通過/var/log/redis/sentinel.log日志看到一些相關信息

Sentinel服務啟動后會打印一些相關日志信息，以下是相關日志特殊字符說明：

+reset-master <instance details> ：主服務器已被重置。

+slave <instance details> ：一個新的從服務器已經被 Sentinel 識別并關聯。

+failover-state-reconf-slaves <instancedetails> ：故障轉移狀態切換到了reconf-slaves 狀態。

+failover-detected <instance details>：另一個 Sentinel 開始了一次故障轉移操作，或者一個從服務器轉換成了主服務器。

+slave-reconf-sent <instance details>：領頭（leader）的 Sentinel 向實例發送了 SLAVEOF 命令，為實例設置新的主服務器。

+slave-reconf-inprog <instancedetails> ：實例正在將自己設置為指定主服務器的從服務器，但相應的同步過程仍未完成。

+slave-reconf-done <instance details>：從服務器已經成功完成對新主服務器的同步。

-dup-sentinel <instance details> ：對給定主服務器進行監視的一個或多個 Sentinel 已經因為重復出現而被移除 —— 當 Sentinel 實例重啟的時候，就會出現這種情況。

+sentinel <instance details> ：一個監視給定主服務器的新 Sentinel 已經被識別并添加。

+sdown <instance details> ：給定的實例現在處于主觀下線狀態。

-sdown <instance details> ：給定的實例已經不再處于主觀下線狀態。

+odown <instance details> ：給定的實例現在處于客觀下線狀態。

-odown <instance details> ：給定的實例已經不再處于客觀下線狀態。

+new-epoch <instance details> ：當前的紀元（epoch）已經被更新。

+try-failover <instance details> ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by themajority）。

+elected-leader <instance details> ：贏得指定紀元的選舉，可以進行故障遷移操作了。

+failover-state-select-slave <instancedetails> ：故障轉移操作現在處于select-slave 狀態 —— Sentinel 正在尋找可以升級為主服務器的從服務器。

no-good-slave <instance details> ：Sentinel 操作未能找到適合進行升級的從服務器。Sentinel 會在一段時間之后再次嘗試尋找合適的從服務器來進行升級，又或者直接放棄執行故障轉移操作。

selected-slave <instance details> ：Sentinel 順利找到適合進行升級的從服務器。

failover-state-send-slaveof-noone<instance details> ：Sentinel 正在將指定的從服務器升級為主服務器，等待升級功能完成。

failover-end-for-timeout <instancedetails> ：故障轉移因為超時而中止，不過最終所有從服務器都會開始復制新的主服務器（slaves will eventually be configured to replicate with the newmaster anyway）。

failover-end <instance details> ：故障轉移操作順利完成。所有從服務器都開始復制新的主服務器了。

+switch-master <master name><oldip> <oldport> <newip> <newport> ：配置變更，主服務器的 IP 和地址已經改變。 這是絕大多數外部用戶都關心的信息。

+tilt ：進入 tilt 模式。

-tilt ：退出 tilt 模式。

?

測試驗證

可以對master-slave進行測試，將master關閉，此時slave會自動充當新的new-master；

當old-master恢復后，會充當new-master的slave，即：在這個過程中，sentinel.conf會被改寫，改寫為當前監控的主機master服務；

如下圖測試所示：

Master服務停止：redis-cli -h 10.11.11.5 info Replication? 查看10.11.11.7 為master

?

如圖：master己切換到10.11.11.5

?

三、haproxy 配置，提供負載均衡功能和vip

haproxy 節點：10.11.11.10

vim? /etc/haproxy/haproxy.cfg

globaldaemongroup  haproxylog  /dev/log local0maxconn  16000pidfile  /var/run/haproxy.pidstats  socket /var/lib/haproxy/statstune.bufsize  32768user  haproxydefaultslog  globalmaxconn  8000mode  httpoption  redispatchretries  3stats  enabletimeout  http-request 10stimeout  queue 1mtimeout  connect 10stimeout  client 1mtimeout  server 1mtimeout  check 10slisten stats *:10000mode httpstats enablestats uri /stats refresh 5sstats show-nodestats show-legendsstats hide-versionlisten awredisbind 10.11.11.10:6379balance  leastconnmode  tcpoption tcp-check #redis 健康檢查，確保只有master提供連接tcp-check connect   tcp-check send PING\r\ntcp-check expect string +PONGtcp-check send info\ replication\r\ntcp-check expect string role:mastertcp-check send QUIT\r\ntcp-check expect string +OKserver redis01 10.11.11.5:6379   check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3server redis02 10.11.11.7:6379   check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3server redis03 10.11.11.8:6379   check port 6379 inter 5s fastinter 2s downinter 5s rise 3 fall 3

啟動haproxy 服務，可以通過10.11.11.10：10000端口看haproxy的狀態

?

如圖：只有master 是up狀態

轉載于:https://www.cnblogs.com/tzm7614/p/5691912.html

總結

以上是生活随笔為你收集整理的redis sentinel集群配置及haproxy配置的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。