NodeId-bound cluster connections #104
Comments
mp911de
changed the title
|
Renamed issue from slot-bound to node-id-bound. My bad for the initial wrong name |
|
Motivation: Redis cluster nodes can be identified by three-and-a-half means:
The identification details can be moved/changed at runtime. Most prominent examples are slots and master/slave state. A certain nodeId can be moved as well from one host/port to another one. The previous implementation did not care too much about that fact; all connections were identified by host and port. While moving a certain nodeId from one host to another is quite unlikely, it still might happen. The connection pool, therefore, distinguishes now between host and port-bound and nodeId-bound connections. Host and port-bound connections stick to the particular host/port. NodeId-bound connections are reconfigured once the cluster topology changes. Another effect of the change is, the connection management can double the number connections because connections are not shared amongst the identifier classes. |
Motivation: Redis cluster nodes can be identified by three-and-a-half means: * NodeId * Host and Port * Slot ** The half: Master/slave state for a certain slot The identification details can be moved/changed at runtime. Most prominent examples are slots and master/slave state. A certain nodeId can be moved as well from one host/port to another one. The previous implementation did not care too much about that fact; all connections were identified by host and port. While moving a certain nodeId from one host to another is quite unlikely, it still might happen. The connection pool, therefore, distinguishes now between host and port-bound and nodeId-bound connections. Host and port-bound connections stick to the particular host/port. NodeId-bound connections are reconfigured once the cluster topology changes. Another effect of the change is, the connection management can double the number connections because connections are not shared amongst the identifier classes.
Motivation: Redis cluster nodes can be identified by three-and-a-half means: * NodeId * Host and Port * Slot ** The half: Master/slave state for a certain slot The identification details can be moved/changed at runtime. Most prominent examples are slots and master/slave state. A certain nodeId can be moved as well from one host/port to another one. The previous implementation did not care too much about that fact; all connections were identified by host and port. While moving a certain nodeId from one host to another is quite unlikely, it still might happen. The connection pool, therefore, distinguishes now between host and port-bound and nodeId-bound connections. Host and port-bound connections stick to the particular host/port. NodeId-bound connections are reconfigured once the cluster topology changes. Another effect of the change is, the connection management can double the number connections because connections are not shared amongst the identifier classes.
A connection, that is obtained for a particular nodeId, should be stable and survive cluster reconfigurations.
The text was updated successfully, but these errors were encountered: