0

I want to use Redis for a particular use case. I am not sure to go with a Redis Cluster or with Twemproxy + Sentinel.

I know the Cluster is a winner any day. I am just skeptical due to the MOVED responses. In case of MOVED responses, the client will connect another node and in case of resharding, it may have to connect another again. But in case of Twem, it knows where the data is residing, so it will never get a MOVED response.

There are different problems with Twem, like added hop, may increase overall turnaround time, problem with adding new nodes or if it ejects some nodes out, it won't be able to serve the requests for the keys present on that node. Extra maintenance headache as in, having sentinels for my Redis instances and mechanism for HA of twem itself.

Can anyone suggest me, should I go with Twem or Cluster? I am thinking of going with Twem as I will not be going to and fro in case of MOVED responses. But I am skeptical about it, considering the above mentioned concerns.

P.S. I am planning to using Jedis client for Redis (if that helps).

Tarun
  • 152
  • 1
  • 15

1 Answers1

3

First of all, I'm not familiar with Twemproxy, so I'll only talk about your concerns on Redis Cluster.

Redis client can get the complete slot-node mapping, i.e. the location of keys, from Redis Cluster. It can cache the mapping on the client side, and sends request to the right node. So most of the time, it won't be redirected, i.e. get the MOVED message.

However, if you add/delete node or reshard the data set, client will receive MOVED message, since it still uses the old mapping. In this case, client can update its local cache, and any subsequent requests will be sent to the right node, i.e. no MOVED message any more.

A decent client library can take the above optimization to make it more efficient. So if your client library has this optimization, you don't need to worry about the MOVED penalty.

for_stack
  • 21,012
  • 4
  • 35
  • 48
  • Thanks @for_slack. What I understand from your answer is that it means that the client would be synching the location of keys periodically from the cluster. What if I have a lot of keys, will the client be able to load all that in memory? – Tarun Nov 01 '18 at 10:32
  • 1
    @Tarun NO. Client only needs a slot-node mapping which is very small. For a given key, client can calculate the slot number of the key dynamically, i.e. CRC16, look up the slot-node mapping to find the corresponding node, and sends request to that node. – for_stack Nov 01 '18 at 12:17
  • Thanks. I checked lettuce and Jedis. I could find this thing in Jedis, but not in lettuce. I think all clients do not provide this then. Anyhow, I was going to use Jedis anyway. So thank you for helping me here. – Tarun Nov 02 '18 at 06:53