Consistent hashing gives a lot of nice properties when it hashes servers into a ring:
- servers are randomly distributed in the ring, good for balancing load in a cluster
- add/remove a server only affect its neighbors, minimize data migration
However, I don't think you can control which key goes to which server: i.e. I can't do the following assignment:
key 1-99 ==> serverA
key 100 ==> serverB
// I can probably reach the same traffic split, 99:1
// by given more virtual nodes to serverA, but it won't guarantee
// key 1 and key 99 is served by the same machine
This is allowed in redis, redis uses hash slot, which I believe is an explicit map from hash value -> severs. This gives you full control, especially it enables multi-key transaction: i.e.
key Alice, key Bob ==> serverA
// move 100$ from Alice's bank account to Bob's in one operation
// no need special technique like 2 phase commit
The key -> server mapping is now managed by yourself as opposed to by consistent hashing, the drawback is that there are more work/responsibility for the admins, Redis also provides commends to help you with the management: rebalance
, reshard
Disclaimer: this is my own understanding (here's my sources), I wish I can just @redis_dev on stackoverflow and let them proofread my answer