In production environments where concurrent requests are high, a single Redis cannot meet performance requirements, and usually a Redis cluster is configured to improve service performance. Redis supported cluster mode after 3.
RedisThe officially provided cluster functionality is centralized, and command requests can be sent to any Redis node. If the key of the request is not handled by that node, it is returned to the client MOVED error, prompting the client to switch to the corresponding processing node for that key. Support cluster modeThe redis client will turn automatically, while the normal mode client will only return the MOVED error.
Let’s take a look at the next common Redis cluster structure:
There are connections between nodes, only the master node can handle the client’s command requests; the slave node replicates the master node data, and upgrades the master node after the master node is offline. Each master node can hang more than one slave node. After the master node is offline, the slave node needs to compete. Only one slave node is elected as the master node..
Consider the following key points:
- How are nodes found each other, and how are requests allocated to each node?
- Some nodes fail, how do other nodes discover and recover?
- How does the main node get out of the line and compete with the nodes?
- Is it possible to make dynamic expansion without interrupting Redis services?
The next few articles will examine the Redis cluster source from these key issues; first, look at the basic data structure of the cluster and how nodes connect to each other
1. data structure
RedisClusters are non central, and each node stores information of all nodes in the cluster. Let’s look at the data structure for storing cluster node information in the Redis source code:
Posted on Categories default