You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/operate/rc/databases/configuration/clustering.md
+6-4Lines changed: 6 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -120,10 +120,6 @@ The Standard hashing policy is mostly consistent with the Redis hashing policy,
120
120
1. Keys with a single hashtag: a key's hashtag is any substring between '{' and '}' in the key's name. That means that when a key's name includes the pattern '{...}', the hashtag is used as input for the hashing function. For example, the following key names have the same hashtag and are mapped to the same slot: foo{bar}, {bar}baz & foo{bar}baz.
121
121
1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing
122
122
123
-
However, this policy is less recommended and you should select it only if any of the following conditions apply:
124
-
- Your application uses empty hashtags to hash different keys to the same hashslot
125
-
- Your application uses multiple curly brackets within a key’s name
126
-
127
123
In some cases, the Standard hashing policy behaves differently from the Redis hashing policy:
128
124
1. Using empty hashtags (“{}”): the Standard hashing policy does not ignore empty hashtags, so two keys that start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them).
129
125
For example: given 2 keys {}foo and {}bar, hashing would be:
@@ -134,6 +130,12 @@ In some cases, the Standard hashing policy behaves differently from the Redis ha
134
130
- Standard hashing policy: substrings “foo}bar” and “foo}qux” will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.
135
131
- Redis hashing policy: the substring “foo” will be used for both keys, hashing them to the same slot.
136
132
133
+
{{< note >}}
134
+
To allow seamless transition between hashing policies, the following techniques are not recommended:
135
+
- Using empty hashtags to hash different keys to the same hashslot
136
+
- Using multiple curly brackets within a key’s name
0 commit comments