RedisCluster that can use ReadOnly slaves #1789
Conversation
Add a readFrom parameter, whose value can be MASTER(default), SLAVE and BOTH. This parameter will be passed to all the read command, such as GET, MGET etc. When the JedisPool of a slave node is created, READONLY will be sent immediately. JedisClusterInfoCache has a lot of changes!
The JedisClusterInfoCache has been reverted to the original one. Add a new AbstractJedisCluserInfoCache. If the user choose to use ReadFrom.MASTER, the old JedisClusterInfoCache will be created. If the user choose ReadFrom.SLAVE or BOTH, the EnhancedJedisClusterInfoCache will be created. EnhancedJedisClusterInfoCache can remove JedisPools in the process of nodes setup
|
Got all code up & running. Looking forward to this getting merged! |
|
Can anybody else review this PR? |
|
@digitalsonic when is this going to be merged? |
|
@venkatrangan sorry, i don't know, either. |
|
great pr！when it can be merged and release！ |
|
Any plans on merging this? |
|
Any plan for merging this? |
2 similar comments
|
Any plan for merging this? |
|
Any plan for merging this? |
|
To everyone who have asked about merging this PR, first of all I thank you all for your interest in Jedis. This PR has a few backward incompatible parts which wouldn't allow a smooth transition from one version to another for the users who have codes based on the concerned classes. So this specific PR is unlikely to be merged. We have kept open this PR hoping that someone would pick-up the idea and craft another PR with not so backward incompatible parts or at least with "salvageable" ones. Thanks again. |
|
@sazzad16 can you please elaborate more on backward-incompatible changes? I've spotted only Btw looks like by PR |
|
@sazzad16 can you please elaborate more on backward-incompatible changes? That way I could try to offer a new PR with less breaking changes. |
|
@esigma5 @eugeniyk Just try not to remove too many public methods and public classes and/or change their behavior with current parameters. PS: We have started publishing alpha releases for Jedis 5.0. Now is a very good time to work on things that may have breaking parts. Also, if you have something promising please let us know, preferably as WIP or POC, in case we want to wait. @eugeniyk Sincere apologies I missed your comment above. |
|
any news? waiting for it |
JedisCluster uses only Master nodes in the cluster, all the Slave nodes are only standby nodes. In many situation this is a waste of resources.
So I write an EnhancedJedisClusterInfoCache besides the original JedisClusterInfoCache.
When we want to read only from Master, JedisCluster will use JedisClusterInfoCache, nearly nothing changed. But if we want to read from Slave or both Master and Slave nodes, JedisClusterConnectionHandler will create an EnhancedJedisClusterInfoCache.
In the new cache class, there are two maps, one for master nodes and the other for slave nodes.
All the Jedis instances in the slave pool have been sent a ReadOnly command when they were created.
When renewing the slot cache (master goes down or slot migration), both of the two maps will be reset, the JedisPool will be destroyed. So we don't need to worry about writing to a ReadOnly node.
Thanks for reviewing my codes.
P.S.
I've read #790 #830 and some other posts and issues about ReadOnly slaves. And my thought is definitely same with @marcosnils mentioned in #1522 .