Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Cluster: remove hardcoded Cluster port offset #1556

mattsta opened this Issue · 1 comment

2 participants


Steps to remove the hard-coded REDIS_CLUSTER_PORT_INCR limit currently requiring Redis always uses a port at least 10,000 less than the highest port number:

  • Covert to zero: listenToPort(server.port+REDIS_CLUSTER_PORT_INCR, ... -> listenToPort(0, ...
  • When cluster mode is initialized with an OS-assigned cluster management port, save the port number to internal server state (server->cluster_port or somesuch).
  • Add cluster_port to output of an INFO section.
  • When other nodes communicate by:
    • connect to the redis instance on the regular Redis port
    • get the port
    • connect to the cluster port of the server

Reasons for this change: The 10,000 port offset is slightly arbitrary, and disallowing Redis to run on ports higher than 55535 isn't very clear at first.

Reasons against this change: Using a randomly assigned OS port for cluster communication makes firewalling and network permissions difficult. Options: allow a user-specified cluster port (which would still require custom cluster port discovery as above), or use a smaller port offset (next port up instead of 10,000 ports up).

Reasons against a cluster port at all: I haven't looked into it, but I assume muxing cluster communications over the regular Redis port would cause performance problems somewhere.


Hello Matt, thanks for analyzing the question. I still think the fixed offset is a good idea, you have plenty of opportunities to find a set of port/port+10k that are free, and it makes the Redis Cluster universe a bit simpler: nodes always communicate their primary port that is used everywhere, from cluster nodes, to logging of messages, It is implicit that the binary-chat port for the cluster bus is always at a fixed offset.

If you check your message above, it shows how complexity must be added to implement your proposal. However it is not clear for what gain, since you can run your 2, 20, or 100 cluster instances easily in any reasonable box.

Btw brainstorming is always good!

@antirez antirez closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.