On the internet to find the Redis cluster related documents, many of the master-slave or master-slave failover is said to be a cluster, the first few days to play the next group, today finally write a part of the content, can be shared out.
I. Introduction to the basics of Redis cluster
1, Redis cluster Introduction: The
Redis cluster is a facility that can share data between multiple REDIS nodes. The
Redis cluster provides a degree of availability through partitioning: The cluster can continue to process command requests even if some of the nodes in the cluster fail or are unable to communicate. The
Redis cluster provides the following two benefits:
(1) The ability to automatically slice (split) data to multiple nodes.
(2) The ability to continue processing command requests while a subset of nodes in a cluster fails or is unable to communicate.
2, the data sharding function of the cluster:
The Redis cluster does not use a consistent hash, but instead introduces the concept of a hash slot. The
Redis cluster has 16,384 hash slots, and each key determines which slot to place by using the CRC16 checksum to 16384 modulo. Each node in the cluster is responsible for a portion of the hash slot. This structure makes it easy to add or remove nodes, and either adding or modifying a node does not cause the cluster to be unusable.
3. The master-slave architecture of the Redis cluster:
The cluster uses a master-slave replication model, with N-1 replicas for each node, in order for the cluster to still be available if some nodes fail or if most of the nodes are unable to communicate.
Eg: if there is a cluster with a,b,c three nodes, if node B fails without a replication model, then the entire cluster will not be available for a slot that is missing the range of hash slots assumed by the B node.
However, if we add a slave node a1,b1,c1 to each node when the cluster is created (or over time), then the entire cluster will have three master nodes and three slave nodes, so that after the failure of Node B, the cluster will elect B1 to continue service for the new primary node. The entire cluster will not be unusable because the slots cannot be found. Of course, if B and B1 are down, the cluster is still unavailable.
second, build and use Redis cluster
1, Architecture anatomy:
ip port
192.168.1.223 &N Bsp; 6379, 6380, 6381, 6382 6383
192.168.1.226 6379, 6380, 6381, 6382 6383
2. Installing Redis:
The Redis installation method is no longer elaborated, see reference to the previous document:
http://www.minunix.com/2014/07/redis-install/
3. Modify the Redis configuration file:
As with the configuration in the previous configuration file, you only need to open the following three items in the cluster section of the configuration file:
cluster-enabled Yes
Cluster-config-file "Nodes.conf"
Cluster-node-timeout 1500
Other configurations with Redis Foundation and deployment documentation;
The cluster-enabled option in the file is used to open the cluster mode of the instance, while the Cluster-conf-file option sets the path to save the node profile, the default value is nodes.conf. The node profile is not required to be modified by Redis The cluster is created at startup and is automatically updated if necessary.
To allow the cluster to operate at least three primary nodes, it is strongly recommended to use six nodes when starting the cluster function: Three are primary, while the remaining three are the slave nodes of each master node. In this example, 10 nodes, 5 primary nodes, and 5 slave nodes are used.
4, build the cluster:
By using the Redis Cluster command-line tool Redis-trib, the work of writing node profiles can be done very easily: Redis-trib is located in the Redis Source src folder, which is a ruby program that creates a new cluster by sending special commands to the instance , check the cluster, or re-shard (reshared) the cluster.
#./redis-trib Create--replicas 1 192.168.1.223:6379 192.168.1.223:6380 192.168.1.223:6381 192.168.1.223:6382 192.168.1.223:6383 192.168.1.226:6379
192.168.1.226:6380 192.168.1.226:6381 192.168.1.226:6382 192.168.1.226:6383
This statement is a command to create a cluster where "--replicas 1" means to create a slave node for each node in the cluster, followed by the entity ip:port of the node;
Redis-trib will print out an expected configuration to show you, if you feel no problem, you can enter Yes, Redis-trib will apply this configuration to the cluster, each node communicates with each other, to get the following results:
[OK] All nodes agree about slots configuration.
>>> Check for open Slots ...
>>> Check Slots Coverage ...
[OK] All 16384 slots covered.
This means that 16,384 slots in the cluster have at least one master node in process and the cluster is functioning normally.
5. Test cluster:
The simple way to test a Redis cluster is to use Redis-rb-cluster or REDIS-CLI, and we'll use REDIS-CLI as an example to demonstrate:
#./redis-cli-h 192.168.1.223-p 6379-c
192.168.1.223:6379> Set AA bb
Ok
192.168.1.223:6379> Set-DD
-Redirected to Slots [5878] located at 192.168.1.226:6379
Ok
192.168.1.226:6379>get AA
-Redirected to Slots [1180] located at 192.168.1.223:6379
"BB"
192.168.1.223:6379> Get 33
-Redirected to Slots [5878] located at 192.168.1.226:6379
"DD"
As you can see, the Redis cluster has been built.
REDIS-CLI support for the cluster is very basic, so it always relies on the Redis cluster node to turn it (redirect) to the correct node. A real (serious) cluster client should do better than this: it should use the cache to record the mapping (map) between the hash slot and the node address, thus directly sending the command to the correct node. This mapping only changes when there are certain modifications to the configuration of the cluster, such as after a failover (failover), or after the system administrator modifies the layout of the cluster by adding nodes or removing nodes.
This article is from the "Dream to Reality" blog, please be sure to keep this source http://lookingdream.blog.51cto.com/5177800/1828497
Redis Cluster cluster