Redis集群有哪些功能

本篇內容介紹了“Redis集群有哪些功能”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

　　什么是Redis集群

　　Redis集群是一個實現分布式并且允許單點故障的Redis高級版本。

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

　　Redis集群為了數據的一致性可能犧牲部分允許單點故障的功能，所以當網絡故障和節點發生故障時這個系統會盡力去保證數據的一致性和有效性。(這里我們認為節點故障是網絡故障的一種特殊情況)

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

　　已實現子集

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

　　在將來，有可能會增加一種為“Computation Node”的新類型節點。這種節點主要用來處理在集群中multi-key的只讀操作，但是對于multi-key的只讀操作不會以集群傳輸到Computation Node節點再進行計算的方式實現。

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

　　客戶端與服務端在Redis集群版中的約定

　　在Redis集群版本中，節點有責任/義務保存數據和自身狀態，這其中包括把數據(key)映射到正確的節點。所有節點都應該自動探測集群中的其他節點，并且在發現故障節點之后把故障節點的從節點更改為主節點(原文這里有“如果有需要” 可能是指需要設置或者說存在從節點)。

　　集群節點使用TCP bus和二進制協議進行互聯并對任務進行分派。各節點使用gossip 協議發送ping packets給集群其他節點以確定其他節點是否正常工作。cluster bus也可以用來在節點間執行PUB/SUB命令。

　　當發現集群節點無應答的時候則會使用redirections errors -MOVED and -ASK命令并且會重定向至可用節點。理論上客戶端可隨意向集群中任意節點發送請求并獲得重定向，也就是說客戶端實際上并不用關心集群的狀態。然而，客戶端也可以緩存數據對應的節點這樣可以免去服務端進行重定向的工作，這在一定程度上可以提高效率。

　　Redis集群有哪些功能

　　Keys分配模式

　　一個集群可以包含最多4096個節點(但是我們建議最多設置幾百個節點)。

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

　　用來計算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個字節。在我們的測試中，對于4096個slots， CRC16算法最合適。

　　集群節點特性

　　在集群中每個節點都擁有唯一的名字。節點名為16進制的160 bit隨機數，當節點獲取到名字后將被立即啟用。節點名將被永久保存到節點設置文件中，除非系統管理員手動刪除節點配置文件。

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

　　每個節點可獲知其他節點的信息包括：IP 端口、狀態、管理的hash slots、cluster bus最后發送PING的時間、最后接收到PONG的時間、從節點數量、節點ID。

　　無論是主節點還是從節點都可以通過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

　　節點交互

　　所有節點總是允許接受來自cluster bus的連接請求，并且即使請求PING的節點是不可信的也會進行應答。然而，所有來自非集群節點的packets都會被忽略。

　　只有以下兩種情況節點才會把其他節點認為是集群的一部分：

　　如果一個節點使用 MEET message 介紹自己。MEET message 命令是強制其他節點把自己當成是集群的一部分。只有系統管理員使用 CLUSTER MEET ip port 命令節點才會發送MEET message給其他節點。

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

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

　　這個機制使得集群系統更加健壯。

　　當一個節點故障時，其余節點會嘗試連接其他所有已知的節點已確定其他節點的健壯性。

　　被移動數據的重定向

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

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

　　MOVED 錯誤如下：

　　GET x

　　-MOVED 3999 127.0.0.1:6381

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

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

　　客戶端雖然不被要求但是應該嘗試去記住hash slot 3999現在已被轉移至127.0.0.1:6381。這樣的話，當一個新的命令需要從hash slot 3999獲取數據時就可以有更高的幾率從hash slot獲取到正確的目標節點。

　　假設集群已經足夠的穩定(不增刪節點)，那么所有的客戶端將會擁有一份hash slots對應節點的數據，這可以使整個集群更高效，因為這樣每個命令都會直接定向到正確的節點，不需要通過節點尋找節點或者重新計算hash slot對應的節點。

　　集群不下線更新配置

　　Redis集群支持線上增刪節點。實際上對于系統來說，增加和刪除節點在本質上是一樣的，因為他們都是把hash slot從一個節點遷移至另外一個節點而已。

　　增加節點：集群中加入一個空節點并且把hash slot從已存在的節點們移至新節點。

　　刪除節點：集群刪除一個已存在節點并且把hash slot分散到已存在的其他節點中。

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

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