Redis集群有哪些功能

本篇內(nèi)容介紹了“Redis集群有哪些功能”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

　　什么是Redis集群

　　Redis集群是一個實(shí)現(xiàn)分布式并且允許單點(diǎn)故障的Redis高級版本。

　　Redis集群沒有最重要或者說中心節(jié)點(diǎn)，這個版本最主要的一個目標(biāo)是設(shè)計一個線性可伸縮(可隨意增刪節(jié)點(diǎn)?)的功能。

　　Redis集群為了數(shù)據(jù)的一致性可能犧牲部分允許單點(diǎn)故障的功能，所以當(dāng)網(wǎng)絡(luò)故障和節(jié)點(diǎn)發(fā)生故障時這個系統(tǒng)會盡力去保證數(shù)據(jù)的一致性和有效性。(這里我們認(rèn)為節(jié)點(diǎn)故障是網(wǎng)絡(luò)故障的一種特殊情況)

　　為了解決單點(diǎn)故障的問題，我們同時需要masters 和 slaves。 即使主節(jié)點(diǎn)(master)和從節(jié)點(diǎn)(slave)在功能上是一致的，甚至說他們部署在同一臺服務(wù)器上，從節(jié)點(diǎn)也僅用以替代故障的主節(jié)點(diǎn)。 實(shí)際上應(yīng)該說 如果對從節(jié)點(diǎn)沒有read-after-write(寫并立即讀取數(shù)據(jù) 以免在數(shù)據(jù)同步過程中無法獲取數(shù)據(jù))的需求，那么從節(jié)點(diǎn)僅接受只讀操作。

　　已實(shí)現(xiàn)子集

　　Redis集群會把所有的單一key存儲在非分布式版本的Redis中。對于復(fù)合操作比如求并集求交集之類則未實(shí)現(xiàn)。

　　在將來，有可能會增加一種為“Computation Node”的新類型節(jié)點(diǎn)。這種節(jié)點(diǎn)主要用來處理在集群中multi-key的只讀操作，但是對于multi-key的只讀操作不會以集群傳輸?shù)紺omputation Node節(jié)點(diǎn)再進(jìn)行計算的方式實(shí)現(xiàn)。

　　Redis集群版本將不再像獨(dú)立版本一樣支持多數(shù)據(jù)庫，在集群版本中只有database 0，并且SELECT命令是不可用的。

　　客戶端與服務(wù)端在Redis集群版中的約定

　　在Redis集群版本中，節(jié)點(diǎn)有責(zé)任/義務(wù)保存數(shù)據(jù)和自身狀態(tài)，這其中包括把數(shù)據(jù)(key)映射到正確的節(jié)點(diǎn)。所有節(jié)點(diǎn)都應(yīng)該自動探測集群中的其他節(jié)點(diǎn)，并且在發(fā)現(xiàn)故障節(jié)點(diǎn)之后把故障節(jié)點(diǎn)的從節(jié)點(diǎn)更改為主節(jié)點(diǎn)(原文這里有“如果有需要” 可能是指需要設(shè)置或者說存在從節(jié)點(diǎn))。

　　集群節(jié)點(diǎn)使用TCP bus和二進(jìn)制協(xié)議進(jìn)行互聯(lián)并對任務(wù)進(jìn)行分派。各節(jié)點(diǎn)使用gossip 協(xié)議發(fā)送ping packets給集群其他節(jié)點(diǎn)以確定其他節(jié)點(diǎn)是否正常工作。cluster bus也可以用來在節(jié)點(diǎn)間執(zhí)行PUB/SUB命令。

　　當(dāng)發(fā)現(xiàn)集群節(jié)點(diǎn)無應(yīng)答的時候則會使用redirections errors -MOVED and -ASK命令并且會重定向至可用節(jié)點(diǎn)。理論上客戶端可隨意向集群中任意節(jié)點(diǎn)發(fā)送請求并獲得重定向，也就是說客戶端實(shí)際上并不用關(guān)心集群的狀態(tài)。然而，客戶端也可以緩存數(shù)據(jù)對應(yīng)的節(jié)點(diǎn)這樣可以免去服務(wù)端進(jìn)行重定向的工作，這在一定程度上可以提高效率。

　　Redis集群有哪些功能

　　Keys分配模式

　　一個集群可以包含最多4096個節(jié)點(diǎn)(但是我們建議最多設(shè)置幾百個節(jié)點(diǎn))。

　　所有的主節(jié)點(diǎn)會控制4096個key空間的百分比。當(dāng)集群穩(wěn)定之后，也就是說不會再更改集群配置(更改配置指的增刪節(jié)點(diǎn))，那么一個節(jié)點(diǎn)將只為一個hash slot服務(wù)。(但是服務(wù)節(jié)點(diǎn)(主節(jié)點(diǎn))可以擁有多個從節(jié)點(diǎn)用來防止單點(diǎn)故障)

　　用來計算key屬于哪個hash slot的算法如下：

　　HASH_SLOT = CRC16(key) mod 4096

　　Name: XMODEM (also known as ZMODEM or CRC-16/ACORN)

　　Width: 16 bit

　　Poly: 1021 (That is actually x^16 + x^12 + x^5 + 1)

　　Initialization: 0000

　　Reflect Input byte: False

　　Reflect Output CRC: False

　　Xor constant to output CRC: 0000

　　Output for "123456789": 31C3

　　這里我們會取CRC16后的12個字節(jié)。在我們的測試中，對于4096個slots， CRC16算法最合適。

　　集群節(jié)點(diǎn)特性

　　在集群中每個節(jié)點(diǎn)都擁有唯一的名字。節(jié)點(diǎn)名為16進(jìn)制的160 bit隨機(jī)數(shù)，當(dāng)節(jié)點(diǎn)獲取到名字后將被立即啟用。節(jié)點(diǎn)名將被永久保存到節(jié)點(diǎn)設(shè)置文件中，除非系統(tǒng)管理員手動刪除節(jié)點(diǎn)配置文件。

　　節(jié)點(diǎn)名是集群中每個節(jié)點(diǎn)的身份證明。在不更改節(jié)點(diǎn)ID的情況下是允許修改節(jié)點(diǎn)IP和地址的。cluster bus會自動通過gossip協(xié)議獲取更改后的節(jié)點(diǎn)設(shè)置。

　　每個節(jié)點(diǎn)可獲知其他節(jié)點(diǎn)的信息包括：IP 端口、狀態(tài)、管理的hash slots、cluster bus最后發(fā)送PING的時間、最后接收到PONG的時間、從節(jié)點(diǎn)數(shù)量、節(jié)點(diǎn)ID。

　　無論是主節(jié)點(diǎn)還是從節(jié)點(diǎn)都可以通過CLUSTER NODES命令來獲取以上信息

　　示例如下：

　　$ redis-cli cluster nodes

　　d1861060fe6a534d42d8a19aeb36600e18785e04 :0 myself - 0 1318428930 connected 0-1364

　　3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1:6380 master - 1318428930 1318428931 connected 1365-2729

　　d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1:6381 master - 1318428931 1318428931 connected 2730-4095

　　節(jié)點(diǎn)交互

　　所有節(jié)點(diǎn)總是允許接受來自cluster bus的連接請求，并且即使請求PING的節(jié)點(diǎn)是不可信的也會進(jìn)行應(yīng)答。然而，所有來自非集群節(jié)點(diǎn)的packets都會被忽略。

　　只有以下兩種情況節(jié)點(diǎn)才會把其他節(jié)點(diǎn)認(rèn)為是集群的一部分：

　　如果一個節(jié)點(diǎn)使用 MEET message 介紹自己。MEET message 命令是強(qiáng)制其他節(jié)點(diǎn)把自己當(dāng)成是集群的一部分。只有系統(tǒng)管理員使用 CLUSTER MEET ip port 命令節(jié)點(diǎn)才會發(fā)送MEET message給其他節(jié)點(diǎn)。

　　另外一種方式就是通過集群節(jié)點(diǎn)間的推薦機(jī)制。例如 如果A節(jié)點(diǎn)知道B節(jié)點(diǎn)屬于集群，而B知道C節(jié)點(diǎn)屬于集群，那么B將會發(fā)送gossip信息告知A：C是屬于集群的。當(dāng)A獲得gossip信息之后就會嘗試去連接C。

　　這意味著，當(dāng)我們以任意連接方式為集群加入一個節(jié)點(diǎn)，集群中所有節(jié)點(diǎn)都會自動對新節(jié)點(diǎn)建立信任連接。也就是說，集群具備自動識別所有節(jié)點(diǎn)的功能，但是這僅發(fā)生在當(dāng)系統(tǒng)管理強(qiáng)制為新節(jié)點(diǎn)與集群中任意節(jié)點(diǎn)建立信任連接的前提下。

　　這個機(jī)制使得集群系統(tǒng)更加健壯。

　　當(dāng)一個節(jié)點(diǎn)故障時，其余節(jié)點(diǎn)會嘗試連接其他所有已知的節(jié)點(diǎn)已確定其他節(jié)點(diǎn)的健壯性。

　　被移動數(shù)據(jù)的重定向

　　Redis客戶端被允許向集群中的任意節(jié)點(diǎn)發(fā)送命令，其中包括從節(jié)點(diǎn)。被訪問的節(jié)點(diǎn)將會分析命令中所需要的數(shù)據(jù)(這里僅指請求單個key)，并自己通過判斷hash slot確定數(shù)據(jù)存儲于哪個節(jié)點(diǎn)。

　　如果被請求節(jié)點(diǎn)擁有hash slot數(shù)據(jù)(這里指請求數(shù)據(jù)未被遷移過 或者 hash slot在數(shù)據(jù)遷移后被重新計算過)，則會直接返回結(jié)果，否則將會返回一個 MOVED 錯誤。

　　MOVED 錯誤如下：

　　GET x

　　-MOVED 3999 127.0.0.1:6381

　　這個錯誤包括請求的數(shù)據(jù)所處的 hash slot(3999) 和 數(shù)據(jù)目前所屬的IP:端口?？蛻舳诵枰ㄟ^訪問返回的IP:端口獲取數(shù)據(jù)。即使在客戶端請求并等待數(shù)據(jù)返回的過程中，集群配置已被更改(也就是說請求的key在配置文件中所屬的節(jié)點(diǎn)ID已被重定向至新的IP:端口)，目標(biāo)節(jié)點(diǎn)依然會返回一個MOVED錯誤。

　　所以雖然在集群中的節(jié)點(diǎn)使用節(jié)點(diǎn)ID來確定身份，但是map依然是靠hash slot和Redis節(jié)點(diǎn)的IP:端口來進(jìn)行配對。

　　客戶端雖然不被要求但是應(yīng)該嘗試去記住hash slot 3999現(xiàn)在已被轉(zhuǎn)移至127.0.0.1:6381。這樣的話，當(dāng)一個新的命令需要從hash slot 3999獲取數(shù)據(jù)時就可以有更高的幾率從hash slot獲取到正確的目標(biāo)節(jié)點(diǎn)。

　　假設(shè)集群已經(jīng)足夠的穩(wěn)定(不增刪節(jié)點(diǎn))，那么所有的客戶端將會擁有一份hash slots對應(yīng)節(jié)點(diǎn)的數(shù)據(jù)，這可以使整個集群更高效，因?yàn)檫@樣每個命令都會直接定向到正確的節(jié)點(diǎn)，不需要通過節(jié)點(diǎn)尋找節(jié)點(diǎn)或者重新計算hash slot對應(yīng)的節(jié)點(diǎn)。

　　集群不下線更新配置

　　Redis集群支持線上增刪節(jié)點(diǎn)。實(shí)際上對于系統(tǒng)來說，增加和刪除節(jié)點(diǎn)在本質(zhì)上是一樣的，因?yàn)樗麄兌际前裩ash slot從一個節(jié)點(diǎn)遷移至另外一個節(jié)點(diǎn)而已。

　　增加節(jié)點(diǎn)：集群中加入一個空節(jié)點(diǎn)并且把hash slot從已存在的節(jié)點(diǎn)們移至新節(jié)點(diǎn)。

　　刪除節(jié)點(diǎn)：集群刪除一個已存在節(jié)點(diǎn)并且把hash slot分散到已存在的其他節(jié)點(diǎn)中。

　　所以實(shí)現(xiàn)這個功能的核心就是遷移slots。實(shí)際上從某種觀點(diǎn)上來說，hash slot只不過是一堆key的合集，所以Redis集群要做的事情只是在重分片的時候把一堆key從一個實(shí)例移動到另外一個實(shí)例。

“Redis集群有哪些功能”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！