like pipelining, multi-operations is another way to significantly improve performance. In cluster mode, there is a limitation to only support one slot keys multi-operation, or the server will response with CROSSSLOT error code. This limitation actually make the multi-operations not that useful, we have to group keys by slot on client side and issue separate multi- commands to the right instances, this is OK since a "smart client" have to deal with rules like that, but considering there are 16384 slots, there is a big chance that we separate, say 1000 keys , by slot to 1000 multi-operations, each multi- just fetch/put only one key, we get no benefit from this. Is there any risk to change the limitation of multi-operation, to let it enable cross slot, but still, to make REDIR/ASKING work, we restrict it not to cross node? I mean if all the slots of multi- keys are served by the instance which receives the multi- command, getNodeByQuery() will let it go or it still returns error code, and if any of the slot are in MIGRATING or IMPORTING status, the current limitation still respected. In production, the biggest cluster here is with 40 instances, separate 1000 keys to 40 multi-operation seems more useful than 1000 separate multi-operations with only one key.
Comment From: madolson
That would push a lot of complexity to the clients. This is probably not going to ever get implemented.
Comment From: oranagra
I would add that having redis process a command that access multiple slots which happen to be on the cluster node that received it, would mean that some applications that are not really "cluster ready", may appear to work on a cluster, until some resharding happens and then they'll suddenly break. So we probably never want commands such as SUNIONSTORE or MULTI-EXEC to allow that. Regarding MGET and alike, I don't think the performance difference between MGET and a pipelined GET is that big.
Comment From: RedisOptimal
https://github.com/RedisOptimal/redis-cluster-support-mget This code support mget/mset running in same node, not the same slot. mgetSeries/msetSeries will partition key by node, and run mget/mset command one by one in each node. Finally, merge result and return. Pipelined GET is better than my implement.