Ubuntu 16.04 Redis Cluster Cluster Build (official original program)

Tag: End disk determines positive wget results based on LAN class

Prerequisite: First install Redis, reference: http://www.cnblogs.com/EasonJim/p/7599941.html

Note: Redis cluster cluster mode can be used to dynamically add nodes and Downline nodes, which is very convenient to use.

The following tutorials are mainly built through the official documentation:

Https://redis.io/topics/cluster-tutorial

Http://www.redis.cn/topics/cluster-tutorial.html

http://ifeve.com/redis-cluster-tutorial/

http://ifeve.com/redis-cluster-spec/(translated from the official advanced use tutorial)

The Chinese tutorials above can be found in the official documentation provided.

The principle should be as follows:

Note: The following build tutorials are relatively simple, based on pseudo-cluster mode, if the production environment can deploy one instance per machine. The operation is basically consistent.

This tutorial is a brief introduction to the Redis cluster rather than a complex concept of distributed systems. It mainly describes how to build, test, and use Redis clusters from a user's perspective, and the detailed design of the Redis cluster is described in the Redis cluster specification.

This tutorial describes the availability and consistency of redis clusters in an easy-to-understand way, at the perspective of the Redis consumer.

Note: This tutorial requires a version of Redis3.0 or more.

If you plan to deploy a Redis cluster, you can read some detailed design of the cluster, which is not required, of course. Getting started with this tutorial, it's a good idea to start with a Redis cluster and then read the detailed design of the Redis cluster.

Redis Cluster 101

The Redis cluster automatically slices between multiple nodes when it is started. Also provides availability between shards: The cluster can continue to work when a subset of REDIS nodes fail or the network is interrupted. However, when a large area of node failure or network outage (for example, most of the primary node is not available), the cluster cannot be used.

So, from a practical point of view, the Redis cluster provides the following features:

• Automatically slice data into multiple REDIS nodes
• Cluster can continue to work when some nodes are hung or unreachable

TCP ports for Redis clusters

Each node in the Redis cluster needs to establish 2 TCP connections and listen to these 2 ports: One port is called the "client Port", which is used to accept client instructions, interact with the client, such as 6379, and the other port is called "Cluster bus port", which adds 10000 to the client port number. For example, 16379, used for communication between nodes via binary protocol. Each node detects the outage node, updates the configuration, and the failover verification through the cluster bus. Clients can use only client ports and cannot use cluster bus ports. Make sure that your firewall allows you to open both ports, otherwise the Redis cluster will not work. The difference between the client port and the cluster bus port is fixed, and the cluster bus port is 10000 higher than the client port.

Note that there are 2 ports on the cluster:

• The client port (typically 6379) needs to be open to all clients and cluster nodes, because the cluster node needs to transfer data through that port.
• The cluster bus port (typically 16379) is only available for all nodes in the cluster

These 2 ports must be open or the cluster will not work properly.

The interaction of data between cluster nodes via the cluster bus port, using a protocol different from the client's protocol, is a binary protocol, which reduces bandwidth and processing time.

Sharding of Redis cluster data

Redis clusters do not use a consistent hash, but instead use hash slots. The entire Redis cluster has 16,384 hash slots, and the algorithm that determines which one key should be allocated to that slot is: computes the CRC16 result of the key and then modulo 16834.

Each node in the cluster is responsible for a portion of the hash slot, such as 3 nodes in a cluster:

• The hash slot range for Node A storage is: 0–5500
• The hash slot range stored by Node B is: 5501–11000
• The hash slot range stored by node C is: 11001–16384

This method of distribution facilitates the addition and deletion of nodes. For example, a new node D is needed to move some of the hash slot data in a, B, and C to the D node. Similarly, if you want to delete the a node in the cluster, you only need to move the data of the hash slot of the A node to the B and C nodes, and when the data of the a node is all removed, the a node can be completely removed from the cluster.

Because moving a hash slot from one node to another node does not require downtime, adding or removing nodes, or changing the hash slots on the nodes, is not required.

If multiple keys belong to a hash slot, the cluster supports the simultaneous manipulation of these keys through a single command (or transaction, or LUA script). The concept of "hash label" allows the user to assign multiple keys to the same hash slot. Hash tags are described in the cluster detail document, here is a brief introduction: If the key contains curly braces "{}", then only the strings in curly braces will participate in the hash, such as "This{foo}" and "Another{foo}" the 2 keys will be assigned to the same hash slot, So you can manipulate them in one command at the same time.

Master-slave mode for Redis clusters

In order to ensure that the cluster still works properly when a partial node fails or the network fails, the cluster uses a master-slave model, each with one (master node) to N replicas (N-1 nodes). In our earlier cluster example, there are a,b,c three nodes, if the B-node failure cluster will not work properly, because the hash slot data in the B node is not operational. However, if we add a slave node to each node, it becomes: a,b,c three nodes are the primary node, A1, B1, C1 are their slave nodes, and when the B node goes down, our cluster will work. The B1 node is a copy of the B-node, and if the B-node fails, the cluster will elevate the B1 to the primary node, allowing the cluster to continue working properly. However, if B and B1 fail at the same time, the cluster cannot continue to work.

Consistency assurance for Redis clusters

Redis clusters do not guarantee strong consistency. Some operations that have confirmed write success to the client are lost in some uncertain circumstances.

The first reason for the loss of write operations is because the master-slave nodes use asynchronous methods to synchronize the data.

A write operation is such a process:

1) The client initiates a write operation to master Node B
2) Master Node B responds to client write operation succeeded
3) master Node B synchronizes the write operation to its slave node b1,b2,b3

As can be seen from the above process, master Node B does not wait for the result of the client's operation after it has been written from the node b1,b2,b3. Therefore, if master Node B fails after notifying the client that the write operation succeeds, but before synchronizing to the slave node, the master Node B is faulted, and one of the slave nodes that did not receive the write operation is promoted to the master node, and the write operation is lost forever.

Just like a traditional database, it writes back to disk every second without involving a distributed scenario. To improve consistency, you can reply to the client after the write is complete, but you will lose performance. This is equal to how the Redis cluster uses synchronous replication.

Basically, between performance and consistency, a tradeoff is needed.

If you really need it, the Redis cluster supports synchronous replication by using the wait command, which reduces the likelihood of losing write operations. However, even with synchronous replication, Redis clusters are still not strongly consistent, and in some complex situations, such as when a node is selected as the primary node after it loses connectivity to the master node, inconsistencies can occur.

This inconsistency occurs when the client is connected to a small number of nodes (at least one master node), but they are not connected to most other network nodes. For example, 6 nodes, A,b,c is the main node, A1,B1,C1 is their slave node, a client called Z1.

When the network problems, they were divided into 2 groups of networks, the group network connectivity, but the network between the 2 groups are not connected, assuming that a,c,a1,b1,c1 between each other is Unicom, the other side, B and Z1 network is unicom. Z1 can continue to write to B, and B also accepts Z1 write operations. When the network recovers, if the interval is short enough, the cluster can still continue to function properly. If the time is longer, so that B1 on most of the side is selected as the main node, then just Z1 to B write operations will be lost.

Note that Z1 send write to B has a limit, if the length of time to reach the majority of nodes can choose a new master node, a few of the main side of all the primary node will not accept write operations.

The configuration of this time, called node timeout, is very important to the cluster, and when it reaches the time that the node expires, the primary node is considered to be down and can be replaced with one of its slave nodes. Similarly, when a node times out, if the primary node still cannot contact the other primary node, it goes into an error state and no longer accepts write operations.

Redis Cluster parameter configuration

We'll deploy a Redis cluster later as an example, before that, let's introduce the parameters of the cluster in redis.conf.

• cluster-enabled <yes/no>: If you configure "yes" to turn on cluster functionality, this Redis instance is a node of a cluster, otherwise it is a common single redis instance.
• cluster-config-file <filename>: Note: Although this configuration is named "Cluster Profile", this profile cannot be edited manually, it is a file that is automatically maintained by the cluster node and is used primarily to record which nodes are in the cluster, Their status, as well as some persistence parameters, make it easy to restore these states on reboot. This file is usually updated after the request is received.
• cluster-node-timeout <milliseconds>: This is the maximum time that a node in a cluster can be lost, and beyond that time, the node is considered to be faulty. If the primary node exceeds this time or is unreachable, the slave node will initiate a failover and upgrade to the master node. Note that this node will stop receiving any requests if the node is still not connected to most of the primary nodes within this time.
• cluster-slave-validity-factor <factor>: If set to 0, the slave node will attempt to upgrade to the master node regardless of how long the slave node is missing from the primary node. If set to a positive number, then cluster-node-timeout times the time that is obtained by Cluster-slave-validity-factor, which is the maximum time to be valid from the node data after it is lost from the node to the primary node, and will not initiate a failover from the node. Assuming cluster-node-timeout=5,cluster-slave-validity-factor=10, this slave node cannot become the primary node if the slave node is not associated with the primary node for more than 50 seconds. Note that if this parameter is configured to be non-0, it is possible that the cluster will not function properly because a primary node is missing, but not from the top of the node, and in this case, only when the original primary node is re-returned to the cluster.
• cluster-migration-barrier <count>: The minimum number of slave nodes required by the primary node, which is migrated from the node only if the primary node fails. A more detailed introduction can be seen later in this tutorial about replica migration to the section.
• cluster-require-full-coverage <yes/no>: If this parameter is set to "Yes" (the default) when the node where the key is located is not available, the entire cluster will stop accepting the operation; If this parameter is set to " No, the cluster still provides read operations for keys on the nodes that can be reached.

Create and use a Redis cluster

Note: Manually deploying a Redis cluster will give you a good idea of how it works, but if you want the cluster to run as quickly as possible, skip this section and the next section and go directly to the "Create a Redis cluster using Create-cluster script" section.

To create a cluster, you first need an empty Redis instance running in cluster mode. It is also said that Redis launched in normal mode is not a node of the cluster, Redis instances that need to be started in cluster mode can have the characteristics of the cluster nodes, support the command of the cluster, and become the nodes of the cluster.

The following is the minimal redis cluster configuration file (redis.conf):

Port 7000cluster-enabled yescluster-config-file nodes.  appendonly Yes

To turn on cluster mode, simply open the cluster-enabled configuration item. Each Redis instance contains a configuration file, which is nodes.conf (automatically generated at startup) to store some of the configuration information for this node. This configuration file is created and updated by the node of the Redis cluster and cannot be manually modified by the person.

A minimal cluster requires a minimum of 3 primary nodes. For the first test, it is strongly recommended that you configure 6 nodes: 3 Master nodes and 3 slave nodes.

To start the test, proceed as follows: Go to the new directory, create a directory with the port of the Redis instance, and we will run our instance in these directories.

Similar to this:

mkdir cluster-test CD cluster-test mkdir 7000 7001 7002 7003 7004 7005

In 7000-7005 of each directory to create a configuration file redis.conf, the content is the simplest configuration of the above template, note that modify the port number, instead of the directory consistent with the port.

Copy your Redis server (compile/or stabilize the code with the latest code from the unstable branch in GitHub) to the Cluster-test directory and open 6 terminal pages to prepare for the test.

First set:

Starting a Redis instance at each terminal, the instructions are similar to this:

CD 7000../redis-server./redis.conf

In the log we can see that since no nodes.conf file exists, each node gives itself a new ID.

[82462] 11:56:55.329 * No cluster configuration found, I ' m 97a3a64667477371c4479320d683e4c8db5858b1

This ID will always be used by this node as a unique identifier for this node throughout the cluster. The node distinguishes between other nodes and is identified by this ID, not IP or port. The IP can be changed, the port can be changed, but this ID cannot be changed until the node leaves the cluster. This ID is called the Node ID.

Second set:

Third set:

Fourth set:

Fifth set:

Sixth set:

Repeat the first operation.

Create a cluster

Now that 6 instances are running, we need to write some meaningful configuration to the nodes to create the cluster. The command tool redis-trib for Redis clusters makes it very easy to create clusters. Redis-trib is a ruby-written script used to send commands to nodes to create clusters, check cluster status, or re-shard clusters. Redis-trib in the Redis source src directory, gem Redis is required to run Redis-trib.

Gem Install Redis

To create a cluster, simply enter the directive:

./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

The command here is create, because we need to build a new cluster. The option "–replicas 1" indicates that each primary node requires a slave node. Other parameters are the address of the Redis instance that needs to be added to the cluster.

The cluster we created has 3 primary nodes and 3 slave nodes.

Redis-trib will give you some configuration suggestions, enter Yes to accept. Clusters are configured and connected to each other, meaning that each node instance is directed to call each other and eventually form a cluster. Finally, if all goes well, you'll see a message similar to the following:

[OK] All 16384 Slots Covered

This means that 16,384 hash slots are served by the master node as a function.

Creating a Redis cluster using the Create-cluster script

If you don't want to create a cluster by manually configuring the nodes individually, like above, there is a simpler system (and of course, some details of how the cluster works).

In the Utils/create-cluster directory, there is a bash script called Create-cluster. If you need to start a cluster with 3 primary nodes and 3 slave nodes, you only need to enter the following instructions

#1 Start #2
Create-cluster Create

In step 2, when Redis-trib wants you to accept the layout of the cluster, enter "Yes".

Now you can interact with the cluster, and the first node's start port defaults to 30001. When you are finished, stop the cluster with the following command:

Create-cluster stop

Please see the Readme in the directory, which has a detailed description of how to use this script.

The actual operation is as follows:

Version: 4.0.2

: Https://redis.io/download

Offline Version: (Link: https://pan.baidu.com/s/1bpwDtOr password: 4cxk)

Source Code compilation:

wget Http://download.redis.io/releases/redis-4.0.2.tar.gztar xzf redis-4.0.2.tar.gzcd redis-4.0.2make

If you do not install to the specified location, the program is placed by default in the SRC folder,

To create a cluster file and folder:

mkdir cluster-test CD cluster-test mkdir 7000 7001 7002 7003 7004 7005

Enter 7000 to create the redis.conf, which reads as follows:

CD 7000sudo vim redis. conf#7000cluster-enabled yescluster-config-file nodes.  appendonly Yes

Enter 7001 to create the redis.conf, which reads as follows:

CD 7001sudo vim redis.  conf# content Port 7001cluster-enabled yescluster-config-file nodes.  Confcluster-node-timeoutappendonly Yes     

Enter 7002 to create the redis.conf, which reads as follows:

CD 7002sudo vim redis.  conf# content Port 7002cluster-enabled yescluster-config-file nodes.  Confcluster-node-timeoutappendonly Yes     

Enter 7003 to create the redis.conf, which reads as follows:

CD 7003sudo vim redis.  conf# content Port 7003cluster-enabled yescluster-config-file nodes.  Confcluster-node-timeoutappendonly Yes     

Enter 7004 to create the redis.conf, which reads as follows:

CD 7004sudo vim redis.  conf# content Port 7004cluster-enabled yescluster-config-file nodes.  Confcluster-node-timeoutappendonly Yes     

Enter 7005 to create the redis.conf, which reads as follows:

CD 7005sudo vim redis.  conf# content Port 7005cluster-enabled yescluster-config-file nodes.  Confcluster-node-timeoutappendonly Yes     

Start 6 clusters separately:

CD 7000../redis-server./redis.conf

CD 7001../redis-server./redis.conf

CD 7002../redis-server./redis.conf

CD 7003../redis-server./redis.conf

CD 7004../redis-server./redis.conf

CD 7005../redis-server./redis.conf

To create a cluster:

Install Ruby First

sudo apt-get Ruby

Go to src folder

Then install Redis through gem

CD Srcgem Install Redis

If an error occurs, refer to: http://www.cnblogs.com/EasonJim/p/7629314.html

Start

./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

You will be prompted to enter Yes and then basically complete. The output information indicates which are the primary node and the slave node.

Reference:

http://ifeve.com/redis-cluster-tutorial/(The above sections are transferred from this article)

http://blog.csdn.net/fengshizty/article/details/51368004 (Test of node operation)

Http://www.redis.cn/topics/cluster-tutorial.html

http://ifeve.com/redis-cluster-spec/

Http://os.51cto.com/art/201512/499551.htm

http://blog.csdn.net/robertohuang/article/details/70766809

http://blog.csdn.net/robertohuang/article/details/70768922

http://blog.csdn.net/robertohuang/article/details/70833231

Http://blog.chinaunix.net/uid-28396214-id-4981572.html

Http://blog.51yip.com/nosql/1725.html

Http://www.cnblogs.com/wuxl360/p/5920330.html

http://blog.csdn.net/men_wen/article/details/72853078

http://blog.csdn.net/xu470438000/article/details/42971091

Http://www.cnblogs.com/gomysql/p/4395504.html

Ubuntu 16.04 Redis Cluster Cluster Build (official original program)