-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
ioredis 2: custom filter predicates for "scaleReads" #250
Comments
Sounds interesting. Could you give me an example about the custom function case? P.S. It seems that redis always consider |
The one I'm personally having at the moment is that my cluster spans across multiple network subnets, and the latency between them is relatively large. So my function would take the node's IP, check if it's in the "local subnet IP range", and return a lower priority if it isn't. This would lower significantly the read times, as otherwise reads would go to a random slave which may or may not be nearby (i.e. 50ms latency instead of 1ms latency). P.S.: That is too bad 😞 Yet another regression from classic Redis. |
That makes sense. What about a function with two parameters new Redis.Cluster([/* nodes */], {
scaleReads: function (slaves, command) {
if (command.name === 'get') {
return 0;
}
}
}); |
That could work, although I thought that you'd prefer to keep as much logic as possible inside the library, just letting the custom function filter out low-prioritized nodes. Your suggestion 100% solves the problem. |
Closing this issue in favour of #252. |
Great job, btw, both on ioredis 1 and ioredis 2!
It would be really great if it would be possible to give the "scaleReads" option a custom function that filters which nodes are applicable to be read from, in case not all nodes are born equal (e.g. some are closer to the application than others, network-wise).
Thinking about it, even a bit more:
If you agree that this is at least an acceptable feature, I could open a PR for you into the 2.x branch.
P.S.: shouldn't there be a way to mark eval/evalsha as readonly - so reading lua scripts won't be redirected to a master?
The text was updated successfully, but these errors were encountered: