Redis基礎知識及集群搭建

Redis基礎知識及集群搭建張西強2015年2月目錄Redis基礎知識Redis集群搭建12Redis簡介——Redis，典型的NoSQL數(shù)據(jù)庫服務器，采用KEY-VALUE存儲結構，可以作為服務程序獨立運行于自己的服務器主機，同時作為內(nèi)存數(shù)據(jù)庫，不用IO讀取硬盤數(shù)據(jù)，能夠快速響應請求。Redis是什么？Redis有什么特點？——支持持久化、支持多種數(shù)據(jù)結構、支持主從復制、免費與關系型數(shù)據(jù)庫比較——redis由于其存儲結構相對簡單，因此并不能對復雜的邏輯關系提供很好的支持，然而在適用于Redis的場景中，我們卻可以由此而獲得效率上的顯著提升。Redis的數(shù)據(jù)結構作為NOSQL數(shù)據(jù)庫之一的redis，除了支持基本key-value方式，還支持結構化存儲，以適應各類應用場景：String: 字符串類型List:

鏈表類型Hashes: 哈希類型Set: 集合類型Sorted-Sets 有序集合類型字符串類型：StringString是最常用的一種數(shù)據(jù)類型，普通的key/value存儲都可以歸為此類。當然，也可以存儲圖片，視頻等序列化對象，Value最多可以容納的數(shù)據(jù)長度是512M。1.賦值：

SETKEYVALUE

MSETKEY1VALUE1[KEY][VALUE2]

SETBITKEYOFFSET1/02.取值：

GETKEY

MGETKEY1[KEY] GETBITKEYOFFSET3.字符串操作：

STRLENKEY

SETRANGEKEYOFFSETVALUES

GETRANGEKEYSTARTEND

4.數(shù)字操作：

INCRKEY DECRKEY INCRBYKEYdecrement/DECRBYKEYdecrement5.其他：

SETEXKEYSECONDSKEYVALUEStringLENBUF[]FREE鏈表類型：ListList類型是按照插入順序排序的字符串鏈表。和數(shù)據(jù)結構中的普通鏈表一樣，我們可以在其頭部(left)和尾部(right)添加新的元素。在插入時，如果該鍵并不存在，Redis將為該鍵創(chuàng)建一個新的鏈表。1.賦值：

LPUSH/RPUSHKEYV1V2…VN

LPUSHX/RPUSHXKEYVALUE2.取值：

LPOP/RPOPKEY

LRANGEKEYSTARTEND GETBITKEYOFFSET3.INDEX操作：

LSETkeyindexvalue

LINDEXKEYindex

4.取長度：

LLENKEY5.截?。?/p>

LTRIMkeystartstop場景：LIST可以作為消息隊列，LPUSH鏈表頭作為生產(chǎn)者插入消息，RPOP作為消費者取得消息。哈希類型：Hashes我們可以將Redis中的Hashes類型看成具有StringKey和StringValue的map容器。所以該類型非常適合于存儲值對象的信息。1.賦值：

HSETKEYFILEDVALUE

HMSETKEYFILEDVALUE[FILED1][VALUE]2.取值：

HGETKEY HMGETKEY[KEY]

HKEYSKEY HVALSKEY

HGETALLKEY3.刪除：

HDELFILED[FILED]

4.取長度：

HLEN5.存在判定：

HEXISTSkeyfiled場景：AIOP中用戶標簽信息使用HASHMAP存儲，存儲結構為user:phonetag1val1tag2val2，AIOP傳遞客戶手機號，即可通過HGETuser:phonetag1tag2取出標簽值。集合類型：Sets在Redis中，我們可以將Set類型看作為沒有排序的字符集合，就像什錦果凍，只是聚集在一起，沒有順序，這和List類型不一樣，另外要注意Set集合中不允許出現(xiàn)重復的元素，而且Set支持多個Sets之間的差、并、交集操作。1.新增：

SADDKEYM1M2…2.查詢：

SMEMEBERSKEY SPOPKEY SRANDMEMBERKEY3.刪除：

SREMKEYM1M2…MN4.取長：

SCARDKEY5.存在判定：

SISMEMBERKEYMEMBER6.聚合運算：

SDIFFKEY1KEY2… SINTERKEY1KEY2… SUINONKEY1KEY2…場景：COC中將符合標簽的用戶進行聚類，存放到Set中，比如set1存放學生標簽用戶、set2存放低消費用戶、set3存放非合約用戶，那么取出可能購買小米的低消非合約學生用戶群： 1.SINTERSTOREasetset1set2

2.SDIFFasetset3有序集合中也不允許有重復數(shù)據(jù)，它比Set多了一個score，Redis正是通過score來為集合中的成員進行從小到大的排序。需要注意的是，盡管Sorted-Sets中的成員必須是唯一的，但是分數(shù)(score)卻是可以重復的。1.查詢：

ZADDKEYSCORENMBR1…SCORENMBRN2.刪除：

ZREMKEYMBR1MBR2…MBRN3.取前幾位/后幾位：

ZRANGEkeystartstop[WITHSCORES]

ZREVRANGEkeystartstop[WITHSCORES]

4.統(tǒng)計數(shù)量：

ZCOUNTkeyminmax5.取分數(shù)：

ZSCOREkeymember場景：可以用于一個大型在線游戲的積分排行榜。每當玩家的分數(shù)發(fā)生變化時，可以執(zhí)行ZADD命令更新玩家的分數(shù)，此后再通過ZRANGE命令獲取積分TOPTEN的用戶信息。當然我們也可以利用ZRANK命令通過username來獲取玩家的排行信息。最后我們將組合使用ZRANGE和ZRANK命令快速的獲取和某個玩家積分相近的其他用戶的信息。有序集合類型：Sorted-Sets以上各類數(shù)據(jù)類型的操作全部是針對于KEY關聯(lián)的value操作，redis也提供了單獨對key值的操作匹配: KEYSpattern例如keys*列出所有key值刪除： DELkey[key...]例如dellist1刪除鏈表1是否存在： EXISTSkey鍵值遷移： MOVEkeydb

--移向數(shù)據(jù)庫select01可選擇數(shù)據(jù)庫查看數(shù)據(jù)類型： TYPEkey

設置超時： EXPIREkeyseconds

/EXPIREATkeytimestamp

取消超時： PERSISTkey其他操作Redis在設計之初就被定義為長時間不間斷運行的服務進程，因此大多數(shù)系統(tǒng)配置參數(shù)都可以在不重新啟動進程的情況下立即生效，我用到的有：Slaveofhostport修改主從關系 Info當前系統(tǒng)信息

shutdown關閉redisflushall清空所有keysflushdb清空當前數(shù)據(jù)庫keyRedis主從復制的優(yōu)勢：1.支持一主多從2.支持級聯(lián)復制：master-slave-slave，分載master同步壓力3.支持非阻塞式數(shù)據(jù)同步：數(shù)據(jù)同步與對外服務能力分離，互不影響4.支持slave只讀模式Redis主從復制主從復制流程1).RDB持久化：

該機制是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。

優(yōu)點：1.只有一份rdb文件，可隨時備份

2.比AOF文件小，加載效率高

3.只提供fork子進程，不阻塞主進程，IO操作比較少2).AOF持久化:

該機制將以日志的形式記錄服務器所處理的每一個寫操作，在Redis服務器啟動之初會讀取該文件來重新構建數(shù)據(jù)庫，以保證啟動后數(shù)據(jù)庫中的數(shù)據(jù)是完整的。

優(yōu)點：1.每改動同步數(shù)據(jù)安全性好

2.APPEND方式追加日志，不會對舊日志文件產(chǎn)生影響3).無持久化：

我們可以通過配置的方式禁用Redis服務器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。4).同時應用AOF和RDB。Redis持久化1).RDB持久化：

Dump快照的機制：

1).Redis先fork子進程。

2).子進程將快照數(shù)據(jù)寫入到臨時RDB文件中。

3).當子進程完成數(shù)據(jù)寫入操作后，再用臨時文件替換老的文件。

redis.conf配置修改：

save9001

#在900秒后，如果至少有1個key發(fā)生變化，則dump內(nèi)存快照。

save30010

#在300秒后，如果至少有10個key發(fā)生變化，則dump內(nèi)存快照。

save6010000

#在60秒之后，如果至少有10000個key發(fā)生變化，則dump內(nèi)存快照。

（注釋1：可以配置多個條件組成持久化策略）（注釋2：fork進程開銷大，數(shù)據(jù)量太大時，消耗cpu和內(nèi)存資源，影響父進程不能及時響應請）

2).AOF持久化：

redis.conf配置修改

appendonlyyes

appendfsyncalways

#每次有數(shù)據(jù)修改發(fā)生時都會寫入AOF文件。

appendfsynceverysec

#每秒鐘同步一次，該策略為AOF的缺省策略。

appendfsyncno

#從不同步。高效但是數(shù)據(jù)不會被持久化。

（注釋：一般選擇always每修改同步，保證數(shù)據(jù)安全）Redis持久化2Redis作為內(nèi)存數(shù)據(jù)庫，所有數(shù)據(jù)都從內(nèi)存中拿，省去讀寫磁盤的消耗（持久化是由fork子進程處理，主服務對外能力不受影響），響應速度極快。但我們不可能將所有的數(shù)據(jù)都讀到內(nèi)存中，所以內(nèi)存資源顯得非?？少F，我們就要優(yōu)化存儲結構，使得好鋼用在刀刃上.Redis內(nèi)存優(yōu)化思考1.盡量使用hash

COC中每個客戶會對應上千個標簽，每個客戶就是一個對象,我們?nèi)绾未鎯λ縫hone序列化對象：tag1tag2tag3…tagnkeyvaluePhone:tag1keyvaluephonekeyvaluev1Phone:tag2v2Phone:tagnvntag1v1tag2v2tagnvn序列化對象：要求在redis存儲前對象進行序列化操作，每次取出后還要執(zhí)行反序列化操作，開銷太大；如果只想取對象的某一個值，都需要將整個對象取出，還要解決并發(fā)、數(shù)據(jù)一致性、加鎖等復雜問題。K-V模式:phone字段冗余HASHMAP:

phone字段只出現(xiàn)一次，避免數(shù)據(jù)冗余Redis內(nèi)存優(yōu)化思考續(xù)1存儲結構比較比較K-V結構與HASHMAP結構對內(nèi)存的影響：前提假設COC有1千萬用戶對象，每個用戶對象有1000個標簽，Redis存儲的phone_no格式為185XXXXXXXX。1.根據(jù)ASCII編碼，每位數(shù)字占用單字節(jié)字符，每個phone_no占用11Byte.

2.K-V結構中，存放一個完成對象，每個phone_no需要重復1000次，所以存放1千萬個對象phone_no為1000*1千萬，所占空間為：1000次*10000000個*11B/1024/1024=102.45G內(nèi)存優(yōu)化效果Redis內(nèi)存優(yōu)化思考續(xù)22.根據(jù)業(yè)務場景，考慮使用BITMAP

前面我們在講String的時候提到過兩個命令：setbitkeyoffset0/1和getbitkeyoffset，這兩個命令是在位上進行0/1賦值和取值。假設還是1000W用戶，每個用戶有1000個0/1標簽，我們可以使用bitmap來存放這些數(shù)據(jù)：10010110000010phone1tag1tag1000Setbitphone111Setbitphone199911000bit/8/1024/1024=0.000119MB所有標簽總占用的內(nèi)存為：0.000119MB*1000W=1.19GB,如果使用key-value結構（包括hashes），內(nèi)存占用至少是它的8倍。Redis內(nèi)存優(yōu)化思考續(xù)3只適合01型標簽需要位移位與標簽的字典表，屬于額外開銷，但相對而言字典表offset數(shù)字可共享redis數(shù)字池，比直接存字符串要省空間。犧牲時間換空間：1.維護字典表2.入庫需要對應轉(zhuǎn)化3.出庫計算也需要轉(zhuǎn)換BITMAP使用總結本次redis基礎知識中，我們介紹了基本的數(shù)據(jù)結構及常用命令、數(shù)據(jù)類型的場景舉例、redis主從復制機制、持久化機制、以及內(nèi)存優(yōu)化。無論是數(shù)據(jù)結構選擇還是內(nèi)存優(yōu)化，都要結合具體的業(yè)務場景和業(yè)務要求，沒有通用的最佳推薦模式，只有最符合需求的模式，所以我們需要我們不斷嘗試、不斷優(yōu)化。Redis基礎總結目錄Redis基礎知識Redis集群搭建12集群及集群目的目的：高可用、負載均衡、易擴展、數(shù)據(jù)安全、性能提升技術：集群地址（虛擬IP）、網(wǎng)絡通信(監(jiān)控消息)功能：負載均衡、讀寫分離、故障轉(zhuǎn)移集群集群指的是將幾臺服務器集中在一起，實現(xiàn)同一業(yè)務Redis集群部署方案1方案1：haproxy+keepalived+redis集群Redis集群架構redis服務器haproxy服務器Redis集群部署方案1REDIS：通過REDIS的配置文件，可以實現(xiàn)主從復制、讀寫分離的工作。HAPROXY：通過haproxy的配置文件，實現(xiàn)負載均衡，haproxy負載均衡算法有多種，一般采用輪詢方式，當某臺redis-salve故障時，haproxy會將其摘除。Keepalived：是一個基于VRRP協(xié)議來實現(xiàn)服務器高可用方案，可以利用其來避免haproxy單點故障,保證高可用。方案1redishaproxykeepalivedRedis部署目標Redis部署1機器1:

redis主節(jié)點(3:6379)

從節(jié)點(3:63791)

從節(jié)點(3:63792)機器1:haproxy+keepalived

機器2:

從節(jié)點0:63793

從節(jié)點

0:63794機器2:

haproxy+keepalived機器1:以root用戶創(chuàng)建以下目錄部署環(huán)境進入/usr/local/src目錄Redis下載：wget

http://download.redis.io/releases/redis-2.8.9.tar.gz

Redis部署2解壓redis安裝包：編譯redis:Redis部署3復制配置文件，執(zhí)行如下：修改redis.conf:bind設為3#redis服務跟該IP綁定

dir設為/usr/local/redis/datapidfile/var/run/redis.piddbfilename設為dump.rdbdaemonize設為yesport6379修改redis-slave1:bind3#綁定IPpidfile/var/run/redis-slave1.piddbfilenamedump-slave1.rdbdir/usr/local/redis/dataport63791slaveof36379#是36379的從存儲daemonizeyes#后臺開啟守護進程slave-read-onlyyes#slave只讀（注：不要覆蓋原文件，找到相應的字段修改即可，其他保持原樣）Redis部署4修改redis-slave2:bind3pidfile/var/run/redis-slave2.piddbfilenamedump-slave2.rdbdir/usr/local/redis/dataport63792slaveof36379daemonizeyes啟動slave的redis服務：機器2:機器2上的部署如同機器1，只要配置從服務器文件即可啟動機器1上的redis-master可通過ps–ef|grepredis查看服務是否啟動Redis部署5驗證：首先確認已啟動：機器1上：redis-serverredis.confredis-serverredis-slave1redis-serverredis-slave2機器2上：redis-serverredis-slave3redis-serverredis-slave4

到現(xiàn)在已完成redis集群配置,且只有3

6379可寫數(shù)據(jù)，其余slave機器只能讀數(shù)據(jù)redis-cli

-h

3

-p6379Info可以看到這樣子就是成功了:注1：配置文件中默認主從復制是開啟的，通過上圖可以看到命令機器為master，下掛4個從服務器注2：查看我編寫的redis啟動關閉腳本

redis

該腳本放在/etc/init.d/中，通過serviceredisstart/stop使用Redis部署報錯處理1.如果報下面的錯，說明master的redis沒有啟動，啟動它既可2.在2號機子上執(zhí)行報錯，請檢查防火墻策略

Haproxy部署目標Haproxy部署進入機器11.安裝cd/usr/local/srctar-zxvfhaproxy-0cdhaproxy-0makeTARGET=linux26PREFIX=/usr/local/haproxymakeinstallPREFIX=/usr/local/haproxy注意：要查看linux系統(tǒng)的內(nèi)核信息，要與TARGET匹配2.配置cd/usr/local/haproxy#haproxy默認是沒有配置文件的，需要自己手機創(chuàng)建vi

haproxy.cfg

3.查看是否成功：/usr/local/haproxy/sbin/haproxy-f/usr/local/haproxy/haproxy.cfg#啟動ps-ef|grephaproxy#查進程訪問13:8888/haproxyadmin

機器1與機器2上的haproxy配置部署是一樣的，通過keeplived采用單活方式對外提供服務Keepalived部署進入機器1cd/usr/local/src/wget

/software/keepalived-1.2.12.tar.gztar-zxvfkeepalived-1.2.12.tar.gzcdkeepalived-1.2.12./configuremake&&make

install注：若這里報錯提示沒有裝openssl，則執(zhí)行yum-yinstallopenssl-devel安裝，若還有其他的包沒裝，則執(zhí)行yum命令進行安裝cp/usr/local/etc/rc.d/init.d/keepalived/etc/rc.d/init.d/cp/usr/local/etc/sysconfig/keepalived/etc/sysconfig/mkdir/etc/keepalivedcp/usr/local/etc/keepalived/keepalived.conf/etc/keepalived/ln-s/usr/local/sbin/keepalived/usr/sbin/vi/etc/keepalived/keepalived.conf注1：此處注意{與之前的字符之間必須有空格，否則無法正常調(diào)用，例如VI_1{

這樣寫，就在keepalived啟動時無法建立VIP00vi/etc/keepalived/check_haproxy.sh注1：`是esc下面的符號，不是單引號。另外if\[]\表達式注意空格，另外要注意/etc/keepalived/check_haproxy.sh必須賦予可執(zhí)行權限：chmod777/etc/keepalived/check_haproxy.sh，否則會啟動不起來Keepalived配置文件vrrp_scriptchk_haproxy{script"/etc/keepalived/check_haproxy.sh"interval2}global_defs{router_idLVS_DEVEL}vrrp_instanceVI_1{stateBACKUP#備機MASTER主機interfaceeth0#綁定的網(wǎng)卡virtual_router_id53#與master保持一致，組號,同組能通知priority120#要比master低，選舉的依據(jù)advert_int1authentication{auth_typePASSauth_type1111}track_script{chk_haproxy}virtual_ipaddress{00#VIP}}check_haproxy.sh

腳本如下：#!/bin/bash#A=`ps-Chaproxy--no-header|wc-l`

#keepalived檢查本機haproxy是否啟動if[[`ps-Chaproxy--no-header|wc-l`-eq0]];#haproxy進程是否為0thenecho"haproxynotrunning,attempttostartup"/usr/local/haproxy/sbin/haproxy-f/usr/local/haproxy/haproxy.cfg#如果為零則啟動haproxysleep5if[[`ps-Chaproxy--no-header|wc-l`-eq0]];#判定是否啟動成功then/etc/init.d/keepalivedstopecho"haproxystartfailure,stopkeepalived"elseecho"haproxystartedsuccess"fiFiKeepalived.confcheck_haproxy.shkeepalived驗證機器1、2上分別執(zhí)行：/etc/rc.d/init.d/keepalivedstart通過ipadd，出現(xiàn)如下表示VIP建立通過ps-ef|grephaproxy查看是否啟動haproxy通過ps-ef|grepkeepalived查看是否啟動keepalivedkeepalived驗證通過

tail-f/var/log/messages,出現(xiàn)以下信息為正確如果出現(xiàn)以下錯誤，請檢查/etc/keepalived/check_haproxy.sh是否是可執(zhí)行文件集群方案1驗證主從復制驗證：在master中執(zhí)行setkey1“test”，在slave1、

slave2、slave3、

slave4中執(zhí)行getkey1,獲得“test”,測試通過讀寫分離驗證：

在各slave中執(zhí)行setkey1“test”,報以下錯誤測試通過(error)READONLYYoucan'twriteagainstareadonlyslave.負載均衡驗證：

redis-cli–h00–p63790getkey1得“test””,測試通過負載均衡高可用驗證：

kill-9haproxy進程號，redis-cli–h00–p63790

getkey1得“test””,測試通過擴展性驗證：

slave3上執(zhí)行slaveof063798脫離master,再執(zhí)行slaveof36379加入到master，說明slave可不宕機擴展驗證方式Redis集群部署方案2方案2：redis官方Sentinel集群管理工具Sentinel1Sentinel2Sentinel3Sentinel4masterslaveslaveslave哨兵群Redis集群ping發(fā)布訂閱Redis集群部署方案2Sentinel：負責對redis群中的主從服務器監(jiān)控、提醒和自動故障轉(zhuǎn)移。Redis群：對外提供redis服務方案2Sentinel群Redis群Sentinel原理綜述：RedisSentinel是一個分布式系統(tǒng)，你可以在一個架構中運行多個Sentinel進程（progress），個數(shù)與redis集群中服務個數(shù)沒有關聯(lián)關系。這些進程使用流言協(xié)議（gossipprotocols)來接收關于主服務器是否下線的信息，并使用投票協(xié)議（agreementprotocols）來決定是否執(zhí)行自動故障遷移，以及選擇哪個從服務器作為新的主服務器。流言協(xié)議：Sentinel服務通過ping命令來確認監(jiān)控服務是否正常，當足夠多數(shù)量的sentinel都確認監(jiān)控的同一服務停止了（主觀下線），則判定該服務停止（客觀下線）。跟流言很相似，一個哨兵說看不到目標了，他會向其他哨兵詢問是否看得到目標，足夠多的哨兵說看不到目標，則說明目標消失。一般來說，足夠多就是一半及以上。投票協(xié)議：投票協(xié)議就像選舉，sentinel群根據(jù)一定的規(guī)則，從redis群中選擇一個新的主服務器，并使其他redis服務器作為新服務器的slave,并修改自身的配置文件原理Sentinel配置Sentinel集群部署很簡單，而且它跟redis集群邏輯上是獨立，可以啟動任意多個（當然最少要兩個才有效果）服務，只需要配置Sentinel.conf文件即可：port26378 #sentinel服務端口daemonizeyes #開啟守護進程logfile“/var/log/redis/sentinel1.log“ #sentinel運行日志sentinelmonitormymaster363792 #監(jiān)控主服務及判定客觀下線所需要的最少主觀下線sentinel服務數(shù)sentineldown-after-millisecondsmymaster60000 #本sentinel服務多長時間收不到消息才能判定主觀下線sentinelfailover-timeoutmymaster180000 #故障轉(zhuǎn)移判定超時間sentinelparallel-syncsmymaster1#故障轉(zhuǎn)移后，允許最多幾個slave可以同時從新服務器同步數(shù)據(jù)配置Sentinel問題及注意事項配置文件自動生成內(nèi)容：服務在配置文件中指定從服務器地址及其他sentinel服務地址，sentinel的發(fā)布訂閱功能支持向所監(jiān)控master服務發(fā)布和訂閱消息，而消息中會包含從服務器地址、端口，其他sentinel的信息，sentinel拿到其他sentinel服務消息后，會寫入自己的配置文件中。Failover時間：當新master代替老master后，其他的slave會自動使用新master，同時向新master發(fā)布同步數(shù)據(jù)請求，所有slave同步完成后，這次故障轉(zhuǎn)移才算完成。而本參數(shù)就是規(guī)定最多有幾個slave可以同時進行數(shù)據(jù)同步，failover總時長是：（slaveCount%

parallel-syncs+1）次*單位同步時長parallel-syncs：從2中看出參數(shù)越小，故障轉(zhuǎn)移時間越長?；A中提到過同步數(shù)據(jù)的fork子進程雖然不會阻塞服務，但是會占用內(nèi)存，可能使主服務不能響應指令。所以本參數(shù)越大，同時不能響應指令的slave就越多，就越影響對外服務，甚至使對外服務能力中斷。所以，配置參數(shù)是，我們要盡量減少故障轉(zhuǎn)移時長，同時也要預留足夠的slave對外提供服務。問題及注意事項Sentinel部署環(huán)境Redis：

主節(jié)點(3:6379)

從節(jié)點(3:63791)

從節(jié)點(3:63792)Sentinel：

S(3:26379)

S1(3:26378)53機器Redis：

主節(jié)點(0:63793)

從節(jié)點(0:63794)

Sentinel：

S(0:26379)

S(0:26378)30機器配置文件Sentinel配置文件如右：1.根據(jù)實際情況修改port2.根據(jù)需要修改日志文件Sentinel部署2啟動sentinel方法1：redis-sentinel

sentinel.conf方法2：redis-server sentinel.conf--sentinel啟動成功：ps–ef|grepredis機器5330啟動redis機器5330redis-serverredis.confRedis-serverredis-slave1Redis-serverredis-slave2Redis-serverredis-slave3Redis-serverredis-slave4Sentinel部署3觀察日志命令1：\[10306]03Feb18:52:35.231#Sentinelrunidis242ce4ede4b8d9100f2f761ec00fc2774bca9ad7[10306]03Feb18:52:35.231#+monitormastermymaster36379quorum2[10306]03Feb18:53:35.261#+sdownmastermymaster36379[10306]03Feb19:02:44.126*+sentinelsentinel0:26378026378@mymaster36379[10306]03Feb19:02:44.143#-sdownmastermymaster36379[10306]03Feb19:02:44.144*+sentinelsentinel3:26378326378@mymaster36379[10306]03Feb19:02:44.188*+sentinelsentinel0:26379026379@mymaster36379綠色：sentinel啟動后監(jiān)控master，6秒后未收到響應，判定客觀下線（+sdown）紅色：master啟動后，sentinel發(fā)布消息至master，也收到其他sentinel發(fā)布的消息，將這些sentinel添加到配置文件，并開始監(jiān)控。Sentinel們判定master活著，取消主觀下線和客觀下線狀態(tài)。配置文件新增內(nèi)容Sentinel部署4觀察日志命令2：redis-cli-h3-p63791slaveof36379[10306]03Feb19:23:08.501*+slaveslave3:63791363791@mymaster36379說明：一個新的從服務器已經(jīng)被Sentinel識別并關聯(lián)（

+slave）命令3：在53與30上執(zhí)行slaveof36379[10306]03Feb19:26:29.324*+slaveslave3:63792363792@mymaster36379[10306]03Feb19:28:19.838*+slaveslave0:63793063793@mymaster36379[10306]03Feb19:28:19.838*+slaveslave0:63794063794@mymaster36379說明：redis集群已經(jīng)啟動，并納入sentinel群監(jiān)控Sentinel部署4觀察日志[10306]03Feb19:36:22.681#+sdownmastermymaster36379[10306]03Feb19:36:22.715#+new-epoch1[10306]03Feb19:36