RedisCluster is Redis own son, it is Redis Redis clustering solutions provided by the author himself.
With respect to various Codis, which is to the center, as shown, there are three Redis the cluster nodes, each node is responsible for a portion of the data for the entire cluster, each node is responsible for much of the data may be different. These three nodes are interconnected to form a peer cluster, the cluster information interaction between them to each other by a special binary protocol.
Redis Cluster all data into slots 16384, which is 1024 more than the dividing grooves Codis Finer, wherein each node is responsible for a portion of the slot. Slot information is stored in each node, it is not CODIS, it does not require additional storage node to distributed storage slot information. When Redis Cluster client to connect to a cluster, it will get a slot configuration information of the cluster. So that when the client wants to find a key, it can be positioned directly to the target node.
This differs from the Codis, Codis need to locate the target node Proxy, RedisCluster is positioned directly. To the client node can locate a specific key is located directly, it needs to cache slot-related information, so that it can quickly and accurately locate the corresponding node. At the same time slot because the information there may be a case where the client and server are inconsistent, but also need corrective mechanism to achieve parity adjustment slot information.
In addition, the configuration information RedisCluster each node of the cluster will be persisted to the configuration file, so you must ensure that the configuration file is writable, and try not to rely on manually modify the configuration file.
Slot location algorithm
Cluster default key value will hash algorithm used crc32 obtain an integer value, and then use this integer value modulo 16384 to obtain the specific slot. Cluster also allows the user to force a particular key on the hanging slot, by embedding tag marking key string inside, which can force the key slot is equal to the hanging tag slot is located.
def HASH_SLOT(key)
s = key.index "{"
if s
e = key.index "}",s+1
if e && e != s+1
key = key[s+1..e-1]
end
end
crc16(key) % 16384
end
Jump
When the client sends a command to the wrong node, the node slots will find instructions where key management is not to himself, then it will send a special jump instruction carries the address of the destination node operation to the client, tell the client to connect the node to get the data.
GET x
-MOVED 3999 127.0.0.1:6381
The first parameter is 3999 MOVED instruction slot number corresponding to the key, followed by the destination node address. MOVED preceding instruction has a minus sign indicates that the command is an error message. The client receives MOVED instructions to correct local slot mapping table immediately. Follow all the key slot will use the new map.
migrate
Redis Cluster provides tools redis-trib allows manual adjustment of the distribution of slots operation and maintenance personnel, which uses the Ruby language development, achieved by a combination of a variety of native Redis Cluster command. This Codis done more humane, it not only provides the UI interface allows us to easily migrate, also provides automated tools balance slot, without human intervention can be load balanced cluster. But Redis official policy has always been to provide the minimum available tools are handed over to other communities completed.
The migration process
Redis migration unit is a slot, a groove a slot Redis migrate, when a groove is being migrated, the groove is in a transition state intermediate. The grooves in the original state of a node is migrating, in the state of the target node is importing, from the source to the data representing the target is.
Redis-trib migration tool is first disposed between the source and the destination node intermediate transition state is good, then a list of one-time acquisition of all the source node key slot (keysinslot instructions, may be partially acquired), and then one by one key migration. Each key migration process is based on the original node as a "client" target node, the original node get serialize the contents of the current key execute the dump command and then send commands to the target node by "client" restore carries serialized content as a parameter, the target node then deserialized can restore the contents of memory to the destination node, and then return to "client" OK, the original node "clients" receive and then delete the key out of the current node is complete whole through a single key migration
Cheng.
Get content from a source node => keep to the target node => delete the content from the source node.
Note that the migration process is synchronized, the target node to perform the restore command to delete a node between the original key, the main thread of the original node will be in blocking state until the key was successfully deleted. If the sudden appearance of a network failure during the migration process, migrate the entire slot is only half the battle. In this case both nodes still limbo. Until the next migration tool reconnected when the user is prompted to proceed with the migration. During the migration, if the contents of each key is very small, migrate instruction is executed quickly, it will not affect normal access clients. If the key content great, because migrate instruction is a blocking instruction will result in original and destination node Caton, affecting stable clusters. So in a clustered environment business logic to avoid big key as possible. During the migration process, the process client access vary greatly. First, old and new nodes are part of the slot corresponding to the key data exist. The client first attempts to access the old node, if the corresponding data is still inside the old node, then the old node normal processing. If the corresponding data is not inside the old node, then there are two possibilities, either the data in a new node in either non-existent. Old nodes do not know what kind of situation, so it will return a -ASK targetNodeAddr redirect command to the client. When the client receives the redirect instruction, go to the target node does not execute a command asking any parameters, then re-execute the original instruction at the target operation node.
Asking why the need to perform a command with no arguments it?
Because before the migration is not complete, and normally this slot is not owned by the management of the new node, if this time slot to send the command to the target node, the node is not recognized, it will return a redirect to the client -MOVED instructions tell it to go to the source node to execute. So it will form a redirect loop. The goal is to open the option of asking the instruction target node, tell it to the next instruction can not ignore, and as to their slots to deal with. As can be seen from the above process, the migration will affect the efficiency of the service, the same command a ttl can be done under normal circumstances, but the migration was 3 ttl can get.
Fault Tolerance
Redis Cluster may be provided from a plurality of nodes, single master node fails, the cluster automatically lift wherein a master node for each node from the master node. If a node is not the master node, then when it fails, the cluster will completely unusable state. But Redis also provides a parameter cluster-require-full-coverage may allow some node fails, other nodes can continue to provide external access.
Network jitter
Real-world network room is often not calm, they are often a variety of small problems. For example, network jitter is a very common phenomenon, part of the connection between the sudden becomes inaccessible, then quickly returned to normal. To solve this problem, Redis Cluster provides an option to cluster-node-timeout, means that when a node timeout duration of time lost contact, we can identify the node fails, the need to switch over the primary. Without this option, network jitter can lead to frequent switching from the main (recopy data). There is another option cluster-slave-validity-factor as a multiplication factor to enlarge the timeout to loose fault-tolerant urgency. If the coefficient is zero, then the master switch is not resist the network jitter. If this factor is greater than 1, it becomes the relaxation coefficient from the main switch.
It may be offline (PFAIL-Possibly Fail) and determined offline (the Fail)
Because the Redis Cluster is decentralized, a node considers a node is lost to the node does not represent all agree that it lost to a. Therefore, the cluster had to go through a consultation process, and only when most of the nodes identified with the loss of a node, cluster node only needs to think of the coming of the Lord from the fault-tolerant switch. Redis cluster nodes using Gossip protocol to broadcast their own state and their own perception of change for the entire cluster. For example, a node finds a node that lost to the (PFail), which it will broadcast messages to the entire cluster, other nodes will receive this point lost contact information. If a node receives a certain number of the missing node (PFail Count) has reached the majority of the cluster, the node can be marked to determine the offline state (the Fail), and then broadcast to the whole cluster, forcing the other node also receives the fact that the node has gone offline, immediately switch over the primary and lost to the node.
Basic use Cluster
redis-py Cluster mode is not supported by the client, to use Cluster, must install another package, which is dependent on redis-py package.
pip install redis-py-cluster
Here we look at how redis-py-cluster use.
>>> from rediscluster import StrictRedisCluster
>>> # Requires at least one node for cluster discovery. Multiple nodes is recommended.
>>> startup_nodes = [{"host": "127.0.0.1", "port": "7000"}]
>>> rc = StrictRedisCluster(startup_nodes=startup_nodes, decode_responses=True)
>>> rc.set("foo", "bar")
True
>>> print(rc.get("foo"))
'bar'
Cluster is decentralized, it has a plurality of nodes, when the configuration StrictRedisCluster instance, we can use only one node address, other addresses can automatically be found by the node. However, if more than one node addresses, security will be better. If only one node address, then hung up when this node, the client must be replaced before they can continue to access the address Cluster. The second parameter indicates whether or not to return decode_responses conversion result into a byte array unicode.
Cluster ease of use, together with ordinary redis-py is not very different, just a different way of construction. But they also have considerable different place, such as Cluster does not support transactions, the Cluster mget Compared Redis much slower been split into multiple get command, rename the Cluster method is no longer the atom, it needs transfer data from the original node to the target node.
Slot migration perception
If a slot in the Cluster are migrating or has migrated finished, client can perceive how to change slot it? The client holds the mapping table slot and nodes, it needs to be updated instantly, can normally be issued an instruction to the correct node.
We mentioned earlier that there are two special error Cluster instruction, one is moved, one is asking.
The first is moved to correct slot. If we send instructions to the wrong node, which found that the corresponding instruction slots should not be his management, the address of the destination node will be moved along with instructions to reply to the client to notify the client to access the target node. This time the client will refresh their slot table, then retry instruction, follow all the instructions to play in the slot will go to the destination node.
The second command and moved not the same as asking, which is used to temporarily correct slot. If the current slot is in the migration, the instruction will first be sent to the slot where the old node, if there is data from the old node, it is a direct result of the return, if not, then it may or may not really exist in migration target node. So the old node to a new node informs the client to try to get the data, look at the new node there. This time it will return an error to the client to carry on the target node address asking. After the client receives the asking error, you will go to the target node to try. The client does not refresh the slot mapping table, because it's just a temporary correction slot information of the directive does not affect the subsequent instruction.
Retry 2 times
moved and are asking instruction retry instruction, the client because both Instruction Multiple try again. Have you ever thought readers would not be a case, the client may have to retry it twice? This situation is present, such as an instruction to be sent to the wrong node, the node will inform you that a mistake moved to another node retry give you. So the client retry went to another node, the results this time just for the operation and maintenance personnel to operate slot migration
For, then a reply to the client to inform the client asking command to the target node to retry the command. So here client retries twice.
Retry times
In some special cases, the client will retry even several times, the reader can develop your own brain to think about the hole under what circumstances will retry several times. It is because of the presence of multiple retries, so the client source code where the instruction is executed, there will be a cycle, then sets a maximum number of retries, Java and Python have this parameter, the value just set is not the same. When the number of retries exceeds this value, the client will be thrown directly into the business layer.
Cluster change perception
When the server node changes, the client should receive immediate notification in real-time refresh their node table. That client is how to get notice of it? Here we divided into two kinds: the target node and hung up, the client will throw a ConnectionError, followed randomly pick a node to retry, then the retried node will be assigned to the target slot informing them moved error the new node address. Operation and maintenance information is manually modified cluster, the master switch to other nodes, and remove the old cluster master. Then hit the old node will receive instructions ClusterDown a mistake, inform the current node where the cluster is not available (the current node has been isolated, before it is no longer part of the cluster). Then the client will close all connections, clear the slot mapping table, and then to the upper cast wrong. When the next instruction to be over, it will again try to initialize the node information.