注：本篇記錄一下，學過Redis教程後記錄下來的操作命令
目錄
簡介
Redis是一個高速緩存的NoSql數據庫。可支持持久化。就是把數據寫到硬盤。基於key-value來進行緩存。
首先引用一下百度百科中的介紹。
redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的(單命令)。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，爲了保證效率，數據都是緩存在內存中。區別的是redis會週期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。
數據類型&命令
1、字符串
應用場景：今天我們有多少個獨立用戶訪問（字符串） 微博數、粉絲數。
setbit cc 1 1 //設置 cc key的 1號位 是1
setbit cc 2 1
getbit cc 2 >1 //獲取 cc key的 1號位的值
getbit cc 3 >
bitcount cc >2 //獲取有多少個位
incr incrby decr decrby
getrange z 0 4 //獲取索引段的值
setrange z 0 asd //覆蓋索引0開始往後覆蓋，直到把值asd寫入
getset z asd //設置值爲新值並返回舊值。
strlen z //返回字符串長度。
setex c 10 d //設置 c 的值爲 d 有效期爲 10s 這個是原子的。 ttl查看時間
psetex c 4000 d //設置 c 的值爲 d 有效期爲 4000ms 這個是原子的。 pttl查看時間
setnx c d //設置c 的值爲d 如果不存在的話。 存在就不設置了。
mset mget //多個批量操作。
2、list
被用作消息隊列， 關注列表 粉絲列表
微博熱點緩存。 緩存5000條熱搜ID。 可以做隊列，使用lrange 分頁。
list理解成一個棧。或者理解成 ----> 這樣的一個隊列、l就是左邊進 r就是右邊進 lpush 就是從棧底入棧 rpush 就是從棧頂入棧。
lrange asdkey 0 -1 (start end) //-1表示到最後。list 查裏面的是啥
lpop rpop //就是刪最邊上的元素。
BRPOP它是 RPOP 命令的阻塞版本，當給定列表內沒有任何元素可供彈出的時候，連接將被 BRPOP 命令阻塞,直到等待超時或發現可彈出元素爲止。B 開頭的就是阻塞的。
lpush z 1 2 3
lpushx z 1 //跟lpush區別就是如果key不存在那麼什麼也不做。
llen z //看z的長度、
lrem [key] [count] [value] //可以理解爲,從index爲0的位置開始遍歷這個list,刪除值爲value的項,直到刪除count項爲止
lrem z 2 as //從 左邊/棧底 刪 l開頭、
lindex z 0 //取索引下標的元素 <l開頭> 不會彈出，只是get
lset z 1 9 //將列表的 索引(1) 位改值爲9
ltrim z 0 4 將key截取 索引段 其餘數據丟掉。 閉區間。
LINSERT key BEFORE|AFTER pivot value
linsert z after 4 99 //將值 value 插入到列表 key 當中，位於值 pivot 之前或之後。當 pivot 不存在於列表 key 時，不執行任何操作。
3、hash
存儲對象信息 id =>{name,hobby} 將多個分散的字符串類型key轉成hash能節約內存。單點登錄存用戶信息
hkeys hashkey //獲取hashkey中的所有filed
hgetall hashkey //獲取hashkey中所有的filed和value 會替換交叉展示、
hget key field //獲取指定hashkey 指定field的value值
hvals key //獲取key的所有值。
hkeys key //獲取所有 field。
hmset aa a 5 b 6 //操作多個field
hmget aa a b
hdel aa a b //刪除多個field
hsetnx key field value //將哈希表 key 中的域 field 的值設置爲 value ，當且僅當域 field 不存在。field存在就改不了了。
hexists z s //看key中field 是否存在。
hincrby k f 5 //將對應field的值+5 可以爲負的就是減 只能是整數。
hincrbyfloat z a -1.1 //操作浮點數。
hlen z //看field個數。
4、set 集合
hashtable實現，crud都是O(1) 去重。
微博：所有粉絲作爲一個key 的元素，還可以求共同好友啥的。 交併差集 共同好友，我喜歡啥的。
有時候需要對值的屬性進行標記和跟蹤處理，但不能通過簡單的複製操作完成，集合數據結構是解決此類問題的最好方法之一。當然，對於那些需要運用集合操作的地方（例如交集和並集），集合數據結構就是最好的選擇。
sadd a 1 2 3 4 2 //集合是唯一的，當加入存在的元素(2)會加不進去的。
sadd b 3 4 5 6
sdiff a b //返回 1 2 去掉a b中共有的剩餘a的集合。
sdiffstore c a b //將diff結果存入c
sinter a b //返回 3 4 返回交集。
sinterstore c a b //同上 存儲交集到c
sunion a b //求並集
sunionstore c a b //將並集結果存入c
scard a //返回 key裏面有多少個元素。
smembers //返回集合裏面的所有元素。
srandmember a 2 //隨機返回2兩個元素。
spop a //隨機刪除一個元素並返回。
sismember a 3 //判斷3是不是a裏面的元素。
smove a b 1 //原子性的將a中的1 元素移到b裏面。
srem b 5 6 //移除多個元素
5、sorted set分類集合(zset)
以得分的形式加入分類集合元素， 去重有序，根據score排序，帶權重的操作、 重複添加的元素會更新score值。
排行榜 TOP n
zadd d 10 "a" 20 "b" //添加值並賦予得分
zrange d 0 -1 [withscores] //返回分類集合的元素，可加得分情況
zcard d //返回分類集合中的元素數量
zcount d 20 30 //返回score在 [20,30]裏面的元素。
zrangebyscore d (10 20 //根據得分區間返回元素。 前面加( 表示開區間，默認閉區間。
zscore d c //獲取 c的score
zincrby d 10 tom //將tom增加10分
zrank d c //查看key(d)中c按得分的排名 0是第一名
zrem d a //刪除a 刪除多個元素
zremrangebyrank d 0 1 //刪除排名段內的數據。
zremrangebyscore d 10 200 //刪除指定得分區間的數據。
6、key 等base操作
del key //刪除key
exists key //判斷key是否存在。
keys asd* //查看key
type asdkey //查某個key的數據類型
dump key //序列化某個key
restore b 0 "\x00\aqwerasd\t\x00\xbe\x06\xe9M#\xa8\xd0j" //將值以0(永久) ttl 反序列化到一個key b
expire b 10 //設置過期時間爲 10s
expireat b 1590721735 //設置過期時間爲一個時間戳的時間。
pexpire b 1000 //以毫秒設置過期時間
persist b //刪除key的過期時間。
move key db //將key移到別的庫。
migrate host port key destination-db timeout [COPY] [REPLACE]
將 key 原子性地從當前實例傳送到目標實例的指定數據庫上，一旦傳送成功， key 保證會出現在目標實例上，而當前實例上的 key 會被刪除。
rename k1 k2 //將k1改名爲k2 k1不存在返回錯誤。 刪除k1 並將k1的值覆蓋掉k2的值 不同數據類型也可以，但是隻是替換key的名字 內容不變。相同數據類型會完全覆蓋。
renamenx k1 k2 //當k2不存在時 重命名。
randomkey //當前數據庫隨機返回一個key
lpush z 3 1 54 5 1 5 3 2
sort z desc //排序一個key
lpush a 'ads' 'dd' 'abc' 'daqdw'
sort a alpha desc //排序字符串需要加 alpha desc 表示正序還是倒序。
sort a alpha desc limit 1 2 //可以加limit 跟sql的用法一樣。
sort 還可以根據外部key進行排序 用外部key作爲變量排序。 感覺想不到應用場景。
config get *log* //查看redis.conf配置
事務
Redis是單線程，原子性的。 但是多條Redis命令需要被事務包裹才能順序執行。(單線程，但是多客戶端)
multi 開啓一個事務。
incr a 事務要執行的命令 執行回覆 queued
exec 執行命令
discard 客戶端清空事務隊列，並放棄執行事務。
如果exec執行之前出現問題，那麼這個事務一定是執行失敗的。
即使事務中有某條/某些命令執行失敗了， 事務隊列中的其他命令仍然會繼續執行 —— Redis 不會停止執行事務中的命令。
事務不支持回滾。
redis中使用了 watch來保證不會出現不可重複讀、
WATCH 命令可以爲 Redis 事務提供 check-and-set （CAS）行爲。 實現了樂觀鎖。
WATCH 命令可以被調用多次。 對鍵的監視從 WATCH 執行之後開始生效， 直到調用 EXEC 爲止。
unwatch取消監控。
watch key需要執行在multi事務開啓之前，對指定key進行監控。
如果在 WATCH 執行之後， EXEC 執行之前， 有其他客戶端修改了 key 的值， 那麼當前客戶端的事務就會失敗。 程序需要做的， 就是不斷重試這個操作， 直到沒有發生碰撞爲止。程序是你自己寫的！不是redis自個重試。
redis可以使用lua腳本達成事務的效果。
發佈與訂閱
SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三個命令實現了發佈與訂閱信息泛型
發送者將消息發送到通道，接收者只需從感興趣的通道取就行了，發送者和接收者之間是解耦的。
SUBSCRIBE 、 UNSUBSCRIBE 是客戶端訂閱頻道和取消訂閱的命令
SUBSCRIBE foo bar 訂閱兩個頻道。
正在訂閱的客戶端不能發送除了SUBSCRIBE 、 UNSUBSCRIBE 之外的命令。當客戶端訂閱的頻道數量爲0時就可以執行Redis正常命令了。
起兩個客戶端：
127.0.0.1:6379> subscribe cc ----------1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "cc"
3) (integer) 1 >>>當前Redis客戶端監聽了多少個channel
1) "message"
2) "cc"
3) "hello-zhangyong"
127.0.0.1:6379> publish cc hello-zhangyong ----------2
(integer) 1
還可以監聽一個模式
127.0.0.1:6379> psubscribe cc.* -----cc. 爲前綴的
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "cc.*"
3) (integer) 1
1) "pmessage"
2) "cc.*"
3) "cc.a"
4) "1"
1) "pmessage"
2) "cc.*"
3) "cc.b"
4) "2"
127.0.0.1:6379> publish cc.a 1
(integer) 1 ------接收到的客戶端數量
127.0.0.1:6379> publish cc.b 2
(integer) 1
主從複製
主服務器可以有多個從服務器，從服務器也可以有從服務器，可以讓多個從服務器處理讀命令來提升擴展性。
可以通過複製功能，來讓主服務器免於執行持久化操作，關閉主服務器的持久話功能，讓從服務器去做持久話操作。
無論是初次連接還是重新連接， 當建立一個從服務器時， 從服務器都將向主服務器發送一個 SYNC 命令。
接到 SYNC 命令的主服務器將開始執行 BGSAVE ， 並在保存操作執行期間， 將所有新執行的寫入命令都保存到一個緩衝區裏面。
當 BGSAVE 執行完畢後， 主服務器將執行保存操作所得的 .rdb 文件發送給從服務器， 從服務器接收這個 .rdb 文件， 並將文件中的數據載入到內存中。
之後主服務器會以 Redis 命令協議的格式， 將寫命令緩衝區中積累的所有內容都發送給從服務器。
BGSAVE 命令執行之後立即返回 OK ，然後 Redis fork 出一個新子進程，原來的 Redis 進程(父進程)繼續處理客戶端請求，而子進程則負責將數據保存到磁盤，然後退出。
psync
這個特性需要主服務器爲被髮送的複製流創建一個內存緩衝區（in-memory backlog）， 並且主服務器和所有從服務器之間都記錄一個複製偏移量（replication offset）和一個主服務器 ID （master run id）， 當出現網絡連接斷開時， 從服務器會重新連接， 並且向主服務器請求繼續執行原來的複製進程：
如果從服務器記錄的主服務器 ID 和當前要連接的主服務器的 ID 相同， 並且從服務器記錄的偏移量所指定的數據仍然保存在主服務器的複製流緩衝區裏面， 那麼主服務器會向從服務器發送斷線時缺失的那部分數據， 然後複製工作可以繼續執行。
否則的話， 從服務器就要執行完整重同步操作。
配置從服務器，設置 slaveof ip port 就可以了，也可以不改配置文件，直接在命令行執行。
從服務器的只讀模式通過 slave-read-only 配置。默認開啓、 >>>主服務器的配置項。
從服務器可以通過 masterauth 配置主服務器的密碼
持久化
redis持久化有兩種方式，AOF&RDB
rdb持久化可以在指定的時間間隔內生成數據集的時間點快照。
AOF持久化記錄服務器執行的所有寫操作命令，並在服務器啓動時，通過重新執行這些命令來還原數據集。
Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啓時， 它會優先使用 AOF 文件來還原數據集， 因爲 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整。
RDB優點：適合備份，一個時間段的數據集，這個特別像MySQL複製的按行復制。恢復的速度比AOF的快。
RDB確定：RDB保存的是整個數據集的狀態，所以它並不是一個輕鬆的操作， 比如5分鐘執行一次，那麼還會至少丟這五分鐘的數據。
每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工作。 在數據集比較龐大時， fork() 可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端； 如果數據集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。
save 60 1000 保存快照的頻率。
快照功能並不是非常耐久（durable）： 如果 Redis 因爲某些原因而造成故障停機， 那麼服務器將丟失最近寫入、且仍未保存到快照中的那些數據。
把快照存儲在名爲dump.rdb的文件中
AOF優點：
AOF可以設置不同的fsync策略
AOF 文件是一個只進行追加操作的日誌文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日誌因爲某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
Redis 還可以在後臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。
AOF缺點：
對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。
appendonly yes 打開AOF
每當 Redis 執行一個改變數據集的命令時（比如 SET）， 這個命令就會被追加到 AOF 文件的末尾。
這樣的話， 當 Redis 重新啓時， 程序就可以通過重新執行 AOF 文件中的命令來達到重建數據集的目的。
AOF重寫
AOF文件中的命令全部以Redis協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在後臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
執行 BGREWRITEAOF 命令， Redis 將生成一個新的 AOF 文件， 這個文件包含重建當前數據集所需的最少命令。
比如：執行100次 incr命令，最後結果是加了100，沒必要記錄100次。
以下是 AOF 重寫的執行步驟：
Redis 執行 fork() ，現在同時擁有父進程和子進程。
子進程開始將新 AOF 文件的內容寫入到臨時文件。
對於所有新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF 文件的末尾： 這樣即使在重寫的中途發生停機，現有的 AOF 文件也還是安全的。
當子進程完成重寫工作時，它給父進程發送一個信號，父進程在接收到信號之後，將內存緩存中的所有數據追加到新 AOF 文件的末尾。
搞定！現在 Redis 原子地用新文件替換舊文件，之後所有命令都會直接追加到新 AOF 文件的末尾。
AOF持久化頻率
你可以配置 Redis 多久纔將數據 fsync 到磁盤一次。
有三個選項：
每次有新命令追加到 AOF 文件時就執行一次 fsync ：非常慢，也非常安全。
每秒 fsync 一次：足夠快（和使用 RDB 持久化差不多），並且在故障時只會丟失 1 秒鐘的數據。
從不 fsync ：將數據交給操作系統來處理。更快，也更不安全的選擇。
推薦（並且也是默認）的措施爲每秒 fsync 一次， 這種 fsync 策略可以兼顧速度和安全性。
如果AOF文件在寫入時出現問題，redis-check-aof --fix 使用這個命令來恢復。
執行如下命令切換RDB---->AOF
redis-cli> CONFIG SET appendonly yes
redis-cli> CONFIG SET save ""
redis會優先使用aof方式恢復數據集。
RDB就是Redis的備份方式。
sentinel管理多個Redis服務器(哨兵)
sentinel執行三個任務：
監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級爲新的主服務器， 並讓失效主服務器的其他從服務器改爲複製新的主服務器； 當客戶端試圖連接失效的主服務器時， 集羣也會向客戶端返回新主服務器的地址， 使得集羣可以使用新主服務器代替失效服務器。
sentinel 是一個分佈式系統，可以運行多個sentinel進程。這些進程使用流言協議（gossip protocols)來接收關於主服務器是否下線的信息， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作爲新的主服務器。
對於 redis-sentinel 程序， 你可以用以下命令來啓動 Sentinel 系統：
redis-sentinel /path/to/sentinel.conf
對於 redis-server 程序， 你可以用以下命令來啓動一個運行在 Sentinel 模式下的 Redis 服務器：
redis-server /path/to/sentinel.conf --sentinel
兩種方法都可以啓動一個 Sentinel 實例。
啓動 Sentinel 實例必須指定相應的配置文件， 系統會使用配置文件來保存 Sentinel 的當前狀態， 並在 Sentinel 重啓時通過載入配置文件來進行狀態還原。
如下是一個sentinel 所需的最少配置。
第一行配置指示 Sentinel 去監視一個名爲 mymaster 的主服務器， 這個主服務器的 IP 地址爲 127.0.0.1 ， 端口號爲 6379 ， 而將這個主服務器判斷爲失效至少需要 2 個 Sentinel 同意 （只要同意 Sentinel 的數量不達標，自動故障遷移就不會執行）。
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000 選項指定了 Sentinel 認爲服務器已經斷線所需的毫秒數。
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1 選項指定了在執行故障轉移時， 最多可以有多少個從服務器同時對新的主服務器進行同步， 這個數字越小， 完成故障轉移所需的時間就越長。
無論你設置要多少個 Sentinel 同意才能判斷一個服務器失效， 一個 Sentinel 都需要獲得系統中多數（majority） Sentinel 的支持， 才能發起一次自動故障遷移， 並預留一個給定的配置紀元 （configuration Epoch ，一個配置紀元就是一個新主服務器配置的版本號）。
換句話說， 在只有少數（minority） Sentinel 進程正常運作的情況下， Sentinel 是不能執行自動故障遷移的。
sentinel <選項的名字> <主服務器的名字> <選項的值>
如果服務器在給定的毫秒數之內， 沒有返回 Sentinel 發送的 PING 命令的回覆， 或者返回一個錯誤， 那麼 Sentinel 將這個服務器標記爲主觀下線（subjectively down，簡稱 SDOWN ）。
不過只有一個 Sentinel 將服務器標記爲主觀下線並不一定會引起服務器的自動故障遷移： 只有在足夠數量的 Sentinel 都將一個服務器標記爲主觀下線之後， 服務器纔會被標記爲客觀下線（objectively down， 簡稱 ODOWN ）， 這時自動故障遷移纔會執行。
主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。
客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後， 得出的服務器下線判斷。 （一個 Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認爲給定的服務器已下線。）
如果一個服務器沒有在 master-down-after-milliseconds 選項所指定的時間內， 對向它發送 PING 命令的 Sentinel 返回一個有效回覆（valid reply）， 那麼 Sentinel 就會將這個服務器標記爲主觀下線。
客觀下線條件只適用於主服務器： 對於任何其他類型的 Redis 實例， Sentinel 在將它們判斷爲下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。
只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 並對失效的主服務器執行自動故障遷移操作。
每個sentinel都需要定期執行的任務
每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務器、從服務器以及其他 Sentinel 實例發送一個 PING 命令。
如果一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那麼這個實例會被 Sentinel 標記爲主觀下線。 一個有效回覆可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一個主服務器被標記爲主觀下線， 那麼正在監視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。
如果一個主服務器被標記爲主觀下線， 並且有足夠數量的 Sentinel （至少要達到配置文件指定的數量）在指定的時間範圍內同意這一判斷， 那麼這個主服務器被標記爲客觀下線。
在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記爲客觀下線時， Sentinel 向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改爲每秒一次。
當沒有足夠數量的 Sentinel 同意主服務器已經下線， 主服務器的客觀下線狀態就會被移除。 當主服務器重新向 Sentinel 的 PING 命令返回有效回覆時， 主服務器的主管下線狀態就會被移除。
自動發現 Sentinel 和從服務器
一個 Sentinel 可以與其他多個 Sentinel 進行連接， 各個 Sentinel 之間可以互相檢查對方的可用性， 並進行信息交換。
你無須爲運行的每個 Sentinel 分別設置其他 Sentinel 的地址， 因爲 Sentinel 可以通過發佈與訂閱功能來自動發現正在監視相同主服務器的其他 Sentinel ， 這一功能是通過向頻道 __sentinel__:hello 發送信息來實現的。
與此類似， 你也不必手動列出主服務器屬下的所有從服務器， 因爲 Sentinel 可以通過詢問主服務器來獲得所有從服務器的信息。
每個 Sentinel 會以每兩秒一次的頻率， 通過發佈與訂閱功能， 向被它監視的所有主服務器和從服務器的 __sentinel__:hello 頻道發送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）。
每個 Sentinel 都訂閱了被它監視的所有主服務器和從服務器的 __sentinel__:hello 頻道， 查找之前未出現過的 sentinel （looking for unknown sentinels）。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中， 這個列表保存了 Sentinel 已知的， 監視同一個主服務器的所有其他 Sentinel 。
Sentinel 發送的信息中還包括完整的主服務器當前配置（configuration）。 如果一個 Sentinel 包含的主服務器配置比另一個 Sentinel 發送的配置要舊， 那麼這個 Sentinel 會立即升級到新配置上。
在將一個新 Sentinel 添加到監視主服務器的列表上面之前， Sentinel 會先檢查列表中是否已經包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ， 如果是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 然後再添加新 Sentinel 。
還有個TILT模式，這個是sentinel 依賴計算機時間，如果時間出問題，sentinel應該保持在TILT模式，而不是繼續正常工作。
當 Sentinel 進入 TILT 模式時， 它仍然會繼續監視所有目標， 但是：
它不再執行任何操作，比如故障轉移。
當有實例向這個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令時， Sentinel 返回負值： 因爲這個 Sentinel 所進行的下線判斷已經不再準確。
如果 TILT 可以正常維持 30 秒鐘， 那麼 Sentinel 退出 TILT 模式。
>>>>>>>>>>>>>>>>>redis 集羣實際上就是一個高可用手段和負載手段。