search

shinberg / cpp-hiredis-cluster

c++ cluster wrapper for hiredis with async and unix sockets features
BSD 3-Clause "New" or "Revised" License
65 stars 26 forks source link

specifying the "key" access by the command as opposed to using {} inside the key to let redis use the content of the brackets to determine the hash slot #5

Closed saveriocastellano closed 8 years ago

saveriocastellano commented 8 years ago

Hi, I see that in your commands you need to specify the underyling "key" that is accessed by the command. With the normal redis and redis cli you can control where keys are going by using brackets to enclose the portion of the key that must be used for the hashing.

I was wondering how you use this "key" internally just to make sure that it does not conflict with the one embedded in {} considered by redis.

Do you only use the provided key to cache to which node each key is stored in order to minimize redirects???

Another question I have is.. for commands that do not involve keys (like multi, exec, etc) is it find to specify an empty key?

shinberg commented 8 years ago
  1. No there is no need for caching redirections since library calculates hash of key (algorithm for calculating hash is known and specifiend by redis cluster developers) on client side and makes request only to cluster node that exactly contains required key. Library only caches a map of nodes and hash key slots (key hashes are suit for hash slots and each node complies to list of hash slots) so client knows where to send request if configuration is not changed. If configuration is changed then client follows a redirection and caching new cluster configuration. redis-cli doesn't caching anything so it follows redirecions any time when key is in another node.
  2. Command that do not involve keys are not supported since there not keys, transactions are not supported by redis cluster at all for now, you can read this in redis cluster official documentation, correct me if i'm wrong

I hope i correctly understood your questions.