Redis中Key中爲什麼要使用{}

Redis集羣介紹

Redis 集羣是一個提供在多個Redis間節點間共享數據的程序集。

Redis集羣並不支持處理多個keys的命令,因爲這需要在不同的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.

Redis 集羣通過分區來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令. Redis 集羣的優勢:

  • 自動分割數據到不同的節點上。
  • 整個集羣的部分節點失敗或者不可達的情況下能夠繼續處理命令。

Redis 集羣的數據分片

Redis 集羣沒有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集羣有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集羣的每個節點負責一部分hash槽,舉個例子,比如當前集羣有3個節點,那麼:

  • 節點 A 包含 0 到 5500號哈希槽.
  • 節點 B 包含5501 到 11000 號哈希槽.
  • 節點 C 包含11001 到 16384號哈希槽.

這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從集羣中移除即可. 由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集羣不可用的狀態.

MSET

單實例上的MSET是一個原子性(atomic)操作,所有給定 key 都會在同一時間內被設置,某些給定 key 被更新而另一些給定 key 沒有改變的情況,不可能發生。

而集羣上雖然也支持同時設置多個key,但不再是原子性操作。會存在某些給定 key 被更新而另外一些給定 key 沒有改變的情況。其原因是需要設置的多個key可能分配到不同的機器上。

##SINTERSTORE,SUNIONSTORE,ZINTERSTORE,ZUNIONSTORE

這四個命令屬於同一類型。它們的共同之處是都需要對一組key進行運算或操作,但要求這些key都被分配到相同機器上。

這就是分片技術的矛盾之處:

即要求key儘可能地分散到不同機器,又要求某些相關聯的key分配到相同機器。

Hash Tags

HashTag機制可以影響key被分配到的slot,從而可以使用那些被限制在slot中操作。

HashTag即是用{}包裹key的一個子串,如{user:}1, {user:}2

在設置了HashTag的情況下,集羣會根據HashTag決定key分配到的slot, 兩個key擁有相同的HashTag:{user:}, 它們會被分配到同一個slot,允許我們使用MGET命令。

通常情況下,HashTag不支持嵌套,即將第一個{和第一個}中間的內容作爲HashTag。若花括號中不包含任何內容則會對整個key進行散列,如{}user:

HashTag可能會使過多的key分配到同一個slot中,造成數據傾斜影響系統的吞吐量,務必謹慎使用。

引用文章

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章