-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
redis cluster/consistent hash #4001
Comments
The purpose of this implementation is to save costs, because the redis network bandwidth on Alibaba Cloud is linked to capacity. If you use a larger bandwidth, you can only upgrade the redis specifications. However, in some cases, your business does not need such a large bandwidth. redis capacity, then you can choose to use several small redis combinations. We saved 8 times the cost by using this method. |
Are these small capacity redis selected to form a cluster a shard cluster? If it is not a sharded cluster, how is the node change data migration implemented? |
Other question, why not just use codis? thx @MarkJoyMa |
Why do you need to migrate? If there are new or reduced nodes in the cache cluster, just re-obtain the db normally. This is only used as a cache. |
codis is a distributed Redis solution. It is not equivalent to the cache here. In other words, the capabilities provided by the cache are functionally equivalent to the sharding logic of codis. It does not provide a distributed Redis solution. |
Another point, we have to pay attention to a core issue, what is the purpose of the cache array here? It is not to solve the redis distribution problem, but to achieve the purpose of cost control. As for using redis node cluster, codis or other redis solutions, it does not matter. |
In redis cluster mode, go-redis can calculate the hash slot where the key resides and route it to the selected node. Why still need consistent hash?
The text was updated successfully, but these errors were encountered: