redis學習隨筆

時間 2019-11-17

標籤 redis 學習隨筆欄目 Redis 简体版

原文原文鏈接

一：緩存概念：
緩存是爲了調節速度不一致的兩個或多個不一樣的物質的速度，在中間對速度較快的一方起到一個加
速訪問速度較慢的一方的做用，好比 CPU 的一級、二級緩存是保存了 CPU 最近常常訪問的數據，內存是保存 CPU 常常訪問硬盤的數據，並且硬盤也有大小不一的緩存，甚至是物理服務器的 raid 卡有也緩存，都是爲了起到加速 CPU 訪問硬盤數據的目的，由於 CPU 的速度太快了， CPU 須要的數據硬盤每每不能在短期內知足 CPU 的需求，所以 PCU 緩存、內存、 Raid 卡以及硬盤緩存就在必定程度上知足了 CPU 的數據需求，即 CPU 從緩存讀取數據能夠大幅提升 CPU 的工做效率。html

系統緩存java

一、buffer 與 cachenode

buffer：緩衝也叫寫緩衝，通常用於寫操做，能夠將數據先寫入內存在寫入磁盤 buffer 通常用於寫緩衝，用於解決不一樣介質的速度不一致的緩衝，先將數據臨時寫入到裏本身最近的地方，以提升寫入速度， CPU 會把數據線寫到內存的磁盤緩衝區，而後就認爲數據已經寫入完成看，而後內核的線程在後面的時間在寫入磁盤，因此服務器忽然斷電會丟失內存中的部分數據。web

cache：緩存也叫讀緩存，通常用於讀操做 CPU 讀文件從內存讀，若是內存沒有就先從硬盤讀到內存再讀到 CPU 將須要頻繁讀取的數據放在裏本身最近的緩存區域，下次讀取的時候便可快速讀取。redis

二、cache 的保存位置：算法

客戶端：瀏覽器chrome

內存：本地服務器、遠程服務器數據庫

硬盤：本機硬盤、遠程服務器硬盤vim

三、cache 的特性：後端

自動過時：給緩存的數據加上有效時間，超出時間後自動過時刪除

過時時間：強制過時，源網站更新圖片後 CDN 是不會更新的，須要強制是圖片緩存過時

命中率：即緩存的讀取命中率

四、用戶層緩存：

五、DNS 緩存

默認爲60 秒，即 60 秒以內在訪問同一個域名就不在進行 DNS 解析：

查看 chrome 瀏覽器的 DNS 緩存：chrome://netinternals/#dns

火狐瀏覽器緩存：about:cache

瀏覽器緩存過時機制：

最後修改時間：
系統調用會獲取文件的最後修改時間，若是沒有發生變化就返回給瀏覽器 304 的狀態碼，表示沒有
發生變化，而後瀏覽器就使用的本地的緩存展現資源，

Etag 標記：
基於 Etag 標記是否一致作判斷頁面是否發生過變化，好比基於 Nginx 的 etag on 來實現

過時時間：
以上兩種都須要發送請求，即無論資源是否過時都要發送請求進行協商，這樣會消耗沒必要要的時間，
所以有了緩存的過時時間，即第一次請求資源的時候帶一個資源的過時時間，默認爲 30 天，當前這
種方式使用的比表較多，可是沒法保證客戶的時間都是準確而且一致的，所以假如一個最大生存週期，
使用用戶本地的時間計算緩存數據是否超過多少天，下面的過時時間爲 2027 年，可是緩存的最大生
存週期計算爲天等於 3650 天即 10 年，過時時間以下：

CDN 緩存：

什麼是 CND：
內容分發網絡（ Content Delivery Network），經過將服務內容分發至全網加速節點，利用全球調度系
統使用戶可以就近獲取，有效下降訪問延遲，提高服務可用性， CDN 第一下降機房的使用帶寬，由於不少資源經過 CDN 就直接返回用戶了，第二解決不一樣運營商之間的互聯，由於可讓聯通的網絡訪問聯通讓電信的網絡訪問電信，起到加速用戶訪問的目的，第三：解決用戶訪問的地域問題，就近返回用戶資源。
百度 CDN： https://cloud.baidu.com/product/cdn.html
阿里 CDN： https://www.aliyun.com/product/cdn?spm=5176.8269123.416540.50.728y8n
騰訊 CDN： https://www.qcloud.com/product/cdn
1.3.2：用戶請求 CDN 流程：
提早對靜態內容進行預緩存，避免大量的請求回源，致使主站網絡帶寬被打滿而致使數據沒法更新，
另外 CDN 能夠將數據根據訪問的熱度不一樣而進行不一樣級別的緩存，例如訪問量最高的資源訪問 CDN
邊緣節點的內存，其次的放在 SSD 或者 SATA，再其次的放在雲存儲，這樣兼顧了速度與成本。

CDN 主要優點：
提早對靜態內容進行預緩存，避免大量的請求回源，致使主站網絡帶寬被打滿而致使數據沒法更新，
另外 CDN 能夠將數據根據訪問的熱度不一樣而進行不一樣級別的緩存，例如訪問量最高的資源訪問 CDN邊緣節點的內存，其次的放在 SSD 或者 SATA，再其次的放在雲存儲，這樣兼顧了速度與成本。

緩存到最快的地方如內存，緩存的數據準確命中率高，訪問速度就快
調度準確-將用戶調度到最近的邊緣節點
性能優化-CDN 專門用於緩存響應速度快
安全相關-抵禦攻擊
節省帶寬：因爲用戶請求由邊緣節點響應，所以大幅下降到源站帶寬

應用層緩存：
Nginx、 PHP 等 web 服務能夠設置應用緩存以加速響應用戶請求，另外有些解釋性語言好比 PHP/Python
不能直接運行，須要先編譯成字節碼，但字節碼須要解釋器解釋爲機器碼以後才能執行，所以字節碼
也是一種緩存，有時候會出現程序代碼上線後字節碼沒有更新的現象。

其餘層面緩存：
CPU 緩存(L1 的數據緩存和 L1 的指令緩存)、二級緩存、三級緩存

磁盤緩存
RAID 卡
分佈式緩存： redis、 memcache
# MegaCli64 -LDinfo -Lall –aAll

二： redis 部署與使用：
2.1： redis 基礎：
官網地址： https://redis.io/
Redis 和 Memcached 是非關係型數據庫也稱爲 NoSQL 數據庫， MySQL、 Mariadb、 SQL Server、PostgreSQL、Oracle 數據庫屬於關係型數據(RDBMS, Relational Database Management System)

redis 簡介：
Redis(Remote Dictionary Server)在 2009 年發佈，開發者 Salvatore Sanfilippo 是意大利開發者，他本想爲本身的公司開發一個用於替換 MySQL 的產品 Redis，可是沒有想到他把 Redis 開源後大受歡迎，短短几年， Redis 就有了很大的用戶羣體，目前國內外使用的公司有知乎網、新浪微博、 GitHub 等redis 是一個開源的、遵循 BSD 協議的、基於內存的並且目前比較流行的鍵值數據庫(key-value database)，是一個非關係型數據庫， redis 提供將內存經過網絡遠程共享的一種服務，提供相似功能的還有memcache，但相比 memcache， redis 還提供了易擴展、高性能、具有數據持久性等功能。
Redis 在高併發、低延遲環境要求比較高的環境使用量很是普遍，目前 redis 在 DB-Engine 月排行榜https://db-engines.com/en/ranking 中一直比較靠前，並且一直是鍵值型存儲類的首位。

redis 對比 memcached：

支持數據的持久化：能夠將內存中的數據保持在磁盤中，重啓 redis 服務或者服務器以後能夠從備份
文件中恢復數據到內存繼續使用。
支持更多的數據類型：支持 string(字符串)、 hash(哈希數據)、 list(列表)、 set(集合)、 zet(有序集合)
支持數據的備份：能夠實現相似於數據的 master-slave 模式的數據備份，另外也支持使用快照+AOF。
支持更大的 value 數據： memcache 單個 key value 最大隻支持 1MB，而 redis 最大支持 512MB。
Redis 是單線程，而 memcache 是多線程，因此單機狀況下沒有 memcache 併發高，但 redis 支持分佈式集羣以實現更高的併發，單 Redis 實例能夠實現數萬併發。
支持集羣橫向擴展：基於 redis cluster 的橫向擴展，能夠實現分佈式集羣，大幅提高性能和數據安全
性，而memcached不支持集羣。
都是基於 C 語言開發。

redis 典型應用場景：
Session 共享：常見於 web 集羣中的 Tomcat 或者 PHP 中多 web 服務器 session 共享
消息隊列： ELK 的日誌緩存、部分業務的訂閱發佈系統
計數器：訪問排行榜、商品瀏覽數等和次數相關的數值統計場景
緩存：數據查詢、電商網站商品信息、新聞內容
微博/微信社交場合：共同好友、點贊評論等

Redis 安裝及使用：

官方下載地址： http://download.redis.io/releases/

yum 安裝 redis：
在 centos 系統上須要安裝 epel 源。

查看 yum 倉庫 redis 版本

[root@centos7 ~]#rpm -qi redis

[root@centos7 ~]#yum info redis

安裝 redis：

[root@centos7 ~]#yum install redis

[root@centos7 ~]#systemctl start redis && systemctl enable redis

[root@centos7 ~]#redis-cli

127.0.0.1:6379> set test 123

127.0.0.1:6379> get test

"123"

127.0.0.1:6379> ping

PONG

編譯安裝 redis：

下載當前最新 release 版本 redis 源碼包：

官方的安裝命令：https://redis.io/download
[root@centos7 ~]#tar xf redis-5.0.3.tar.gz
[root@centos7 ~]#cd redis-5.0.3

[root@centos7 ~]#make PREFIX=/usr/local/redis install

[root@centos7 ~]#ll /usr/local/redis

total 0
drwxr-xr-x 2 root root 134 Dec 13 09:21 bin
[root@centos7 ~]#mkdir /usr/local/redis/etc
[root@centos7 ~]#cp redis.conf /usr/local/redis/etc/

前臺啓動 redis：

[root@centos7 ~]#/usr/local/redis/bin/redis-server /usr/local/redis/etc/redis.conf

8894:C 11 Jun 19:38:05.867 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

8894:C 11 Jun 19:38:05.867 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=8894, just started

8894:C 11 Jun 19:38:05.867 # Configuration loaded

8894:S 11 Jun 19:38:05.868 * Increased maximum number of open files to 10032 (it was originally set to 1024).

_._

_.-``__ ''-._

_.-`` `. `_. ''-._ Redis 4.0.11 (00000000/0) 64 bit

.-`` .-```. ```\/ _.,_ ''-._

( ' , .-` | `, ) Running in standalone mode

|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379

| `-._ `._ / _.-' | PID: 8894

`-._ `-._ `-./ _.-' _.-'

|`-._`-._ `-.__.-' _.-'_.-'|

| `-._`-._ _.-'_.-' | http://redis.io

`-._ `-._`-.__.-'_.-' _.-'

|`-._`-._ `-.__.-' _.-'_.-'|

| `-._`-._ _.-'_.-' |

`-._ `-._`-.__.-'_.-' _.-'

`-._ `-.__.-' _.-'

`-._ _.-'

`-.__.-'

8894:S 11 Jun 19:38:05.870 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

8894:S 11 Jun 19:38:05.870 # Server initialized

8894:S 11 Jun 19:38:05.870 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

8894:S 11 Jun 19:38:05.871 * DB loaded from disk: 0.000 seconds

解決當前的警告提示：

tcp-backlog：
The backlog argument defines the maximum length to which the queue of pending connections
for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error
with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may
be ignored so that a later reattempt at connection succeeds.
backlog 參數控制的是三次握手的時候 server 端收到 client ack 確認號以後的隊列值。
net.core.somaxconn = 512

vm.overcommit_memory：
0、表示內核將檢查是否有足夠的可用內存供應用進程使用；若是有足夠的可用內存，內存申請容許；
不然，內存申請失敗，並把錯誤返回給應用進程。
一、表示內核容許分配全部的物理內存，而無論當前的內存狀態如何。
二、表示內核容許分配超過全部物理內存和交換空間總和的內存
vm.overcommit_memory = 1

transparent hugepage：
開啓大頁內存動態分配，須要關閉讓 redis 負責內存管理。
echo never > /sys/kernel/mm/transparent_hugepage/enabled

[root@centos7 ~]#vim /etc/sysctl.conf

[root@centos7 ~]#sysctl -p

net.core.somaxconn = 512

vm.overcommit_memory = 1

[root@centos7 ~]#echo never > /sys/kernel/mm/transparent_hugepage/enabled

再次啓動 redis：
將以上配置同步到其餘 redis 服務器。

編輯 redis 服務啓動腳本:
[root@s1 ~]# cat /usr/lib/systemd/system/redis.service
[Unit]
Description=Redis persistent key-value database
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
#ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd
ExecStart=/apps/redis/bin/redis-server /apps/redis/etc/redis.conf --supervised systemd
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
Type=notify
User=root
Group=root
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target

建立 redis 用戶和數據目錄：
[root@centos7 ~]# groupadd -g 1000 redis && useradd -u 1000 -g 1000 redis -s /sbin/nologin
[root@centos7 ~]# mkdir -pv /usr/local/redis/{etc,logs,data,run}
[root@centos7 ~]# chown redis.redis -R /usr/local/redis/

[root@centos7 ~]# systemctl start redis

使用客戶端鏈接 redis：
[root@centos7 ~]# /usr/local/redis/bin/redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD

建立命令軟鏈接：
[root@centos7 ~]# ln -sv /usr/local/redis/bin/redis-* /usr/bin/

redis 持久化：

redis 雖然是一個內存級別的緩存程序，即 redis 是使用內存進行數據的緩存的，可是其能夠將內存的數據按照必定的策略保存到硬盤上，從而實現數據持久保存的目的， redis 支持兩種不一樣方式的數據持久化保存機制，分別是 RDB 和 AOF

RDB 模式：

只保存一份快照，下一次會覆蓋上一次的備份，在保存快照的時間內若是有用戶寫入，是沒有備份的，只記錄快照瞬間前的數據，若是備份時機器down機了，會形成數據丟失

RDB：基於時間的快照，只保留當前最新的一次快照，特色是執行速度比較快，缺點是可能會丟失從上次快照到當前快照未完成之間的數據。

RDB 實現的具體過程 Redis 從主進程先 fork 出一個子進程，使用寫時複製機制，子進程將內存的數據保存爲一個臨時文件，好比 dump.rdb.temp，當數據保存完成以後再將上一次保存的 RDB 文件替換掉，而後關閉子進程，這樣能夠保存每一次作 RDB 快照的時候保存的數據都是完整的，由於直接替換 RDB文件的時候可能會出現忽然斷電等問題而致使 RDB 文件尚未保存完整就忽然關機中止保存而致使數據丟失的狀況，能夠手動將每次生成的 RDB 文件進程備份，這樣能夠最大化保存歷史數據。RDB 模式的優缺點：

優勢：

-RDB 快照保存了某個時間點的數據，能夠經過腳本執行 bgsave(非阻塞)或者 save(阻塞)命令自定義時間點北備份，能夠保留多個備份，當出現問題能夠恢復到不一樣時間點的版本。

-能夠最大化 o 的性能，由於父進程在保存 RDB 文件的時候惟一要作的是 fork 出一個子進程，而後的操做都會有這個子進程操做，父進程無需任何的 IO 操做

-RDB 在大量數據好比幾個 G 的數據，恢復的速度比 AOF 的快

缺點：

-不能時時的保存數據，會丟失自上一次執行 RDB 備份到當前的內存數據

-數據量很是大的時候，從父進程 fork 的時候須要一點時間，多是毫秒或者秒

AOF 模式：

AOF:按照操做順序依次將操做添加到指定的日誌文件當中，特色是數據安全性相對較高，缺點是即便有些操做是重複的也會所有記錄。AOF 和 RDB 同樣使用了寫時複製機制， AOF 默認爲每秒鐘 fsync 一次，即將執行的命令保存到 AOF 文件當中，這樣即便 redis 服務器發生故障的話頂多也就丟失 1 秒鐘以內的數據，也能夠設置不一樣的 fsync策略，或者設置每次執行命令的時候執行 fsync， fsync 會在後臺執行線程，因此主線程能夠繼續處理用戶的正常請求而不受到寫入 AOF 文件的 IO 影響2.3.2.4： AOF 模式優缺點：AOF 的文件大小要大於 RDB 格式的文件根據所使用的 fsync 策略(fsync 是同步內存中 redis 全部已經修改的文件到存儲設備)，默認是appendfsync everysec 即每秒執行一次 fsync

redis 配置文件：

redis 主要配置項：
bind 0.0.0.0 #監聽地址，能夠用空格隔開後多個監聽 IP

protected-mode yes #redis3.2以後加入的新特性，在沒有設置bind IP和密碼的時候只容許訪問127.0.0.1:6379

port 6379 #監聽端口
tcp-backlog 511 #三次握手的時候 server 端收到 client ack 確認號以後的隊列值。
timeout 0 #客戶端和 Redis 服務端的鏈接超時時間，默認是 0，表示永不超時。
tcp-keepalive 300 #tcp 會話保持時間
daemonize no #認狀況下 redis 不是做爲守護進程運行的，若是你想讓它在後臺運行，你就把它改爲yes,當 redis 做爲守護進程運行的時候，它會寫一個 pid 到 /var/run/redis.pid 文件裏面
supervised no #和操做系統相關參數，能夠設置經過 upstart 和 systemd 管理 Redis 守護進程， centos 7之後都使用 systemd
pidfile /var/run/redis_6379.pid #pid 文件路徑
loglevel notice #日誌級別
logfile "" #日誌路徑
databases 16 #設置 db 庫數量，默認 16 個庫
always-show-logo yes #在啓動 redis 時是否顯示 log
save 900 1 #在 900 秒內有一個鍵內容發生更改就出就快照機制
save 300 10
save 60 10000
stop-writes-on-bgsave-error no #快照出錯時是否禁止 redis 寫入操做
rdbcompression yes #持久化到 RDB 文件時，是否壓縮， "yes"爲壓縮， "no"則反之
rdbchecksum yes #是否開啓 RC64 校驗，默認是開啓
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路徑
replica-serve-stale-data yes #當從庫同主庫失去鏈接或者複製正在進行，從機庫有兩種運行方式： 1) 若是 replica-serve-stale-data 設置爲 yes(默認設置)，從庫會繼續響應客戶端的讀請求。 2) 若是 replicaserve-stale-data 設置爲 no，除去指定的命令以外的任何請求都會返回一個錯誤"SYNC with master inprogress"。
replica-read-only yes #是否設置從庫只讀
repl-diskless-sync no #是否使用 socket 方式複製數據，目前 redis 複製提供兩種方式， disk 和 socket，若是新的 slave 連上來或者重連的 slave 沒法部分同步，就會執行全量同步， master 會生成 rdb 文件，有2 種方式： disk 方式是 master 建立一個新的進程把 rdb 文件保存到磁盤，再把磁盤上的 rdb 文件傳遞給 slave， socket 是 master 建立一個新的進程，直接把 rdb 文件以 socket 的方式發給 slave， disk 方式的時候，當一個 rdb 保存的過程當中，多個 slave 都能共享這個 rdb 文件， socket 的方式就是一個個 slave順序複製，只有在磁盤速度緩慢可是網絡相對較快的狀況下才使用 socket 方式，不然使用默認的 disk方式repl-diskless-sync-delay 30 #diskless 複製的延遲時間，設置 0 爲關閉，一旦複製開始尚未結束以前，master 節點不會再接收新 slave 的複製請求，直到下一次開始
repl-ping-slave-period 10 #slave 根據 master 指定的時間進行週期性的 PING 監測
repl-timeout 60 #複製連接超時時間，須要大於 repl-ping-slave-period，不然會常常報超時
repl-disable-tcp-nodelay no #在 socket 模式下是否在 slave 套接字發送 SYNC 以後禁用 TCP_NODELAY，
若是你選擇「yes」Redis 將使用更少的 TCP 包和帶寬來向 slaves 發送數據。可是這將使數據傳輸到 slave上有延遲， Linux 內核的默認配置會達到 40 毫秒，若是你選擇了 "no" 數據傳輸到 salve 的延遲將會減小但要使用更多的帶寬
repl-backlog-size 1mb #複製緩衝區大小，只有在 slave 鏈接以後才分配內存。
repl-backlog-ttl 3600 #屢次時間 master 沒有 slave 鏈接，就清空 backlog 緩衝區。
replica-priority 100 #當 master 不可用， Sentinel 會根據 slave 的優先級選舉一個 master。最低的優先級的 slave，當選 master。而配置成 0，永遠不會被選舉。
requirepass foobared #設置 redis 鏈接密碼
rename-command #重命名一些高危命令
maxclients 10000 #最大鏈接客戶端
maxmemory #最大內存，單位爲 bytes 字節， 8G 內存的計算方式 8(G)*1024(MB)*1024(KB)*1024(Kbyte)，須要注意的是 slave 的輸出緩衝區是不計算在 maxmemory 內。appendonly no #是否開啓 AOF 日誌記錄，默認 redis 使用的是 rdb 方式持久化，這種方式在許多應用中已經足夠用了。可是 redis 若是中途宕機，會致使可能有幾分鐘的數據丟失，根據 save 來策略進行持久化，Append Only File 是另外一種持久化方式，能夠提供更好的持久化特性。 Redis 會把每次寫入的數據在接收後都寫入 appendonly.aof 文件，每次啓動時 Redis 都會先把這個文件的數據讀入內存裏，先忽略 RDB 文件。
appendfilename "appendonly.aof" #AOF 文件名
appendfsync everysec #aof 持久化策略的配置,no 表示不執行 fsync,由操做系統保證數據同步到磁盤,always 表示每次寫入都執行 fsync，以保證數據同步到磁盤,everysec 表示每秒執行一次 fsync，可能會致使丟失這 1s 數據。
no-appendfsync-on-rewrite no 在 aof rewrite 期間,是否對 aof 新記錄的 append 暫緩使用文件同步策略,主要考慮磁盤 IO 開支和請求阻塞時間。默認爲 no,表示"不暫緩",新的 aof 記錄仍然會被當即同步，Linux 的默認 fsync 策略是 30 秒，若是爲 yes 可能丟失 30 秒數據，但因爲 yes 性能較好並且會避免出現阻塞所以比較推薦。
auto-aof-rewrite-percentage 100 # 當 Aof log 增加超過指定百分比例時，重寫 log file，設置爲 0 表示不自動重寫 Aof 日誌，重寫是爲了使 aof 體積保持最小，而確保保存最完整的數據。
auto-aof-rewrite-min-size 64mb #觸發 aof rewrite 的最小文件大小
aof-load-truncated yes #是否加載因爲其餘緣由致使的末尾異常的 AOF 文件(主進程被 kill/斷電等)
aof-use-rdb-preamble yes #redis4.0 新增 RDB-AOF 混合持久化格式，在開啓了這個功能以後， AOF 重寫產生的文件將同時包含 RDB 格式的內容和 AOF 格式的內容，其中 RDB 格式的內容用於記錄已有的數據，而 AOF 格式的內存則用於記錄最近發生了變化的數據，這樣 Redis 就能夠同時兼有 RDB 持久化和AOF 持久化的優勢（既可以快速地生成重寫文件，也可以在出現問題時，快速地載入數據）。
lua-time-limit 5000 #lua 腳本的最大執行時間，單位爲毫秒
cluster-enabled yes #是否開啓集羣模式，默認是單機模式
cluster-config-file nodes-6379.conf #由 node 節點自動生成的集羣配置文件
cluster-node-timeout 15000 #集羣中 node 節點鏈接超時時間
cluster-replica-validity-factor 10 #在執行故障轉移的時候可能有些節點和 master 斷開一段時間數據比較舊，這些節點就不適用於選舉爲 master，超過這個時間的就不會被進行故障轉移
cluster-migration-barrier 1 #一個主節點擁有的至少正常工做的從節點，即若是主節點的 slave 節點故障後會將多餘的從節點分配到當前主節點成爲其新的從節點。
cluster-require-full-coverage no #集羣槽位覆蓋，若是一個主庫宕機且沒有備庫就會出現集羣槽位不全，那麼 yes 狀況下 redis 集羣槽位驗證不全就再也不對外提供服務，而 no 則能夠繼續使用可是會出現查詢數據查不到的狀況(由於有數據丟失)。
#Slow log 是 Redis 用來記錄查詢執行時間的日誌系統， slow log 保存在內存裏面，讀寫速度很是快，所以你能夠放心地使用它，沒必要擔憂由於開啓 slow log 而損害 Redis 的速度。
slowlog-log-slower-than 10000 #以微秒爲單位的慢日誌記錄，爲負數會禁用慢日誌，爲 0 會記錄每一個命令操做。
slowlog-max-len 128 #記錄多少條慢日誌保存在隊列，超出後會刪除最先的，以此滾動刪除
127.0.0.1:6379> slowlog len
(integer) 14
127.0.0.1:6379> slowlog get
1) 1) (integer) 14
2) (integer) 1544690617
3) (integer) 4
4) 1) "slowlog"
127.0.0.1:6379> SLOWLOG reset
OK

添加一個 key：
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> get key1
"value1"
127.0.0.1:6379> TYPE key1
獲取一個 key 的內容：
127.0.0.1:6379> get key1

刪除一個 key：
127.0.0.1:6379> DEL key1
(integer) 1

批量設置多個 key：
127.0.0.1:6379> MSET key1 value1 key2 value2
OK

批量獲取多個 key：
127.0.0.1:6379> MSET key1 value1 key2 value2
OK

追加數據：
127.0.0.1:6379> APPEND key1 append
(integer) 12
127.0.0.1:6379> get key1
"value1append"

數值遞增：
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> INCR num
(integer) 11
127.0.0.1:6379> get num
"11"

數值遞減：
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> DECR num
(integer) 9
127.0.0.1:6379> get num
"9"
返回字符串 key 長度：
127.0.0.1:6379> STRLEN key1
(integer) 12
列表(list)：
列表是一個雙向可讀寫的管道，其頭部是左側尾部是右側，一個列表最多能夠包含 2^32-1 個元素即
4294967295 個元素。
生成列表並插入數據：
127.0.0.1:6379> LPUSH list1 jack
(integer) 1
127.0.0.1:6379> TYPE list1
list
向列表追加數據：
127.0.0.1:6379> LPUSH list1 tom
(integer) 2
127.0.0.1:6379> RPUSH list1 jack
(integer) 3
獲取列表長度：
127.0.0.1:6379> LLEN list1
(integer) 3
移除列表數據：
127.0.0.1:6379> RPOP list1 #最後一個
"jack"
127.0.0.1:6379> LPOP list1 #第一個
"tom"
集合(set)：
Set 是 String 類型的無序集合。集合成員是惟一的，這就意味着集合中不能出現重複的數據。
2.4.3.1：生成集合 key:
127.0.0.1:6379> SADD set1 v1
(integer) 1
127.0.0.1:6379> SADD set2 v2 v4
(integer) 2
127.0.0.1:6379> TYPE set1
set
127.0.0.1:6379> TYPE set2
set
追加數值：
追加的時候不能追加已經存在的數值
127.0.0.1:6379> SADD set1 v2 v3 v4
(integer) 3
127.0.0.1:6379> SADD set1 v2 #沒有追加成功
(integer) 0
127.0.0.1:6379> TYPE set1
set
127.0.0.1:6379> TYPE set2
set
查看集合的全部數據：
127.0.0.1:6379> SMEMBERS set1
1) "v4"
2) "v1"
3) "v3"
4) "v2"
127.0.0.1:6379> SMEMBERS set2
1) "v4"
2) "v2"
獲取集合的差集：
差集：已屬於 A 而不屬於 B 的元素稱爲 A 與 B 的差（集）
127.0.0.1:6379> SDIFF set1 set2
1) "v1"
2) "v3"
獲取集合的交集：
交集：已屬於 A 且屬於 B 的元素稱爲 A 與 B 的交（集）
127.0.0.1:6379> SINTER set1 set2
1) "v4"
2) "v2"
獲取集合的並集：
並集：已屬於 A 或屬於 B 的元素爲稱爲 A 與 B 的並（集）
127.0.0.1:6379> SUNION set1 set2
1) "v2"
2) "v4"
3) "v1"
4) "v3"
sorted set(有序集合):
Redis 有序集合和集合同樣也是 string 類型元素的集合,且不容許重複的成員，不一樣的是每一個元素都會
關聯一個 double(雙精度浮點型)類型的分數， redis 正是經過分數來爲集合中的成員進行從小到大的排
序，序集合的成員是惟一的,但分數(score)卻能夠重複，集合是經過哈希表實現的，因此添加，刪除，
查找的複雜度都是 O(1)，集合中最大的成員數爲 2^32 - 1 (4294967295, 每一個集合可存儲 40 多億個成
員)。
生成有序集合：
127.0.0.1:6379> ZADD zset1 1 v1
(integer) 1
127.0.0.1:6379> ZADD zset1 2 v2
(integer) 1
127.0.0.1:6379> ZADD zset1 2 v3
(integer) 1
127.0.0.1:6379> ZADD zset1 3 v4
(integer) 1
127.0.0.1:6379> TYPE zset1
zset
127.0.0.1:6379> TYPE zset2
zset
排行案例：
192.168.7.104:6379> ZADD paihangbang 10 key1 20 key2 30 key3
(integer) 3
192.168.7.104:6379> ZREVRANGE paihangbang 0 -1 withscores
1) "key3"
2) "30"
3) "key2"
4) "20"
5) "key1"
6) "10"
批量添加多個數值：
127.0.0.1:6379> ZADD zset2 1 v1 2 v2 4 v3 5 v5
(integer) 4
獲取集合的長度數：
127.0.0.1:6379> ZCARD zset1
(integer) 4
127.0.0.1:6379> ZCARD zset2
(integer) 4
基於索引返回數值：
127.0.0.1:6379> ZRANGE zset1 1 3
1) "v2"
2) "v3"
3) "v4"
127.0.0.1:6379> ZRANGE zset1 0 2
1) "v1"
2) "v2"
3) "v3"
返回某個數值的索引：
127.0.0.1:6379> ZRANK zset1 v2
(integer) 1
127.0.0.1:6379> ZRANK zset1 v3
(integer) 2
哈希(hash)：
hash 是一個 string 類型的 field 和 value 的映射表， hash 特別適合用於存儲對象,Redis 中每一個 hash 可
以存儲 232 - 1 鍵值對（ 40 多億）。
生成 hash key：
127.0.0.1:6379> HSET hset1 name tom age 18
(integer) 1
127.0.0.1:6379> TYPE hset1
hash
獲取 hash key 字段值：
127.0.0.1:6379> HGET hset1 name
"tom"
127.0.0.1:6379> HGET hset1 age
"18"
刪除一個 hash key 的字段：
127.0.0.1:6379> HDEL hset1 age
(integer) 1
獲取全部 hash 表中的字段：
127.0.0.1:6379> HSET hset1 name tom age 19
(integer) 1
127.0.0.1:6379> HKEYS hset1
1) "name"
2) "age"

消息隊列：
消息隊列主要分爲兩種，分別是生產者消費者模式和發佈者訂閱者模式，這兩種模式 Redis 都支持，生產者消費者模式：
在生產者消費者(Producer/Consumer)模式下，上層應用接收到的外部請求後開始處理其當前步驟的
操做，在執行完成後將已經完成的操做發送至指定的頻道(channel)當中，並由其下層的應用監聽該頻
道並繼續下一步的操做，若是其處理完成後沒有下一步的操做就直接返回數據給外部請求，若是還有下一步的操做就再將任務發佈到另一個頻道，由另一個消費者繼續監聽和處理。

模式介紹：
生產者消費者模式下，多個消費者同時監聽一個隊裏，可是一個消息只能被最早搶到消息的消費者
消費，即消息任務是一次性讀取和處理，此模式在分佈式業務架構中很是經常使用，比較經常使用的軟件還有RabbitMQ、 Kafka、 RocketMQ、 ActiveMQ 等

隊列介紹：
隊列當中的消息由不一樣的生產者寫入也會有不一樣的消費者取出進行消費處理，可是一個消息必定是
只能被取出一次也就是被消費一次。

生產者發佈消息：
[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK
127.0.0.1:6379> LPUSH channel1 msg1 #從管道的左側寫入
(integer) 1
127.0.0.1:6379> LPUSH channel1 msg2
(integer) 2
127.0.0.1:6379> LPUSH channel1 msg3
(integer) 3
127.0.0.1:6379> LPUSH channel1 msg4
(integer) 4
127.0.0.1:6379> LPUSH channel1 msg5
(integer) 5

查看隊列全部消息：
127.0.0.1:6379> LRANGE channel1 0 -1
1) "msg5"
2) "msg4"
3) "msg3"
4) "msg2"
5) "msg1"

消費者消費消息：
127.0.0.1:6379> RPOP channel1 #從管道的右側消費
"msg1"
127.0.0.1:6379> RPOP channel1
"msg2"
127.0.0.1:6379> RPOP channel1
"msg3"
127.0.0.1:6379> RPOP channel1
"msg4"
127.0.0.1:6379> RPOP channel1
"msg5"
127.0.0.1:6379> RPOP channel1
(nil)

再次驗證隊列消息：
127.0.0.1:6379> LRANGE channel1 0 -1
(empty list or set) #隊列中的消息已經被已所有消費完畢

發佈者訂閱模式：

模式簡介：
在發佈者訂閱者模式下，發佈者將消息發佈到指定的 channel 裏面，凡是監聽該 channel 的消費者
都會收到一樣的一份消息，這種模式相似因而收音機模式，即凡是收聽某個頻道的聽衆都會收到主持
人發佈的相同的消息內容。
此模式經常使用語羣聊天、羣通知、羣公告等場景。
Subscriber：訂閱者
Publisher：發佈者
Channel：頻道

訂閱者監聽頻道：
[root@redis-s4 ~]# redis-cli
127.0.0.1:6379> AUTH 123456
OK
127.0.0.1:6379> SUBSCRIBE channel1 #訂閱者訂閱指定的頻道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1

發佈者發佈消息：
127.0.0.1:6379> PUBLISH channel1 test1 #發佈者發佈消息
(integer) 2
127.0.0.1:6379> PUBLISH channel1 test2
(integer) 2
127.0.0.1:6379>

各訂閱者驗證消息：

訂閱多個頻道：

> SUBSCRIBE channel1 channel2
訂閱指定的多個頻道
> SUBSCRIBE channel1 channel2

訂閱全部頻道：
127.0.0.1:6379> PSUBSCRIBE *

訂閱匹配的頻道：
> PSUBSCRIBE chann* #匹配訂閱多個頻道

redis 其餘命令：

CONFIG：
config 命令用於查看當前 redis 配置、以及不重啓更改 redis 配置等

更改最大內存：
127.0.0.1:6379> CONFIG set maxmemory 8589934592
127.0.0.1:6379> CONFIG get maxmemory
1) "maxmemory"
2) "8589934592"

設置鏈接密碼：

127.0.0.1:6379> CONFIG SET requirepass 123456
永久保存：寫入配置文件中redis.conf：
requirepass 123

查看當前配置：

127.0.0.1:6379> CONFIG GET *

info：
顯示當前節點 redis 運行狀態信息

127.0.0.1:6379> info

SELECT：
切換數據庫

127.0.0.1:6379> SELECT 1

127.0.0.1:6379[1]>

keys:
查看當前庫下的全部 key：

127.0.0.1:6379>KEYS *

BGSAVE：
手動在後臺執行 RDB 持久化操做

127.0.0.1:6379>BGSAVE

DBSIZE：
返回當前庫下的全部 key 數量

127.0.0.1:6379>DBSIZE

FLUSHDB：
強制清空當前庫中的全部 key

FLUSHALL：
強制清空當前 redis 服務器全部數據庫中的全部 key，即刪除全部數據

redis 高可用與集羣：
雖然 Redis 能夠實現單機的數據持久化，但不管是 RDB 也好或者 AOF 也好，都解決不了單點宕機問題，即一旦 redis 服務器自己出現系統故障、硬件故障等問題後，就會直接形成數據的丟失，所以須要使用另外的技術來解決單點問題。

配置 reids 主從：
主備模式，能夠實現 Redis 數據的跨主機備份。程序端鏈接到高可用負載的 VIP，而後鏈接到負載服務器設置的 Redis 後端 real server，此模式不須要在程序裏面配置 Redis 服務器的真實 IP 地址，當後期 Redis 服務器 IP 地址發生變動只須要更改 redis相應的後端 real server 便可，可避免更改程序中的 IP 地址設置。

Slave 主要配置：
Redis Slave 也要開啓持久化並設置和 master 一樣的鏈接密碼，由於後期 slave 會有提高爲 master 的可能,Slave 端切換 master 同步後會丟失以前的全部數據。一旦某個 Slave 成爲一個 master 的 slave， Redis Slave 服務會清空當前 redis 服務器上的全部數據並將master 的數據導入到本身的內存，可是斷開同步關係後不會刪除當前已經同步過的數據。

1、Slave節點配置：
當前狀態爲 master，須要轉換爲 slave 角色並指向 master 服務器的 IP+PORT+Password
192.168.7.104:6379> SLAVEOF 192.168.7.103 6379 #指向主節點
192.168.7.104:6379> CONFIG SET masterauth 123456 #配置主節點密碼

永久保存：寫入配置文件中redis.conf：
slaveof 172.18.0.70 6379

masterauth 123

2、重啓Slave便可開始同步

3、查看Slave節點狀態：

192.168.7.104:6379> INFO Replication

4、slave 狀態只讀沒法寫入數據

5、查看Master日誌與Slave

主從複製過程：
Redis 支持主從複製分爲全量同步和增量同步，首次同步是全量同步，主從同步可讓從服務器從
主服務器備份數據，並且從服務器還可與有從服務器，即另一臺 redis 服務器能夠從一臺從服務器
進行數據同步， redis 的主從同步是非阻塞的，其收到從服務器的 sync(2.8 版本以前是 PSYNC)命令會fork 一個子進程在後臺執行 bgsave 命令，並將新寫入的數據寫入到一個緩衝區裏面， bgsave 執行完成以後並生成的將 RDB 文件發送給客戶端，客戶端將收到後的 RDB 文件載入本身的內存，而後主 redis將緩衝區的內容在所有發送給從 redis，以後的同步從服務器會發送一個 offset 的位置(等同於 MySQL的 binlog 的位置)給主服務器，主服務器檢查後位置沒有錯誤將此位置以後的數據包括寫在緩衝區的積壓數據發送給 redis 從服務器，從服務器將主服務器發送的擠壓數據寫入內存，這樣一次完整的數據同步，再以後再同步的時候從服務器只要發送當前的 offset 位置給主服務器，而後主服務器根據響應的位置將以後的數據發送給從服務器保存到其內存便可。
Redis 全量複製通常發生在 Slave 初始化階段，這時 Slave 須要將 Master 上的全部數據都複製一份。具體步驟以下：
1）從服務器鏈接主服務器，發送 SYNC 命令；
2）主服務器接收到 SYNC 命名後，開始執行 BGSAVE 命令生成 RDB 快照文件並使用緩衝區記錄此後執行的全部寫命令；
3）主服務器 BGSAVE 執行完後，向全部從服務器發送快照文件，並在發送期間繼續記錄被執行的寫命令；
4）從服務器收到快照文件後丟棄全部舊數據，載入收到的快照；
5）主服務器快照發送完畢後開始向從服務器發送緩衝區中的寫命令；
6）從服務器完成對快照的載入，開始接收命令請求，並執行來自主服務器緩衝區的寫命令；
7）後期同步會先發送本身 slave_repl_offset 位置，只同步新增長的數據，再也不全量同步。

主從同步優化：
Redis 在 2.8 版本以前沒有提供增量部分複製的功能，當網絡閃斷或者 slave Redis 重啓以後會致使主從之間的全量同步，即從 2.8 版本開始增長了部分複製的功能。
repl-diskless-sync yes#yes 爲支持 disk， master 將 RDB 文件先保存到磁盤在發送給 slave， no 爲 maste直接將 RDB 文件發送給 slave，默認即爲使用 no， Master RDB 文件不須要與磁盤交互。
repl-diskless-sync-delay 5 #Master 準備好 RDB 文件後等等待傳輸時間
repl-ping-slave-period 10 #slave 端向 server 端發送 ping 的時間區間設置，默認爲 10 秒
repl-timeout 60 #設置超時時間
repl-disable-tcp-nodelay no #是否啓用 TCP_NODELAY，如設置成 yes，則 redis 會合並小的 TCP 包從而節省帶寬，但會增長同步延遲（40ms），形成 master 與 slave 數據不一致，假如設置成 no，則 redis master會當即發送同步數據，沒有延遲，前者關注性能，後者關注一致性
repl-backlog-size 1mb #master 的寫入數據緩衝區，用於記錄自上一次同步後到下一次同步過程當中間的寫入命令，計算公式： b repl-backlog-size = 容許從節點最大中斷時長 * 主實例 offset 每秒寫入量，好比 master 每秒最大寫入 64mb，最大容許 60 秒，那麼就要設置爲 64mb*60 秒=3840mb(3.8G)=repl-backlog-ttl 3600 #若是一段時間後沒有 slave 鏈接到 master，則 backlog size 的內存將會被釋放。若是值爲 0 則表示永遠不釋放這部分內存。
slave-priority 100 #slave 端的優先級設置，值是一個整數，數字越小表示優先級越高。當 master 故障時將會按照優先級來選擇 slave 端進行恢復，若是值設置爲 0，則表示該 slave 永遠不會被選擇。
#min-slaves-to-write 0 #
#min-slaves-max-lag 10 #設置當一個 master 端的可用 slave 少於 N 個，延遲時間大於 M 秒時，不接收寫操做。

Master 的重啓會致使 master_replid 發生變化， slave 以前的 master_replid 就和 master 不一致從而會引起全部 slave 的全量同步。

slave 切換 master：

中止 slave 同步並查看當前狀態：
192.168.7.101:6379> SLAVEOF no one
192.168.7.101:6379> info Replication

測試可否寫入數據：
192.168.7.101:6379> set key1 value1

Slave 節點再有 Slave：

常見問題彙總：

master 密碼不對：
即配置的 master 密碼不對，致使驗證不經過而沒法創建主從同步關係

Redis 版本不一致：
不一樣的 redis 版本之間存在兼容性問題，所以各 master 和 slave 之間必須保持版本一致。

沒法遠程鏈接：
在開啓了安全模式狀況下，沒有設置 bind 地址和密碼

[root@centos7 ~]# redis-cli -h 192.168.0.1

192.168.0.1:6379>KEYS *

(error) DENIED Redis is running in protected mode because protected mode is enabled, no
bind address was specified, no authentication password
is requested to clients. In this mode connections are only accepted from the loopback
interface. If you want to connect from external computers to Redis you may adopt one of the following solutions:
1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so.Use CONFIG REWRITE to make this change permanent.
2) Alternatively you can just disable the protected mode by editing the Redis configuration
file, and setting the protected mode option to 'no', and then restarting the server.
3) If you started the server manually just for testing, restart it with the '--protected-mode no' option.
4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside.

redis 集羣：
上一個步驟的主從架構沒法實現 master 和 slave 角色的自動切換，即當 master 出現 redis 服務異常、主機斷電、磁盤損壞等問題致使 master 沒法使用，而 redis 高可用沒法實現自故障轉移(將 slave 提高爲 master)，須要手動改環境配置才能切換到 slave redis 服務器，另外也沒法橫向擴展 Redis 服務的並行寫入性能，當單臺 Redis 服務器性能沒法知足業務寫入需求的時候就必須須要一種方式解決以上的兩個核心問題，即： 1.master 和 slave 角色的無縫切換，讓業務無感知從而不影響業務使用 2.能夠橫向動態擴展 Redis 服務器，從而實現多臺服務器並行寫入以實現更高併發的目的。
Redis 集羣實現方式： 客戶端分片代理分片 Redis Cluster

Sentinel(哨兵)：
Sentinel 進程是用於監控 redis 集羣中 Master 主服務器工做的狀態，在 Master 主服務器發生故障的時候，能夠實現 Master 和 Slave 服務器的切換，保證系統的高可用，其已經被集成在 redis2.6+的版本中， Redis 的哨兵模式到了 2.8 版本以後就穩定了下來。通常在生產環境也建議使用 Redis 的 2.8 版本的之後版本。哨兵(Sentinel) 是一個分佈式系統，你能夠在一個架構中運行多個哨兵(sentinel) 進程，這些進程使用流言協議(gossipprotocols)來接收關於 Master 主服務器是否下線的信息，並使用投票協議(Agreement Protocols)來決定是否執行自動故障遷移,以及選擇哪一個 Slave 做爲新的 Master。每一個哨兵(Sentinel)進程會向其它哨兵(Sentinel)、 Master、 Slave 定時發送消息，以確認對方是否」活」着，若是發現對方在指定配置時間(可配置的)內未獲得迴應，則暫時認爲對方已掉線，也就是所謂的」主觀認爲宕機」，英文名稱： Subjective Down，簡稱 SDOWN。有主觀宕機，確定就有客觀宕機。當「哨兵羣」中的多數 Sentinel 進程在對 Master 主服務器作出 SDOWN 的判斷，而且經過 SENTINEL is-masterdown-by-addr 命令互相交流以後，得出的 Master Server 下線判斷，這種方式就是「客觀宕機」，英文名稱是： Objectively Down，簡稱 ODOWN。經過必定的 vote 算法，從剩下的 slave 從服務器節點中，選一臺提高爲 Master 服務器節點，而後自動修改相關配置，並開啓故障轉移（ failover）。
Sentinel 機制能夠解決 master 和 slave 角色的切換問題

主服務器手動配置 master：
須要手動先指定某一臺 Redis 服務器爲 master，而後將其餘 slave 服務器使用命令配置爲 master 服務器的 slave

從服務器 A 配置 slave：
192.168.7.102:6379> REPLICAOF 192.168.7.101 6379 #PEPLICAOF命令不成功則用SLAVEOF替代
192.168.7.102:6379> CONFIG SET masterauth "123456"

從服務器 B 配置 slave：

192.168.7.102:6379> REPLICAOF 192.168.7.101 6379 #PEPLICAOF命令不成功則用SLAVEOF替代
192.168.7.102:6379> CONFIG SET masterauth "123456"

查看各配置狀態

192.168.7.102:6379> info

192.168.7.102:6379> info Replication

應用程序如何鏈接 redis？：
java 客戶端鏈接 redis 是經過 jedis 來實現的， java 代碼用的時候只要建立 jedis 對象就能夠建多個 jedis 鏈接池來鏈接 redis，應用程序再直接調用鏈接池便可鏈接 Redis。而 Redis 爲了保障高可用,服務通常都是 Sentinel 部署方式，當 Redis 服務中的主服務掛掉以後,會仲裁出另一臺 Slaves 服務充當 Master。這個時候,咱們的應用即便使用了 Jedis 鏈接池,Master服務掛了,咱們的應用獎仍是沒法鏈接新的 Master 服務，爲了解決這個問題,Jedis 也提供了相應的Sentinel 實現,可以在 Redis Sentinel 主從切換時候,通知咱們的應用,把咱們的應用鏈接到新的Master 服務。Jedis Sentinel 的使用也是十分簡單的,只是在 JedisPool 中添加了 Sentinel 和 MasterName 參數， Jedis Sentinel 底層基於 Redis 訂閱實現 Redis 主從服務的切換通知，當 Reids 發生主從切換時， Sentinel 會發送通知主動通知 Jedis 進行鏈接的切換， JedisSentinelPool 在每次從鏈接池中獲取連接對象的時候,都要對鏈接對象進行檢測,若是此連接和 Sentinel 的 Master 服務鏈接參數不一致,則會關閉此鏈接,從新獲取新的 Jedis 鏈接對象。

編輯配置文件 sentinel.conf：
Server1 配置：
哨兵能夠不和 Redis 服務器部署在一塊兒
[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 0.0.0.0
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 30000 #(SDOWN)主觀下線的時間
sentinel parallel-syncs mymaster 1 #發生故障轉移時候同時向新 master 同步數據的 slave 數量，數字越小總同步時間越長
sentinel failover-timeout mymaster 180000 #全部 slaves 指向新的 master 所需的超時時間
sentinel deny-scripts-reconfig yes

Server2 配置：

[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 192.168.7.102
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456

Server3 配置：

[root@redis-s1 etc]# grep "^[a-Z]" /usr/local/redis/etc/sentinel.conf
bind 192.168.7.103
port 26379
daemonize yes
pidfile "/usr/local/redis/redis-sentinel.pid"
logfile "/usr/local/redis/sentinel_26379.log"
dir "/usr/local/redis"
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 192.168.7.101 6379 2
sentinel auth-pass mymaster 123456

啓動哨兵：
三臺哨兵都要啓動
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf
#/usr/local/redis/bin/redis-sentinel /usr/local/redis/etc/sentinel.conf

當前 sentinel 狀態：
尤爲是最後一行，涉及到 master IP 是多少，有幾個 slave，有幾個 sentinels，必須是符合所有服務器數量的。

[root@redis-s1 etc]# redis-cli -h 192.168.7.101 -p 26379
192.168.7.101:26379> info Sentinel

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.7.101:6379,slaves=2,sentinels=3

故障轉移後的 redis 配置文件：
故障轉移後 redis.conf 中的 replicaof 行的 master IP 會被修改， sentinel.conf 中的 sentinel monitor IP 會被修改。

Redis Cluster： Redis 分佈式部署方案： 1) 客戶端分區：由客戶端程序決定 key 寫分配和寫入的 redis node，可是須要客戶端本身處理寫入分配、高可用管理和故障轉移等 2)代理方案：基於三方軟件實現 redis proxy，客戶端先鏈接之代理層，由代理層實現 key 的寫入分配，對客戶端來講是有比較簡單，可是對於集羣管節點增減相對比較麻煩，並且代理自己也是單點和性能瓶頸。在哨兵 sentinel 機制中，能夠解決 redis 高可用的問題，即當 master 故障後能夠自動將 slave 提高爲master 從而能夠保證 redis 服務的正常使用，可是沒法解決 redis 單機寫入的瓶頸問題，即單機的 redis寫入性能受限於單機的內存大小、併發數量、網卡速率等因素，所以 redis 官方在 redis 3.0 版本以後推出了無中心架構的 redis cluster 機制，在無中心的 redis 集羣匯中，其每一個節點保存當前節點數據和整個集羣狀態,每一個節點都和其餘全部節點鏈接，特色以下： 1：全部 Redis 節點使用(PING 機制)互聯 2：集羣中某個節點的失效，是整個集羣中超過半數的節點監測都失效纔算真正的失效 3：客戶端不須要 proxy 便可直接鏈接 redis，應用程序須要寫所有的 redis 服務器 IP。 4： redis cluster 把全部的 redis node 映射到 0-16383 個槽位(slot)上，讀寫須要到指定的 redis node 上進行操做，所以有多少個 reids node 至關於 redis 併發擴展了多少倍。 5： Redis cluster 預先分配 16384 個(slot)槽位，當須要在 redis 集羣中寫入一個 key -value 的時候，會使用 CRC16(key) mod 16384 以後的值，決定將 key 寫入值哪個槽位從而決定寫入哪個 Redis 節點上，從而有效解決單機瓶頸。