**Redis集群总结**Not long ago, the company’s project was undergoing a high-availability upgrade. One of the redis clusters was upgraded from sentinel to the current redis_cluster cluster mode. I was responsible for it. Here is a summary of the deployment of redis over the years. It’s just personal experience. Talk, please enlighten me.
Summarizing the architecture encountered in the redis project over the years, it can be roughly divided into the following:
1.
Monolithic redis 2. Redis master-slave (service problems require operation and maintenance to manually switch between master and slave)
3. Redis-sentinel mechanism master-slave (liberates part of the operation and maintenance work, redis sentinel replaces operation and maintenance, Perform health monitoring and fault migration for redis master-slave clusters)
4. Redis-cluster cluster (version 3.0 or later, generally recommended to use 5.0 or later, because there are more cli commands supported, which is more convenient for expanding the cluster and shrinking the cluster)
Comparison of 4 total scenarios :
1. The first one is single-instance redis, which is suitable for very simple systems with low availability dependence.
2. The second is to add a master-slave for availability upgrade, but in essence it is still a master serving.
3. The third type only liberates the trouble of manual operation and maintenance than the second type, and it doesn't have much advantage in essence.
4. The fourth type is a set of highly available cluster solutions redis-cluster developed by redis itself.
Principle: The
general principle is to split the redis cluster into N sub-clusters (at least 3), and each sub-cluster will have one and only There is a master and at least one slave (the master and slave in this sub-cluster are not sent through the way of sentry, it is the redis-cluster version that has implemented master-slave synchronization and failure migration), these sub-clusters share 16384 A data slot (just a mathematical algorithm used to mark the data in which cluster is used) The default sub-cluster is evenly distributed, such as Key=hello, then the set action is placed in which sub-cluster crc16hash(key)%16384= The specific data slot determines which sub-cluster to put in.
In fact, no matter which redis we enter from here, we access it in a cluster mode. It will automatically rewrite you to the cluster where the specified data is located according to the value of the hash slot calculated by your key and return it to you. This actually feels dilute the master and slave. I feel this is better
For horizontal expansion of sub-clusters and contraction of clusters, redis-cluster will migrate data synchronously (this is very important).
Redis-cli cluster --help can query the commands used for the cluster (create cluster, meet cluster node relationship, assign slots, etc. These actions can be done with one command after version 5.0)
Draw a rough cluster architecture diagram for the fourth set of solutions below:
