Centos7 install redis3.2.5 Cluster
Centos7 install redis3.2.5 Cluster
This article is about installing the redis3.2.5 cluster on the centos7 System of the VM.
Redis cluster Introduction
When the redis cluster is started, it automatically splits slices among multiple nodes. At the same time, the availability between shards is provided: when some redis nodes fail or the network is interrupted, the cluster can continue to work. However, when a large area of node failure or network interruption (for example, most of the master nodes are unavailable), the cluster cannot be used. Therefore, from a practical perspective, Redis clusters provide the following functions: ● automatically split data into multiple redis nodes ● when some nodes are down or inaccessible, the cluster can continue to work
Sharding of Redis cluster data
Redis clusters use a hash slot instead of a consistent hash. The entire redis cluster has 16384 hash slots. The algorithm that determines which key should be allocated to is: Calculate the CRC16 result of the key and then model 16834. Each node in the cluster is responsible for part of the hash slot. For example, if the cluster has three nodes, the range of hash slots stored by node A is: 0-5500 ● the hash slot range of Node B Storage is 5501-11000 ● the hash slot range of node C storage is 11001-16384, which facilitates addition and deletion of nodes. For example, to add A new node D, you only need to move part of the hash slot data in A, B, and C to the D node. Similarly, if you want to delete node A in the cluster, you only need to move the data in the hash slot of node A to Node B and node C. After all the data of node A is removed, node A can be completely deleted from the cluster. Because there is no need to stop moving a hash slot from one node to another, adding or deleting a node or changing the hash slot on the node do not need to be stopped. If multiple keys belong to one hash slot, the cluster supports simultaneously operating these keys through one command (or transaction, or lua script. With the concept of "hash tag", you can allocate multiple keys to the same hash slot. The hash tag is described in the detailed cluster document. Here is a brief introduction: if the key contains braces ({}), only strings in braces () are involved in the hash, for example, the keys "this {foo}" and "another {foo}" are allocated to the same hash slot, so they can be operated simultaneously in a single command.
Master-slave mode of Redis Cluster
To ensure that the cluster still works properly when some nodes fail or the network is disconnected, the cluster uses a master-slave model, with each hash slot having one (master node) to N copies (N-1 slave nodes ). In the preceding cluster example, there are three nodes A, B, and C. If node B fails, the cluster cannot work normally, because the hash slot data in Node B cannot be operated. However, if we add A slave node to each node, it becomes: A, B, and C are the Master nodes, A1, B1, and C1 are their slave nodes respectively, when Node B goes down, our cluster can also operate normally. Node B1 is a copy of Node B. If node B fails, the cluster will upgrade node B1 to the master node, so that the cluster can continue to work normally. However, if both B and B1 fail, the cluster cannot continue to work. Redis cluster consistency ensures that the Redis cluster cannot guarantee strong consistency. Some operations that have been successfully written to the client will be lost in some uncertain situations. The first reason for the loss of write operations is that data is synchronized asynchronously between the master and slave nodes. A write operation is like this: 1) the client initiates a write operation to the master node B. 2) the master node B responds to the client's write operation. 3) the master node B sends a write operation to its slave node B1, B2, the write operation in B3 synchronization can be seen from the above process. The master node B does not wait for the result of this operation from the client after the completion of node B1, B2, and B3. Therefore, if master node B fails after it notifies the client that the write operation is successful but is synchronized to slave node, one of the slave nodes that did not receive the write operation will be promoted to the master node, the write operation will be lost forever. Just like a traditional database, it writes back to the disk every second without distributed data. To improve consistency, you can reply to the client after writing the disk, but this will result in performance loss. This method is equivalent to the synchronous replication mode used by the Redis cluster. Basically, there is a trade-off between performance and consistency.
Create and use a Redis Cluster
Step 1: Download The redis3.2.5 source file
I put the downloaded software under/usr/soft [root @ localhost/soft] wget http://download.redis.io/releases/redis-3.2.5.tar.gzwith the following results:
[Root @ localhost/soft] tar xvf redis-3.2.5.tar.gz [root @ localhost/soft] cd redis-3.2.5 [root @ localhost/redis-3.2.5] make & make install this time may report an error, the reason is that gcc needs to install [root @ localhost/soft] yum install gcc successfully, after returning to the redis-3.2.5/src directory, run the make command [root @ localhost/redis-3.2.5] make & make install.
Step 2: Check whether the make command execution result is correct.
The output prompt will strongly recommend that you run the make test command to check whether the result of the make command is correct (you can also skip the make tet command to continue building the redis cluster)
[Root @ localhost/redis-3.2.5] make test at this time may report an error, such
The reason is: tcl is missing
Step 3: Install tcl8.6.6
Install tcl: [root @ localhost/soft] wget kernel/soft] tar xvf tcl8.6.6-src.tar.gz [root @ localhost/tcl8.6.6] cd tcl8.6.6/unix/[root @ localhost/unix]. /configure make & make install: Wait for a while and check the output information. If there is no error, click OK. Now go back to the redis-3.2.5/src directory [root @ localhost soft] # cd redis-3.2.5/src [root @ localhost/src] # make test wait, have a drink and come back
OK. At this point, redis compilation is OK
Step 4: Create a cluster configuration file
[Root @ localhost soft] # mkdir redis_cluster [root @ localhost soft] # cd redis_cluster [root @ localhost redis_cluster] # mkdir conf in this directory, create six configuration files from redis_7000.conf to redis_7005.conf. Now create redis_7000.conf, and the remaining five cp will be ready, change the port number in the content to the corresponding 700 * [root @ localhost conf] # touch redis_7000.conf [root @ localhost conf] # vim redis_7000.conf convert daemonize yes pidfile/var/run/redis_7000.pid port 7000 cluster-enabled yes cluster-config-file nodes_7000.conf cluster-node-timeout 5000 appendonly yes paste to the file Esc: wq, save and quit
[Root @ localhost conf] # cp redis_7000.conf redis_7001.conf [root @ localhost conf] # cp zookeeper [root @ localhost conf] # cp redis_7000.conf redis_7003.conf [root @ localhost conf] # cp redis_7000.conf restart [root @ localhost conf] # cp redis_7000.conf redis_7005.conf remember to modify the field corresponding to the port of the file content after cp: daemonize yes // run pidfile/var/run/redis_7000.pid in the redis background // port 7000 corresponding to the pidfile // port cluster-enabled yes // enable the cluster to comment # Remove cluster-config- file nodes_7000.conf // the configuration file of the cluster is automatically generated at the first startup. cluster-node-timeout 5000 // The request timeout value is set to 5 seconds. If the appendonly yes // aof log is enabled, it must be enabled, it records a log for each write operation and uses the tree Command to clearly view the directory structure: [root @ localhost redis_cluster] # yum install tree [root @ localhost redis_cluster] # Six files configured by tree-I conf are shown in figure
Start these six redis instances
View the started redis Process
View the listening ports of the redis6 Processes
Step 5: Build a cluster
Now we have six running Redis instances. Next we need to use these instances to create clusters and write configuration files for each node. By using Redis-trib, The redis cluster command line tool, you can easily write node configuration files: redis-trib is located in the src folder of Redis source code, and is a Ruby program, this program sends a special command to the instance to create a new cluster, check the cluster, or reshare the cluster. So we need to install ruby [root @ localhost redis_cluster] # yum install ruby
[root@localhost redis_cluster]# yum install rubygems
[root@localhost redis_cluster]# gem install redis
[Root @ localhost src] #. /redis-trib.rb create -- replicas 1 127.0.0.1: 7000 127.0.0.1: 7001 \> 127.0.0.1: 7002 127.0.0.1: 7003 127.0.0.1: 7004 127.0.0.1: 7005 this command is used here to create a new cluster, option-replicas 1 indicates that we want to create a slave node for each master node in the cluster. The other parameters that follow are the address list of the cluster instance. The three master3 slave redis-trib will print out the expected configuration for you, if you think there is no problem, you can enter yes, redis-trib will apply this configuration to the cluster, so that each node can start to communicate with each other, and finally get the following information:
Enter "yes" and press Enter.
"M:" On the left indicates that the node is a master node, and "S:" indicates that the node is a slave node.
Test cluster:
The Redis-cli program in the redis Branch provides basic cluster support. You can run the redis-cli-c command to start the cluster.
Set yy yao on 7000 and the cluster is automatically saved to 7001. Set yy2 go2 on 7000 and the cluster is automatically saved to 7001. Get yy2 on 7000, and the cluster automatically goes to 7001.