Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix how hash slot assignment is retrieved and stored #405

Merged
merged 3 commits into from
Oct 11, 2023

Conversation

Ladicek
Copy link
Contributor

@Ladicek Ladicek commented Sep 20, 2023

Previously, the RedisClusterClient used to obtain the hash slot
assignment as the first step of each connect() call. This is fairly
expensive and increases the load on the first endpoint in the list
(because we target the first endpoint when issuing CLUSTER SLOTS).

It is also unnecessary. Redis always sends a redirection when the node
to which a command is sent is not assigned the hash slot targetted
by the command. Until we observe such redirection, the hash slot
assignment we observed before is still valid. Hence, we can store
the hash slot assignment in the RedisClusterClient and reuse it
for all RedisClusterConnection objects, until the MOVED error
is seen. In such case, we reset the hash slot assignment so that
the next connect() call fetches it again.

To avoid spurious failures (it could happen that the cluster is
resharded such that a command that would fail under the existing
hash slot assignment will no longer fail, because the hash slots
that were previously assigned to multiple nodes are now assigned
to a single node), the hash slot assignment is not kept permanently.
Instead, it is treated as a cache with configurable TTL, defaulting
to 1 second.

Fixes #404

Previously, the `RedisClusterClient` used to obtain the hash slot
assignment as the first step of each `connect()` call. This is fairly
expensive and increases the load on the first endpoint in the list
(because we target the first endpoint when issuing `CLUSTER SLOTS`).

It is also unnecessary. Redis always sends a redirection when the node
to which a command is sent is not assigned the hash slot targetted
by the command. Until we observe such redirection, the hash slot
assignment we observed before is still valid. Hence, we can store
the hash slot assignment in the `RedisClusterClient` and reuse it
for all `RedisClusterConnection` objects, until the `MOVED` error
is seen. In such case, we reset the hash slot assignment so that
the next `connect()` call fetches it again.

To avoid spurious failures (it could happen that the cluster is
resharded such that a command that would fail under the existing
hash slot assignment will no longer fail, because the hash slots
that were previously assigned to multiple nodes are now assigned
to a single node), the hash slot assignment is not kept permanently.
Instead, it is treated as a cache with configurable TTL, defaulting
to 1 second.
@vietj vietj added this to the 5.0.0 milestone Oct 11, 2023
@vietj vietj merged commit df02b83 into vert-x3:master Oct 11, 2023
4 checks passed
@Ladicek Ladicek deleted the fix-cluster-slots-retrieval branch October 11, 2023 06:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

RedisClusterClient gives much higher load to first healthy node
2 participants