Open andynuss opened 6 years ago
Hi,it's not a recommend usage for xmemcached.If there are many xmemcached client instances, it will consume too much memory,because every instance has it's own reactor/threads etc.
I have an idea long time ago, which make xmemcached instances can share reactor/threads. But i don't implement it right now. I will consider it for next release.
I am using AWS clusters, but doing so in an unusual way. For my needs, scaling up and down is far burstier than most. That is, I go from 2 nodes to 8 or 8 nodes to 2. Therefore, consistent hashing doesn't help much. So what I want to do is on each of my java client machines that talk to the cluster, have one of your MemcachedClient classes for each node. Then there is no need for consistent hashing. What I am doing is this: when I scale up from 2 nodes to 8, I record that now the primary nodecount is 8 and the secondary node count is 2. When I do a get(), I first use my own murmur3 hash of the nodecount modules 8 to select the appropriate MemcachedClient to use, and if that fails, then my getter tries getting from nodecount modulus 2, and if found, adds it to the new primary node. Thus instead of consistent hashing, I pay the cost of 2 gets and a possible migration when the mapping is on the wrong node due to scale up.
The question to you is does your nio-based library handle the construction of many MemcachedClient objects, one per node, in a performant way, or did you design it to only work well with one MemcachedClient object for the entire cluster?