IT技術互動交流(liu)平(ping)台

十分11选5官网

來源︰IT165收集  發布日期︰2020-02-24 13:13:19

十分11选5官网

從本篇文章開始,我們(men)將(jiang)向讀(du)者介(jie)紹幾種Redis的高可用高負載集群方案。除了si)jie)紹Redis 3.X版本中推薦的原生集群方案外(wai),還會介(jie)紹使用第三方組件搭建Redis集群的方法。本文我們(men)會首先介(jie)紹Redis的高可用集群方案。

十分11选5官网

Redis提供的高可用方案和我們(men)介(jie)紹過的很(hen)多軟件的高可用方案類(lei)似(si),都是使用主(zhu)從節點的思路。即是有一個Master節點在平(ping)時(shi)提供服務,另外(wai)一個或多個Slave節點在平(ping)時(shi)不(bu)提供服務(或只提供數(shu)據讀(du)取服務)。當Master節點由于某些原因停止服務後,再人工/自yuan) 瓿lave節點到Master節點的切xie)還?鰨 員(yuan)閼edis集群繼(ji)續向外(wai)提供服務。既然是要進行(xing)角(jiao)色切xie)唬 乙 笳廡┘詰閼?醞wai)部(bu)調用者來說沒有任何(he)不(bu)同(tong),最重要的就是Master節點和Slave節點的數(shu)據同(tong)步過程。數(shu)據同(tong)步最關鍵的設計思路是如何(he)在數(shu)據一致性(xing)和同(tong)步性(xing)yue)萇險業(ye)揭桓 昝賴鈉ping)衡點

同(tong)步復(fu)制(zhi)的工作思路可以概括為︰Master節點的任何(he)數(shu)據變化(hua)都會立即同(tong)步到一個或多個Slave節點上。只要一個Slave節點同(tong)步失(shi)敗(例如超時(shi)),都會認為整個數(shu)據寫操作過程失(shi)敗。這樣的設計考慮側(ce)重于保證各節點上xi)氖shu)據絕(jue)對一致,完全沒有考慮qian)aster節點的響應性(xing)yue)埽 踔粱岢魷aster節點為了保證數(shu)據一致性(xing)而停止對後續寫操作請求的響應

異(yi)步復(fu)制(zhi)的工作思路可以概括為︰Master節點首先保證對外(wai)部(bu)請求的響應性(xing)yue)埽 lave節點的數(shu)據同(tong)步一般由一個新的進程/線程獨立完成。數(shu)據復(fu)制(zhi)過程由Slave節點周期性(xing)發起或者由它一直駐留在Master節點的連接進行(xing)實時(shi)監控(kong)又或者由Master節點主(zhu)動推送(song)數(shu)據,再或者是同(tong)時(shi)使用多個異(yi)步復(fu)制(zhi)過程。由于在Slave節點進行(xing)數(shu)據同(tong)步時(shi),Master節點一直在處理新的數(shu)據寫請求,所以Slave節點已完成同(tong)步的數(shu)據和Master上xi)氖凳shi)數(shu)據一般會存在一些差異(yi)。例如MySQL原生支持(chi)的數(shu)據復(fu)制(zhi)過程,就是一個異(yi)步過程。

很(hen)顯然異(yi)步復(fu)制(zhi)思路在對調用者的響應性(xing)yue)萇希 硐忠 韌tong)步復(fu)制(zhi)好(hao)得多。但(dan)如果由于異(yi)步復(fu)制(zhi)而導致的節點間數(shu)據差異(yi)達(da)到某chi)殖潭du),就失(shi)去了數(shu)據同(tong)步的意義(yi)了。所以如何(he)減少(shao)節點間的數(shu)據差異(yi)就tong)晌 yi)步復(fu)制(zhi)過程中xing)枰 刈 囊 /strong>。而後者的處理辦法就有很(hen)多了,例如MySQL由第三方jiang)寮?chi)的半同(tong)步方式,又例如講(jiang)解ActiveMQ消息隊列時(shi)提到的AutoAck和DUPS_OK_ACK,再例如我們(men)下文介(jie)紹的Diskless Replication和Master寫保護。

2-1、主(zhu)從復(fu)制(zhi)工作過程

Redis的主(zhu)從復(fu)制(zhi)功(gong)能除了支持(chi)一個Master節點對應多個Slave節點的同(tong)時(shi)進行(xing)復(fu)制(zhi)外(wai),還支持(chi)Slave節點向其(qi)它多個Slave節點進行(xing)復(fu)制(zhi)。這樣就使得架(jia)構師能夠靈活組織業(ye)務緩存數(shu)據的傳播,例如使用多個Slave作為數(shu)據讀(du)取服務的同(tong)時(shi),專(zhuan)門使用一個Slave節點為流(liu)式分析工具(ju)服務。Redis的主(zhu)從復(fu)制(zhi)功(gong)能分為兩(liang)種數(shu)據同(tong)步模式︰全量(liang)數(shu)據同(tong)步和增(zeng)量(liang)數(shu)據同(tong)步。

這里寫圖片描述(shu)

上圖簡要說明了Redis眾?http://www.it165.net/pro/pkqt/" target="_blank" class="keylink">QTWFzdGVyvdq147W9U2xhdmW92rXjtcTIq8G/yv2+3c2ssr25/bPMoaO1sVNsYXZlvdq147j4tqi1xHJ1bl9pZLrNTWFzdGVytcRydW5faWSyu9K71sLKsaOsu/LV31NsYXZluPi2qLXEyc/Su7TO1PbBv82ssr21xG9mZnNldLXEzrvWw9TaTWFzdGVytcS7t9DOxNq05tbQzt63qLaozrvKsaOouvPOxLvhzOG1vaOpo6xNYXN0ZXK+zbvhttRTbGF2ZbeixvDIq8G/zayyvbLZ1/eho9XiyrE8c3Ryb25nPs7ewtvE+srHt/HU2k1hc3RlcrTyv6rBy1JEQr/s1dW5psTco6zL/LrNU2xhdmW92rXjtcTDv9K7tM7Iq8G/zayyvbLZ1/e5/bPMtry74bj80MIvtLS9qE1hc3RlcsnPtcRSRELOxLz+PC9zdHJvbmc+oaPU2lNsYXZlway907W9TWFzdGVyo6yyos3qs8m12tK7tM7Iq8G/yv2+3c2ssr2686OsvdPPwsC0TWFzdGVytb1TbGF2ZbXEyv2+3c2ssr25/bPM0ruw477NysfU9sG/zayyvdDOyr3By6Oo0rKzxs6qsr+31s2ssr2jqaGj1PbBv82ssr25/bPMsrvU2db30qrSwMC1UkRCzsS8/qOsTWFzdGVyu+G9q9DCsvrJ+rXEyv2+3bHku6+y2df3tOa3xdTa0ru49sTatObH+NPyo6zV4rj2xNq05sf40/KyydPDu7fQzrm51Oyho7n9s8zI58/Co7o8L3A+CjxwPjxpbWcgYWx0PQ=="這里寫圖片描述(shu)" src="http://www.it165.net/uploadfile/files/2016/1222/20161222193742342.png" title="" />

為什麼在Master上新lue)zeng)的數(shu)據除了根據Master節點上RDB或者AOF的設置(zhi)進行(xing)日志文件更新外(wai),還會同(tong)時(shi)將(jiang)數(shu)據變化(hua)寫入一個環形內存結構,並(bing)以後者為依據進行(xing)Slave節點的增(zeng)量(liang)更新呢?主(zhu)要原因有以下lu)父觶/p>

由于網絡環境的不(bu)穩定,網絡抖動/延遲都可能造(zao)成Slave和Master暫(zan)時(shi)斷(duan)開連接,這種情況要遠(yuan)遠(yuan)多于新的Slave連接到Master的情況。如果以上所有情況都使用全量(liang)更新,就會大大增(zeng)加Master的負載壓力——寫RDB文件是有大量(liang)I/O過程的,雖然Linux Page Cahe特性(xing)會減少(shao)性(xing)yue)芟摹/p>

另外(wai)在數(shu)據量(liang)達(da)到一huan) gui)模的情況下,使用全量(liang)更新進行(xing)和Slave的第一次同(tong)步是一個不(bu)得已的選擇——因為要盡快減少(shao)Slave節點和Master節點的數(shu)據差異(yi)。所以只能佔用Master節點的資shi)春屯鞜kuan)資shi)礎/p>

使用內存記錄(lu)數(shu)據增(zeng)量(liang)操作,可以有xing)?跎shao)Master節點在這方面付出的I/O代價。而做成環形內存的原因,是為了保證在滿足(zu)數(shu)據記錄(lu)需求的情況下盡可能減少(shao)內存的佔用量(liang)。這個環形內存的大小,可以通過repl-backlog-size參數(shu)進行(xing)設置(zhi)。

Slave重連後會向Master發送(song)之(zhi)前(qian)接收到的Master run_id信息和上一次完成部(bu)分同(tong)步的offset的位置(zhi)信息。如果Master能夠確定這個run_id和自己的run_id一致且能夠在環形內存中找ye)秸飧ffset的位置(zhi),Master就會發送(song)從offset的位置(zhi)開始向Slave發送(song)增(zeng)量(liang)數(shu)據。那麼連接正常的各個Slave節點如何(he)接受新數(shu)據呢?連接正常的Slave節點將(jiang)會在Master節點將(jiang)數(shu)據寫入環形內存後,主(zhu)動接收到來自Master的數(shu)據復(fu)制(zhi)信息。

2-2、基本Master/Slave配置(zhi)

Redis提供的主(zhu)從復(fu)制(zhi)功(gong)能的配置(zhi)信息,在Redis主(zhu)配置(zhi)文件的“REPLICATION”部(bu)分。以下是這個部(bu)分zhi)鬧zhu)要參數(shu)項說明︰

slaveof <masterip> <masterport>︰如果您需要將(jiang)某個節點設置(zhi)為某個Master節點的Slave節點,您需要在這里指定Master節點的IP信息和tou)絲諦畔 U飧鏨柚zhi)項默認是關閉(bi)的,也即是說Master節點不(bu)需要設置(zhi)這個參數(shu)。另外(wai),除了song) 渲zhi)文件設置(zhi)外(wai),您還可以通過Redis的客戶端命(ming)令進行(xing)slaveof設定。

slave-serve-stale-data︰當master節點斷(duan)開和當前(qian)salve節點的連接或者當前(qian)slave節點正在進行(xing)和master節點的數(shu)據同(tong)步時(shi),如果收到了客戶端的數(shu)據讀(du)取請求,slave服務器是否使用陳(chen)舊數(shu)據向客戶端提供服務。該(gai)參數(shu)的默認值(zhi)為yes。

slave-read-only 是否將(jiang)salve節點設置(zhi)為“只huan)rdquo;。一旦設置(zhi)為“只huan)rdquo;,表示(shi)這個Salve節點只會進行(xing)數(shu)據讀(du)取服務,如果客戶端直接向這個Salve節點發送(song)寫數(shu)據的請求,則會收到錯(cuo)誤提示(shi)。建議(yi)采(cai)用默認xi)ldquo;yes”值(zhi)進行(xing)設定。

repl-diskless-sync︰上文已經介(jie)紹過Redis的主(zhu)從復(fu)制(zhi)功(gong)能基于RDB,後者的過程是將(jiang)數(shu)據刷入RDB文件(實際上是Linux的Page Cache區域),然後基于RDB文件內容的更新情況和Salve當前(qian)已同(tong)步的數(shu)據標(biao)記點來進行(xing)Salve上xi)氖shu)據更新。所以這個過程實際會增(zeng)加一huan) 氖shu)據延遲,消耗一huan) 拇 磣試(shi)礎;謖飧鑾榭觶edis中提供了一種不(bu)經過物理磁(ci)盤設備就進行(xing)主(zhu)從數(shu)據同(tong)步的技術,稱為diskless。但(dan)是直到Redis version 3.2這個技術也一直處于試(shi)驗狀(zhuang)態(tai),所以並(bing)不(bu)推薦在生產(chan)環境下使用︰“
WARNING: DISKLESS REPLICATION IS EXPERIMENTAL CURRENTLY”。

repl-diskless-sync-delay︰這個參數(shu)只有xing)諫弦桓霾問shu)設置(zhi)為“yes”時(shi)才起作用,主(zhu)要是設置(zhi)在進行(xing)兩(liang)次diskless模式的數(shu)據同(tong)步jiang)僮韉氖shi)間間隔。默認為5秒。

repl-ping-slave-period︰Slave節點向Master節點發送(song)ping指令的事lu)涓簦  餃0秒。

repl-timeout︰這是一個超時(shi)間,當某些操作達(da)到這個時(shi)間時(shi),Master和Slave雙方都會認為對方已經斷(duan)開連接。實際上您可以將(jiang)這個時(shi)間看成是一個租約到期的時(shi)間。那麼這個操作時(shi)間會影響哪些操作呢?A、向Slave進行(xing)的數(shu)據同(tong)步jiang)僮鞅舊shen)不(bu)能超過這個時(shi)間;B、Slave向Master發送(song)一個PING指令並(bing)等待響應的時(shi)間;C、Master向Slave發送(song)PONG回復(fu)並(bing)等待ACK的時(shi)間。

repl-disable-tcp-nodelay︰這個選項的默認值(zhi)為no,它對優化(hua)主(zhu)從復(fu)制(zhi)時(shi)使用的網絡資shi)捶淺S杏謾R 靼漬飧霾問shu)的含義(yi),就首先要解釋一下tcp-nodelay是個什麼玩意兒?TCP數(shu)據報的報文頭(tou)包含很(hen)多屬(shu)性(xing),這些屬(shu)性(xing)基本上起到記錄(lu)和保證傳輸目的、傳輸狀(zhuang)態(tai)的作用,但(dan)沒有數(shu)據報的所攜帶的業(ye)務數(shu)據(稱之(zhi)為有xing)?睪桑 D敲春hen)明顯,20個字節內容的信息分成20個數(shu)據報進行(xing)傳輸和只用一個數(shu)據報進行(xing)傳輸,需要佔用的網絡資shi)淳屯耆 bu)一樣。JohnNagle在1984年(nian)發明了一種減輕網絡傳輸壓力的算法,就是為了si)餼穌飧鑫侍猓ㄋ惴 拿志徒凶ldquo;Nagle”,後續的技術人員(yuan)又做了很(hen)多改進和升級)。其(qi)基本思路就是將(jiang)要發送(song)的內容湊夠一huan) 氖shu)量(liang)後,再用一個數(shu)據報發送(song)tong)鋈?H綣gai)屬(shu)性(xing)設置(zhi)為yes,Redis將(jiang)使用“Nagle”算法(或類(lei)似(si)算法),讓數(shu)據報中的有xing)?睪紗展灰歡(huan)ㄊshu)量(liang)後,在發送(song)tong)鋈?簧柚zhi)成no,Redis就不(bu)會這麼做。

repl-backlog-size︰上文已經介(jie)紹過了Redis中為了si)xing)增(zeng)量(liang)同(tong)步所準備的環形內存區域,以及Redis這樣做的原因額,所以這里就不(bu)再贅述(shu)了。這個選項就是用來設置(zhi)環形內存的大小的,這個選項的默認值(zhi)為1MB;正式的生產(chan)環境下可以稍微加大一些,例如5MB。

slave-priority︰當前(qian)Slave節點的優先級du)ㄖ亍N頤men)後文會介(jie)紹一款Redis自帶的監控(kong)和故障轉(zhuan)移工具(ju)︰Redis Sentinel,這個工具(ju)允許(xu)一個Master節點下有多個Slave節點,並(bing)且可以自yuan) 謝(xie)lave節點為Master節點。如果Slave節點的優先級du)ㄖ?zhi)越低,就會再切xie)皇shi)有限成為新的Master節點。

min-slaves-to-write和min-slaves-max-lag︰he) 司】贍鼙 aster節點對應的多個Slave節點在數(shu)據復(fu)制(zhi)過程中數(shu)據差異(yi)被越拉越大。Redis服務提供了一組拒絕(jue)數(shu)據寫操作的策(ce)略(lue),這個策(ce)略(lue)可以解釋為︰當Master上在min-slaves-max-lag時(shi)間(單位秒)間隔後,任然有min-slaves-to-write個Slave和它正常連接,那麼Master才允許(xu)進行(xing)數(shu)據寫操作。

2-3、Master和Slave設置(zhi)實例

討論(lun)了Redis中主(zhu)從復(fu)制(zhi)的基本原理和Redis主(zhu)配置(zhi)文件中針對主(zhu)從復(fu)制(zhi)的設定選項意義(yi)後,我們(men)來看一個實際設置(zhi)過程。注意,由于這個過程非常簡單所以我們(men)會“非常快”。首先Master服務器不(bu)需要針對主(zhu)從復(fu)制(zhi)做任何(he)的設置(zhi)(這不(bu)包括對主(zhu)從復(fu)制(zhi)過程的配置(zhi)優化(hua))。所以我們(men)就直接來看Slave節點的配置(zhi)︰

Slave節點上我們(men)只需要做一件事情,就是打開slaveof選項︰
......# slaveof選項的設置(zhi),給(gei)定master節點的ip和port就可以了# 192.168.61.140就是master節點slaveof 192.168.61.140 6379......
接著,我們(men)馬上就可以看看同(tong)步效果了。首先確保您的master節點使工作正常的,然後就可以yun)舳lave節點了︰
......5349:S 17 Dec 04:20:00.773 * Connecting to MASTER 192.168.61.140:63795349:S 17 Dec 04:20:00.773 * MASTER <-> SLAVE sync started5349:S 17 Dec 04:20:00.774 * Non blocking connect for SYNC fired the event.5349:S 17 Dec 04:20:00.775 * Master replied to PING, replication can continue...5349:S 17 Dec 04:20:00.776 * Partial resynchronization not possible (no cached master)5349:S 17 Dec 04:20:00.782 * Full resync from master: 976f0b31cbf6acd4fcc888301ea4639a7c591136:15349:S 17 Dec 04:20:00.864 * MASTER <-> SLAVE sync: receiving 119 bytes from master5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Flushing old data5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Loading DB in memory5349:S 17 Dec 04:20:00.865 * MASTER <-> SLAVE sync: Finished with success5349:S 17 Dec 04:20:01.068 * Background append only file rewriting started by pid 53525349:S 17 Dec 04:20:01.082 * AOF rewrite child asks to stop sending diffs.5352:C 17 Dec 04:20:01.082 * Parent agreed to stop sending diffs. Finalizing AOF...5352:C 17 Dec 04:20:01.082 * Concatenating 0.00 MB of AOF diff received from parent.5352:C 17 Dec 04:20:01.082 * SYNC append only file rewrite performed5352:C 17 Dec 04:20:01.082 * AOF rewrite: 6 MB of memory used by copy-on-write5349:S 17 Dec 04:20:01.168 * Background AOF rewrite terminated with success5349:S 17 Dec 04:20:01.168 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)5349:S 17 Dec 04:20:01.168 * Background AOF rewrite finished successfully......

筆者在Slave節點上開啟了定期的RDB快照和AOF日志功(gong)能,所以各位huan)琳嚦梢院雎lue)yue)切┤罩拘畔  苯庸刈ldquo;Connecting to MASTER ….”和“MASTER <-> SLAVE …….”這些日志信息就好(hao)。

以下是Master節點上給(gei)出的日志信息
......5614:M 17 Dec 04:20:00.789 * Slave 192.168.61.145:6379 asks for synchronization5614:M 17 Dec 04:20:00.789 * Full resync requested by slave 192.168.61.145:63795614:M 17 Dec 04:20:00.789 * Starting BGSAVE for SYNC with target: disk5614:M 17 Dec 04:20:00.791 * Background saving started by pid 56205620:C 17 Dec 04:20:00.814 * DB saved on disk5620:C 17 Dec 04:20:00.815 * RDB: 6 MB of memory used by copy-on-write5614:M 17 Dec 04:20:00.875 * Background saving terminated with success5614:M 17 Dec 04:20:00.877 * Synchronization with slave 192.168.61.145:6379 succeeded......

看來Master節點收到了Slave節點的連接信息,並(bing)完成了全量(liang)數(shu)據同(tong)步jiang)僮鰲/p>

2-4、關閉(bi)RDB功(gong)能的說明

以上介(jie)紹的Master節點和Slave節點的設置(zhi)是否特別簡單?是的,實際上只需要打開了Slave節點上“REPLICATION”區域的slaveof選項就可以讓Redis的主(zhu)從復(fu)制(zhi)功(gong)能運(yun)作起來。現在我們(men)往(wang)回倒,回到上一篇文章的介(jie)紹。在上一篇文章介(jie)紹RDB快照功(gong)能的配置(zhi)項時(shi),文章提到了可以用以下方式關閉(bi)RDB快照功(gong)能︰

# 以下為默認xi)納柚zhi)為,注釋掉即可# save 900 1# save 300 10# save 60 10000# 在設置(zhi)以下選項,就可以關閉(bi)RDB功(gong)能save ''

但(dan)是根據本文對Redis主(zhu)從復(fu)制(zhi)的介(jie)紹,我們(men)qiang)梢苑 strong>Redis的RDB快照功(gong)能實際上是無(wu)法真正關閉(bi)的!以上所謂(wei)關閉(bi)RDB功(gong)能的設置(zhi),只是關閉(bi)了Redis服務在正常工作時(shi)定期快照的條(tiao)件設定,但(dan)只要有Slave節點請求全量(liang)數(shu)據同(tong)步,Master節點就會強(qiang)制(zhi)做一次RDB快照。並(bing)且如果客戶端主(zhu)動發送(song)BGSAVE命(ming)令,要求Redis服務進行(xing)RDB快照時(shi),Redis也bu)岊歡(huan) 蔥xing)RDB快照操作。

但(dan)是本文還是建議(yi)在組建Redis高可用集群時(shi),關閉(bi)Master節點上xi)DB功(gong)能。讀(du)者一huan)ㄒ 宄庋齙腦 潁赫獠bu)是為了像個別網絡資料(liao)說的那樣真正關閉(bi)Redis的RDB快照功(gong)能,而是盡可能減少(shao)Master上主(zhu)動進行(xing)RDB操作的次數(shu),並(bing)將(jiang)RDB快照工作轉(zhuan)移到各個Slave節點完成。

十分11选5官网

Redis服務提供了性(xing)yue)芙細叩鬧zhu)從復(fu)制(zhi)功(gong)能,但(dan)是沒有提供原生的Master——Slave的切xie)還gong)能。也就是說如果您只是配置(zhi)了Redis的主(zhu)從復(fu)制(zhi)功(gong)能,那麼在Master節點出現故障時(shi),您必須手動將(jiang)一台Slave狀(zhuang)態(tai)的節點切xie)晃aster狀(zhuang)態(tai)。當然這個問題在Redis Version 2.8 版本前(qian)是有標(biao)準解決方案的,那就是︰Keepalived + Redis服務組成的高可用集群。

這里寫圖片描述(shu)

由Keepalived監控(kong)Redis高可用集群眾?http://www.it165.net/pro/pkqt/" target="_blank" class="keylink">QTWFzdGVyvdq147XEuaTX99e0zKyjrLKi1NrS7LOjx+m/9s/Cx9C7u8Ht0ru49r3ateO908zmuaTX96GjtavKx6Os1eK49re9sLjKx9PQ0rvQqc7KzOLBy6OsxuTW0Nau0ru+zcrHy/nT0LXEU2xhdmW92rXj1NpTdGFuZGJ517TMrMqxzt63qLfWtaNNYXN0ZXK92rXjtcTIzrrO0NTE3NG5waYmbWRhc2g7Jm1kYXNoO7y0yrnE+sno1sPBy3JlYWQtb25sebXIss7K/dKysrvQ0KOs0vLOqlZJULj5sb6yu7vhsNHH68fzx9C5/ciloaOyosfS1eLW1re9yr27ubK7zKu3vbHjvOC/2FJlZGlzuN+/ydPDvK/IutbQuPe49rf+zvG92rXjtcTKtcqx17TMrKGjPC9wPgo8cD6001ZlcnNpb24gMi44sOaxvr+qyryjrFJlZGlzzOG5qcHL0ru49tStyfq1xNb3tNPXtMysvOC/2LrNx9C7u7XE1+m8/iZtZGFzaDsmbWRhc2g7UmVkaXMgU2VudGluZWyho82ouf3L/Ly8yvXIy9Sxsru1q7/J0tTN6rPJUmVkaXO437/J08O8r8i6tcTKysqxvOC/2KOsu7m/ydLUzai5/bHgs8zK1rbOvPXH4byvyLrW0E1hc3Rlcr3atePW0LbBstnX97XE0bnBpqGjsb692sTayN2jrM7Sw8fP8rbB1d+96cnc1eK49lJlZGlzIFNlbnRpbmVstcS88rWlyrnTw6GjPC9wPgo8aDQgaWQ9"3-1基本配置(zhi)">3-1、基本配置(zhi)

由于Redis Sentinel是Redis原生支持(chi)的,以Redis Version 3.2為例,在下lue)匕滄zhuang)後就可以直接使用命(ming)令“redis-sentinel”啟動Sentinel了。Sentinel的主(zhu)配置(zhi)文件模板存放在Redis安裝(zhuang)目錄(lu)的下,默認名為“sentinel.conf”。以下命(ming)令可以yun)舳entinel(啟動Sentinel所依據的配置(zhi)文件是一huan)ㄒ  牟問shu))︰

# redis-sentinel ./sentinel.conf

Redis Sentinel本身(shen)也支持(chi)集群部(bu)署,而且為了在生產(chan)環境下避免Sentinel單點故障,所以也建議(yi)同(tong)時(shi)部(bu)署多個Sentinel節點。部(bu)署多個Sentinel還有一個原因,就是提高Master——Slave切xie)壞淖既沸xing)。以下的配置(zhi)文件介(jie)紹會說明這一點。

下面我們(men)介(jie)紹一些Sentinel主(zhu)配置(zhi)文件中的關鍵配置(zhi),注意Sentinel主(zhu)配置(zhi)文件也有類(lei)似(si)Redis主(zhu)配置(zhi)文件提供的訪問shi);?J劍rotected-mode)、訪問者權限控(kong)制(zhi)(auth-pass)等,但(dan)是它們(men)的意義(yi)基本上類(lei)似(si)前(qian)文介(jie)紹過的,在Redis主(zhu)配置(zhi)文件中的相似(si)內容,所以這里就不(bu)再贅述(shu)了。

sentinel monitor <master-name> <ip> <redis-port> <quorum>︰

這個屬(shu)性(xing)是Redis Sentinel中的最主(zhu)要設置(zhi)元素,換句話說如果要開啟Sentinel甚至liang)梢災簧柚zhi)這個屬(shu)性(xing)。它包括了四個參數(shu)︰master-name,這個參數(shu)是一個英文名說明了Sentinel服務監听的Master節點的別名,如果一個Sentinel服務需要同(tong)時(shi)監控(kong)多個Master,這需要設置(zhi)多個不(bu)同(tong)的master-name;ip和redis-port,指向sentinel需要監控(kong)的Redis集群最初的那個Master節點(為什麼會是最初呢?後文會說明)的ip和tou)絲冢uorum,投(tou)票數(shu)量(liang)這個參數(shu)很(hen)重要,如果是Sentinel集群方式下,它設定“當quorum個Sentinel認為Master異(yi)常了,就判定該(gai)Master真的異(yi)常了”。單個Sentinel節點認為Master下線了被稱為主(zhu)管下線,而quorum個Sentinel節點都認為Master下線的情況被稱為客觀下線。

sentinel parallel-syncs <master-name> <numslaves>︰

一旦原來的Master節點被認為客觀下線了,Sentinel就會啟動切xie)還獺4籩呂唇jiang)就是從當前(qian)所有Slave節點選擇一個節點成為新的Master節點(這時(shi)在Redis中設定的slave-priority參數(shu)就會起作用了)。而其(qi)它的Slave其(qi)slaveof的Master信息將(jiang)被sentinel切xie)壞叫碌aster上。而一次同(tong)時(shi)並(bing)行(xing)切xie)歡(huan)嗌shao)個Slave到新的Master上就是這個參數(shu)決定的。如果整個Redis高可用集群的節點數(shu)量(liang)不(bu)多(沒有超過6個),建議(yi)使用默認值(zhi)就可以了。

主(zhu)配置(zhi)文件中被rewrite的參數(shu)內容︰sentinel.conf文件中的配置(zhi)內容會隨著Sentinel的監控(kong)情況發生變化(hua)——由Sentinel程序(xu)動態(tai)寫入到文件中。例如sentinel known-slave參數(shu)、sentinel current-epoch參數(shu)和sentinel leader-epoch參數(shu)。

注意,在Sentinel中您只需要配置(zhi)最初的Master的監控(kong)位置(zhi),無(wu)需配置(zhi)Master下任何(he)Slave的位置(zhi),Sentinel會自己識(shi)別到這些Master直接的或者間接的Slave。

節點作用192.168.61.140Redis Master192.168.61.145Redis Slave192.168.61.140Redis Sentinel

這里就不(bu)再贅述(shu)Redis Master和Redis Slave的內容了,因為在本文第2節中已經詳細介(jie)紹過。實際上您只需要打開Slave節點的主(zhu)配置(zhi)文件,並(bing)增(zeng)加slaveof的配置(zhi)信息,將(jiang)其(qi)指向Master的IP和tou)絲誥涂梢粵恕R韻率entinel節點主(zhu)要更改的配置(zhi)信息︰

......sentinel monitor mymaster 192.168.61.140 6379 1......

由于在測試(shi)環境chi)形頤men)只使用了一個Sentinel節點,所以設置(zhi)sentinel monitor配置(zhi)項中的quorum為1就可以了,代表有一個Sentinel節點認為Master不(bu)可用了,就開啟故障轉(zhuan)移過程。當然生產(chan)環境下不(bu)建議(yi)這樣使用。

之(zhi)後我們(men)使用以下Sentinel的主(zhu)要配置(zhi)信息啟動Sentinel︰

# redis-sentinel ./sentinel.conf......8576:X 19 Dec 00:49:01.085 # Sentinel ID is 5a5eb7b97de060e7ad5f6aa20475a40b3d9fd3e18576:X 19 Dec 00:49:01.085 # +monitor master mymaster 192.168.61.140 6379 quorum 1......

之(zhi)後主(zhu)動終(zhong)止原來Master的運(yun)行(xing)過程(您可以直接使用kill命(ming)令,或者拔掉網線,又索性(xing)直接關機),來觀察Slave節點和Sentinel節點的日志情況︰

當斷(duan)開原來的Master節點後,Slave節點將(jiang)提示(shi)連接失(shi)效並(bing)開始重試(shi)。當Sentinel開始進入故障轉(zhuan)移並(bing)完成後,Salve又會打印相應的過程信息︰

......8177:S 19 Dec 00:53:17.467 * Connecting to MASTER 192.168.61.140:63798177:S 19 Dec 00:53:17.468 * MASTER <-> SLAVE sync started8177:S 19 Dec 00:53:17.468 # Error condition on socket for SYNC: Connection refused......8177:M 19 Dec 00:53:18.134 * Discarding previously cached master state.8177:M 19 Dec 00:53:18.134 * MASTER MODE enabled (user request from 'id=3 addr=192.168.61.140:51827 fd=5 name=sentinel-5a5eb7b9-cmd age=258 idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 oll=0 omem=0 events=r cmd=exec')8177:M 19 Dec 00:53:18.138 # CONFIG REWRITE executed with success.......

從以上Slave節點的內容可以看到,Slave被切xie)懷閃aster狀(zhuang)態(tai)。那麼Sentinel本身(shen)有哪些重要的日志信息呢?如下所示(shi)︰

......// 當前(qian)Sentinel節點確定原Master主(zhu)觀下線8576:X 19 Dec 00:53:18.074 # +sdown master mymaster 192.168.61.140 6379// 由于設置(zhi)的quorum為1,所以一個Sentinel節點的主(zhu)管下線就認為Master客觀下線了8576:X 19 Dec 00:53:18.074 # +odown master mymaster 192.168.61.140 6379 #quorum 1/1// 第三代,每轉(zhuan)移一次故障epoch的值(zhi)+1,// 不(bu)好(hao)意思,在書寫測試(shi)實例前(qian),本人已經自行(xing)測試(shi)了兩(liang)次故障轉(zhuan)移,所以這里看到的epoch為3// 這個信息會自yuan) 慈氳entinel節點的主(zhu)配置(zhi)文件中8576:X 19 Dec 00:53:18.074 # +new-epoch 3// 開始進行(xing)故障轉(zhuan)移8576:X 19 Dec 00:53:18.074 # +try-failover master mymaster 192.168.61.140 6379// 選舉出主(zhu)導故障轉(zhuan)移的Sentinel節點,因為不(bu)是所有Sentinel節點都會主(zhu)導這個過程8576:X 19 Dec 00:53:18.084 # +vote-for-leader 5a5eb7b97de060e7ad5f6aa20475a40b3d9fd3e1 38576:X 19 Dec 00:53:18.084 # +elected-leader master mymaster 192.168.61.140 63798576:X 19 Dec 00:53:18.084 # +failover-state-select-slave master mymaster 192.168.61.140 6379// 選擇提升哪一個slave作為新的master8576:X 19 Dec 00:53:18.156 # +selected-slave slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 63798576:X 19 Dec 00:53:18.156 * +failover-state-send-slaveof-noone slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 63798576:X 19 Dec 00:53:18.211 * +failover-state-wait-promotion slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 6379// 提升原來的slave8576:X 19 Dec 00:53:19.201 # +promoted-slave slave 192.168.61.145:6379 192.168.61.145 6379 @ mymaster 192.168.61.140 6379// 試(shi)圖重寫所有salves節點的配置(zhi)信息,並(bing)讓它們(men)指向新的master8576:X 19 Dec 00:53:19.201 # +failover-state-reconf-slaves master mymaster 192.168.61.140 6379// 故障轉(zhuan)移ping) 576:X 19 Dec 00:53:19.250 # +failover-end master mymaster 192.168.61.140 6379// 最終(zhong)完成master節點的切xie)576:X 19 Dec 00:53:19.250 # +switch-master mymaster 192.168.61.140 6379 192.168.61.145 6379// 注意原有的master節點會再顯示(shi)一條(tiao)作為主(zhu)觀下線,但(dan)是這次下線信息是以salve身(shen)份(fen)通知的// 這是因為這次故障切xie)緩螅  吹aster就算再上線,也只會作為Slave節點了8576:X 19 Dec 00:53:19.251 * +slave slave 192.168.61.140:6379 192.168.61.140 6379 @ mymaster 192.168.61.145 63798576:X 19 Dec 00:53:49.305 # +sdown slave 192.168.61.140:6379 192.168.61.140 6379 @ mymaster 192.168.61.145 6379......

通過Slave節點和Sentinel節點的日志可以看到,在經過了短(duan)暫(zan)的時(shi)間後Sentinel成功(gong)將(jiang)唯一一個Slave節點轉(zhuan)換成了Master節點,並(bing)繼(ji)續向外(wai)部(bu)提供服務。

之(zhi)後我們(men)重新啟動原有Master節點,看看會發生什麼︰

# 以下是原有Master啟動後,在Sentinel顯示(shi)的信息......8576:X 19 Dec 01:31:12.743 * +reboot slave 192.168.61.140:6379 192.168.61.140 6379 @ mymaster 192.168.61.145 63798576:X 19 Dec 01:31:12.805 # -sdown slave 192.168.61.140:6379 192.168.61.140 6379 @ mymaster 192.168.61.145 6379......

一個非常重要的現象是,當原來的Master節點再次啟動時(shi),即使配置(zhi)文件中沒有設定slaveof信息,它也bu)嵩entinel的協調下稱為Slave節點。這是因為任何(he)一次Master到Slave的切xie)歡(huan)際且 凍齟鄣模 qi)中除了狀(zhuang)態(tai)本身(shen)的判斷(duan)外(wai),還有Sentinel自身(shen)協調和選舉過程(選舉哪一個Sentinel進行(xing)實質的切xie)歡(huan) 鰨  褂行(xing)碌aster的選定問題,甚至包括Slave的slaveof目標(biao)變化(hua)過程中xing)枰  淼氖shu)據一致性(xing)問題等等工作。所以最好(hao)的辦法就是︰只要能夠保證Redis高可用集群持(chi)續工作,就不(bu)進行(xing)Master狀(zhuang)態(tai)的切xie)/strong>。

3-3、Java客戶端配合(he)Sentinel的使用

通過Sentinel組建的高可用集群對yuan)韌 諶餃砑榻 母嚦捎眉 憾裕 釁qi)明顯的優點。例如可以實時(shi)返(fan)回集群中每個Redis節點的狀(zhuang)態(tai),且各節點間更能保持(chi)最佳的數(shu)據一致性(xing),另外(wai)還可以在必要的時(shi)候通過轉(zhuan)移客戶端讀(du)操作,減輕Master節點的工作壓力。但(dan)是它也有一個很(hen)明顯的缺點,就是由于整個集群可以向調用者開放多個Redis節點的地(di)址,且Sentinel本身(shen)並(bing)不(bu)能充當路由器的作用,所以當Redis高可用集群hang)xing)狀(zhuang)態(tai)切xie)皇shi),客戶端可能並(bing)不(bu)清楚原有的Master節點已經失(shi)效了。如下圖所示(shi)︰

這里寫圖片描述(shu)

還好(hao)的是,Java最常用的Redis客戶端jedis提供了一組針對Sentinel的集群工具(ju),讓客戶端可以在獲(huo)取當前(qian)Redis高可用集群中的Master節點後,再在這個Master節點上完成數(shu)據讀(du)寫操作。但(dan)另外(wai)一個讀(du)操作的負載問題還是沒有被解決,所有的讀(du)操作也只會在Master節點完成。

這里寫圖片描述(shu)

我們(men)來看看一些關鍵代碼︰

......// 這是基本的連接配置(zhi)// 當讓這些屬(shu)性(xing)都可以根據您的實際情況進行(xing)更改JedisPoolConfig poolConfig = new JedisPoolConfig();poolConfig.setMaxTotal(100); poolConfig.setMaxIdle(50); poolConfig.setMinIdle(20); poolConfig.setMaxWaitMillis(6 * 1000); poolConfig.setTestOnBorrow(true);// 以下是qiang)捎玫畝喔entinel節點的ip和tou)絲et<String> jedisClusterNodes = new HashSet<String>();jedisClusterNodes.add('192.168.61.140:26379');//如果有多個Sentinel一個一個添加進去//jedisClusterNodes.add('192.168.61.139:26379');JedisSentinelPool jedisSentinelPool = new JedisSentinelPool('mymaster', jedisClusterNodes , poolConfig);// 開始插(cha)入信息for(Integer index = 0 ; index < 10000 ; index++) { // 獲(huo)取最新的master信息 Jedis master = null; try { master = jedisSentinelPool.getResource(); } catch(JedisConnectionException e) { // 如果出現異(yi)常,說明當前(qian)的maser斷(duan)開了連接,那麼等待一huan)問shi)間後重試(shi) LOGGER.info('master is loss , waiting for try again......'); synchronized (MasterSlaveApp.class) {  MasterSlaveApp.class.wait(5000); } index--; continue; } // 開始正式jiang)迦master.set(('key' + index).getBytes(), index.toString().getBytes()); LOGGER.info('write ︰ ' + 'key' + index); synchronized (MasterSlaveApp.class) { // 停止0.5秒,以yuan)愎鄄煜窒MasterSlaveApp.class.wait(500); }}jedisSentinelPool.close();......

在示(shi)例代碼中Sentinel節點只有一個,存在于192.168.61.140:26379上。如果是生產(chan)環境建議(yi)不(bu)要對Sentinel進行(xing)單點部(bu)署,否則一旦Sentinel單點崩潰會造(zao)成整個Redis高可用集群在客戶端無(wu)法進行(xing)Master節點的切xie)弧T誄跏冀錐92.168.61.140:6379是master節點,然後我們(men)在程序(xu)執行(xing)過程中將(jiang)原有的master節點關閉(bi),這時(shi)上面的客戶端代碼片段可能的輸出以下日志信息(部(bu)分)︰

......14639 [main] INFO redis_test.test.MasterSlaveApp - write ︰ key2916144 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......22148 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......28151 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......34155 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......40159 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......十二月 20, 2016 4:12:22 下午 redis.clients.jedis.JedisSentinelPool initPool信息: Created JedisPool to master at 192.168.61.145:637946163 [main] INFO redis_test.test.MasterSlaveApp - master is loss , waiting for try again......51166 [main] INFO redis_test.test.MasterSlaveApp - write ︰ key3051670 [main] INFO redis_test.test.MasterSlaveApp - write ︰ key31......

==================================
後文內容預(yu)告(gao)︰
4、Redis負載均衡方案
4-1、Twitter Twemproxy
4-2、Twemproxy存在的問題
5、Redis 3.X Cluster
5-1、Redis Cluster 簡介(jie)
5-2、Redis Cluster 搭建實例
5-3、Client連接到Redis Cluster

==========各位huan)琳叨暈惱侶嘸 綣兄室桑 huan)迎在評論(lun)區留言。感xing)話鎦zhu)我指出錯(cuo)誤的讀(du)者。

Tag標(biao)簽(qian)︰集群  架(jia)構  方案  
  • 十分11选5官网

About IT165 - 廣告(gao)服務 - 隱私(si)聲明 - 版權申明 - 免責(ze)條(tiao)款 - 網站(zhan)地(di)圖 - 網友投(tou)稿 - 聯系(xi)方式
本站(zhan)內容來自于互聯網,僅供用于網絡技術學習,學習中請遵循(xun)相關法律法規(gui)
十分11选5官网 | 下一页