當我們提交了一批命令，往Redis中存儲一批鍵，那麼這些鍵一般會被映射到不同的slot，而不同的slot又可能在Redis Cluster中不同的節點上，這樣就和的預期有點不同，有沒有辦法將這批鍵映射到同一個slot呢？ 答案是可以。
哈希標籤是確保兩個鍵都在同一個哈希槽裏的一種方式。將來也許會使用到哈希標籤，例如爲了在集羣穩定的情況下（沒有在做碎片重組操作）允許某些多鍵操作。
爲了實現哈希標籤，哈希槽是用另一種不同的方式計算的。基本來說，如果一個鍵包含一個 “{…}” 這樣的模式，只有 { 和 } 之間的字符串會被用來做哈希以獲取哈希槽。但是由於可能出現多個 { 或 }，計算的算法如下：
- 如果鍵包含一個 { 字符。
- 那麼在 { 的右邊就會有一個 }。
- 在 { 和 } 之間會有一個或多個字符，第一個 } 一定是出現在第一個 { 之後。
然後不是直接計算鍵的哈希，只有在第一個 { 和它右邊第一個 } 之間的內容會被用來計算哈希值。
例子：
- 比如這兩個鍵 {user1000}.following 和 {user1000}.followers 會被哈希到同一個哈希槽裏，因爲只有 user1000 這個子串會被用來計算哈希值。
- 對於 foo{}{bar} 這個鍵，整個鍵都會被用來計算哈希值，因爲第一個出現的 { 和它右邊第一個出現的 } 之間沒有任何字符。
- 對於 foozap 這個鍵，用來計算哈希值的是 {bar 這個子串，因爲它是第一個 { 及其右邊第一個 } 之間的內容。
- 對於 foo{bar}{zap} 這個鍵，用來計算哈希值的是 bar 這個子串，因爲算法會在第一次有效或無效（比如中間沒有任何字節）地匹配到 { 和 } 的時候停止。
- 按照這個算法，如果一個鍵是以 {} 開頭的話，那麼就當作整個鍵會被用來計算哈希值。當使用二進制數據做爲鍵名稱的時候，這是非常有用的。
上代碼：
不使用哈希標籤的情況
上面代碼沒有使用hash標籤，必然數據會被分配到不同的hash槽中
結果：
可以看到foo2，foo4，foo1被分配到3個節點中
使用哈希標籤的情況：
加了test的hash標籤，結果：
可以看到hash標籤生效了