這篇文章主要介紹“redis分布式緩存的作用是什么”，在日常操作中，相信很多人在Redis分布式緩存的作用是什么問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Redis分布式緩存的作用是什么”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

創(chuàng)新互聯(lián)成立以來不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術(shù)為基點(diǎn)，以客戶需求中心、市場(chǎng)為導(dǎo)向”的快速反應(yīng)體系。對(duì)公司的主營(yíng)項(xiàng)目，如中高端企業(yè)網(wǎng)站企劃 / 設(shè)計(jì)、行業(yè) / 企業(yè)門戶設(shè)計(jì)推廣、行業(yè)門戶平臺(tái)運(yùn)營(yíng)、app軟件開發(fā)、成都手機(jī)網(wǎng)站制作、微信網(wǎng)站制作、軟件開發(fā)、達(dá)州服務(wù)器托管等實(shí)行標(biāo)準(zhǔn)化操作，讓客戶可以直觀的預(yù)知到從創(chuàng)新互聯(lián)可以獲得的服務(wù)效果。

Redis哨兵（Sentinel）模式

主從切換技術(shù)的方法是：當(dāng)主服務(wù)器宕機(jī)后，需要手動(dòng)把一臺(tái)從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費(fèi)事費(fèi)力，還會(huì)造成一段時(shí)間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時(shí)候，我們優(yōu)先考慮哨兵模式。

一、哨兵模式概述

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個(gè)獨(dú)立的進(jìn)程，作為進(jìn)程，它會(huì)獨(dú)立運(yùn)行。其原理是哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運(yùn)行的多個(gè)Redis實(shí)例。

這里的哨兵有兩個(gè)作用

• 通過發(fā)送命令，讓Redis服務(wù)器返回監(jiān)控其運(yùn)行狀態(tài)，包括主服務(wù)器和從服務(wù)器。

• 當(dāng)哨兵監(jiān)測(cè)到master宕機(jī)，會(huì)自動(dòng)將slave切換成master，然后通過發(fā)布訂閱模式通知其他的從服務(wù)器，修改配置文件，讓它們切換主機(jī)。

然而一個(gè)哨兵進(jìn)程對(duì)Redis服務(wù)器進(jìn)行監(jiān)控，可能會(huì)出現(xiàn)問題，為此，我們可以使用多個(gè)哨兵進(jìn)行監(jiān)控。各個(gè)哨兵之間還會(huì)進(jìn)行監(jiān)控，這樣就形成了多哨兵模式。

用文字描述一下故障切換（failover）的過程。假設(shè)主服務(wù)器宕機(jī)，哨兵1先檢測(cè)到這個(gè)結(jié)果，系統(tǒng)并不會(huì)馬上進(jìn)行failover過程，僅僅是哨兵1主觀的認(rèn)為主服務(wù)器不可用，這個(gè)現(xiàn)象成為主觀下線。當(dāng)后面的哨兵也檢測(cè)到主服務(wù)器不可用，并且數(shù)量達(dá)到一定值時(shí)，那么哨兵之間就會(huì)進(jìn)行一次投票，投票的結(jié)果由一個(gè)哨兵發(fā)起，進(jìn)行failover操作。切換成功后，就會(huì)通過發(fā)布訂閱模式，讓各個(gè)哨兵把自己監(jiān)控的從服務(wù)器實(shí)現(xiàn)切換主機(jī)，這個(gè)過程稱為客觀下線。這樣對(duì)于客戶端而言，一切都是透明的。

二、Redis配置哨兵模式

三、哨兵模式的其他配置項(xiàng)

sentinel down-after-milliseconds配置項(xiàng)只是一個(gè)哨兵在超過規(guī)定時(shí)間依舊沒有得到響應(yīng)后，會(huì)自己認(rèn)為主機(jī)不可用。對(duì)于其他哨兵而言，并不是這樣認(rèn)為。哨兵會(huì)記錄這個(gè)消息，當(dāng)擁有認(rèn)為主觀下線的哨兵達(dá)到sentinel monitor所配置的數(shù)量時(shí)，就會(huì)發(fā)起一次投票，進(jìn)行failover，此時(shí)哨兵會(huì)重寫Redis的哨兵配置文件，以適應(yīng)新場(chǎng)景的需要。

Redis集群原理

1.1.Redis-cluster架構(gòu)圖

1、所有的redis節(jié)點(diǎn)彼此互聯(lián)(PING-PONG機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

2、節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效。

3、客戶端與redis節(jié)點(diǎn)直連,不需要中間proxy層?？蛻舳瞬恍枰B接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

4、redis-cluster把所有的物理節(jié)點(diǎn)映射到[0-16383]slot上,cluster 負(fù)責(zé)維護(hù)node<->slot<->value Redis 集群中內(nèi)置了 16384 個(gè)哈希槽，當(dāng)需要在 Redis 集群中放置一個(gè) key-value 時(shí)，redis 先對(duì) key 使用 crc16 算法算出一個(gè)結(jié)果，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0-16383 之間的哈希槽，redis 會(huì)根據(jù)節(jié)點(diǎn)數(shù)量大致均等的將哈希槽映射到不同的節(jié)點(diǎn)。一個(gè)節(jié)點(diǎn)對(duì)應(yīng)一臺(tái)redis服務(wù)器。16384個(gè)哈希槽最大可以對(duì)應(yīng)16384臺(tái)redis服務(wù)器。

1.2.Redis-cluster投票&容錯(cuò)

投票過程是集群中所有master參與,如果半數(shù)以上master節(jié)點(diǎn)與master節(jié)點(diǎn)通信超時(shí)(cluster-node-timeout),認(rèn)為當(dāng)前master節(jié)點(diǎn)掛掉。

什么時(shí)候整個(gè)集群不可用(cluster_state:fail)?

A：如果集群任意master掛掉,且當(dāng)前master沒有slave.集群進(jìn)入fail狀態(tài),也可以理解成集群的slot映射[0-16383]不完整時(shí)進(jìn)入fail狀態(tài). ps : redis-3.0.0.rc1加入cluster-require-full-coverage參數(shù),默認(rèn)關(guān)閉,打開集群兼容部分失敗。

B：如果集群超過半數(shù)以上master掛掉，無論是否有slave，集群進(jìn)入fail狀態(tài)。

到此，關(guān)于“Redis分布式緩存的作用是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！