Some flaws in the sentinel architecture:
1. Instantaneous interruption problem. In the sentinel architecture, when the master node hangs up, it needs to be elected and then switched. There is a service suspension time of several seconds to tens of seconds in the middle.
2. The problem of high concurrency limitation, the sentinel only provides write services to one node, and one QPS is only a few w.
3. The memory of a single node cannot be set too large, which is about 10G, otherwise it will cause the persistent file to be too large and affect the efficiency of data recovery and master-slave synchronization.
The Redis cluster architecture can solve the problems mentioned above,
The redis cluster is a distributed server cluster composed of multiple small groups of master and slave nodes
Features: Replication, high availability, sharding characteristics, no central node, horizontal expansion. The official website says it can support tens of thousands of nodes (recommended no more than 1000), and the configuration is simple.
The problem of instantaneous interruption is still not completely solved. If the small cluster where the key that happens to be accessed is hung up, it will wait for that small cluster to be elected and restart. However, the key services in other clusters can be serviced normally.
For the sake of simplicity, the construction is based on one master and one follower instead of the above one master and 2 slave structure.
Reids high-availability cluster construction:
1. According to the machine where redis has been installed, clone 3 machines through the virtual machine
2. Set the ip addresses of the 3 machines to 192.168.0.101, 192.168.0.102, 192.168.0.103 respectively
Tutorial for configuring the network: https://blog.csdn.net/pengweismile/article/details/112910138
3. Make the following configurations on 3 machines respectively,
3.1 Create a new directory and modify the configuration file
cd /home/allen/packages/redis-5.0.3/
mkdir redis-cluster
cd redis-cluster
mkdir 8001 8004
cp /home/allen/packages/redis-5.0.3/conf/redis.config 8001
cp /home/allen/packages/redis-5.0.3/conf/redis.config 8004
vi 8001/redis.config3.2 Configure the following information in the redis.config file, the most important of which is the following bold fields:
port 8001
protected-mode no
daemonize yes
pidfile "/var/run/redis_8001.pid"
logfile "8001.log"
dir "/home/allen/packages/redis-5.0.3/8001"
masterauth allen
replica-read-only yes
requirepass allen
appendonly yes
appendfilename "appendonly.aof"
cluster-enabled yes
cluster-config-file nodes-8001.conf
cluster-node-timeout 100004. Create a directory corresponding to the port number in the redis-5.0.3 item of each machine, and store log data, etc.
cd /home/allen/packages/redis-5.0.3
mkdir 8001 80044.1. Create directories 8002, 8005 under 192.168.0.102 in /home/allen/packages/redis-5.0.3/redis-cluster, create 8003, 8006 on 192.168.0.102, and copy them in by the configuration file redis.config
cd /home/allen/packages/redis-5.0.3/redis-cluster
mkdir 8001 80045.Replace all the redis.config files in the corresponding directories to achieve the purpose of modifying each configuration file
:%s/8001/8004/g
6. Start the redis server on each machine separately
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8001/redis.conf
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8004/redis.conf
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8002/redis.conf
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8005/redis.conf
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8003/redis.conf
[allen@localhost redis-5.0.3]$ src/redis-server redis-cluster/8006/redis.conf 7. Create a cluster and post the log of successful startup
src/redis-cli -a allen --cluster create 192.168.0.101:8001 192.168.0.101:8004 192.168.0.102:8002 192.168.0.102:8005 192.168.0.103:8003 192.168.0.103:8006 --cluster-replicas 1
[allen@localhost redis-5.0.3]$ src/redis-cli -a allen --cluster create 192.168.0.101:8001 192.168.0.101:8004 192.168.0.102:8002 192.168.0.102:8005 192.168.0.103:8003 192.168.0.103:8006 --cluster-replicas 1
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.0.102:8005 to 192.168.0.101:8001
Adding replica 192.168.0.101:8004 to 192.168.0.102:8002
Adding replica 192.168.0.103:8006 to 192.168.0.103:8003
>>> Trying to optimize slaves allocation for anti-affinity
[OK] Perfect anti-affinity obtained!
M: 7e6aa35995b79bef083cbfe60855d6d4ec3ba999 192.168.0.101:8001
slots:[0-5460] (5461 slots) master
S: 499787d7590f9df6d102339c1341c00a1585726f 192.168.0.101:8004
replicates 0f1f5538d02a78e9e5266afc285a4a524e3daa51
M: 383e0df8c3e16aacf86a17cbb7b2819426f9e454 192.168.0.102:8002
slots:[5461-10922] (5462 slots) master
S: 3689c09d371ea3b0b11b4cc3827412220a8b6a11 192.168.0.102:8005
replicates 7e6aa35995b79bef083cbfe60855d6d4ec3ba999
M: 0f1f5538d02a78e9e5266afc285a4a524e3daa51 192.168.0.103:8003
slots:[10923-16383] (5461 slots) master
S: 9a5e3238d9648eba8084c6f5ad62814c61fb73b3 192.168.0.103:8006
replicates 383e0df8c3e16aacf86a17cbb7b2819426f9e454
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.....
>>> Performing Cluster Check (using node 192.168.0.101:8001)
M: 7e6aa35995b79bef083cbfe60855d6d4ec3ba999 192.168.0.101:8001
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: 3689c09d371ea3b0b11b4cc3827412220a8b6a11 192.168.0.102:8005
slots: (0 slots) slave
replicates 7e6aa35995b79bef083cbfe60855d6d4ec3ba999
M: 383e0df8c3e16aacf86a17cbb7b2819426f9e454 192.168.0.102:8002
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 9a5e3238d9648eba8084c6f5ad62814c61fb73b3 192.168.0.103:8006
slots: (0 slots) slave
replicates 383e0df8c3e16aacf86a17cbb7b2819426f9e454
M: 0f1f5538d02a78e9e5266afc285a4a524e3daa51 192.168.0.103:8003
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 499787d7590f9df6d102339c1341c00a1585726f 192.168.0.101:8004
slots: (0 slots) slave
replicates 0f1f5538d02a78e9e5266afc285a4a524e3daa51
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[allen@localhost redis-5.0.3]$ 8. Check to log in to the client in the form of cluster, and check the cluster information, you can see that cluster_know_nodes: 6 is 6 machines.
[allen@localhost redis-5.0.3]$ src/redis-cli -a allen -c -h 192.168.0.101 -p 8004
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.0.101:8004> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:5
cluster_stats_messages_ping_sent:104
cluster_stats_messages_pong_sent:113
cluster_stats_messages_meet_sent:4
cluster_stats_messages_sent:221
cluster_stats_messages_ping_received:112
cluster_stats_messages_pong_received:108
cluster_stats_messages_meet_received:1
cluster_stats_messages_received:221
9. Check the cluster nodes to see the master-slave structure of each machine. Here you can see that the main weights are on different machines. That is, two instances of the same ip will not be a master-slave structure.
192.168.0.101， 8001 8004
192.168.0.102， 8002 8005
192.168.0.103, 8003 8006
8002 (master)-8006 (slave)
8001 (master)-8005 (slave)
8003 (master)-8004 (slave)
192.168.0.101:8004> cluster nodes
9a5e3238d9648eba8084c6f5ad62814c61fb73b3 192.168.0.103:8006@18006 slave 383e0df8c3e16aacf86a17cbb7b2819426f9e454 0 1611145153000 6 connected
3689c09d371ea3b0b11b4cc3827412220a8b6a11 192.168.0.102:8005@18005 slave 7e6aa35995b79bef083cbfe60855d6d4ec3ba999 0 1611145154081 4 connected
0f1f5538d02a78e9e5266afc285a4a524e3daa51 192.168.0.103:8003@18003 master - 0 1611145152121 5 connected 10923-16383
383e0df8c3e16aacf86a17cbb7b2819426f9e454 192.168.0.102:8002@18002 master - 0 1611145153172 3 connected 5461-10922
7e6aa35995b79bef083cbfe60855d6d4ec3ba999 192.168.0.101:8001@18001 master - 0 1611145154181 1 connected 0-5460
499787d7590f9df6d102339c1341c00a1585726f 192.168.0.101:8004@18004 myself,slave 0f1f5538d02a78e9e5266afc285a4a524e3daa51 0 1611145151000 2 connected
192.168.0.101:8004>
10. As you can see, the above information is recorded in the files of the machine every day, as follows, so when you restart during the period, you don’t need to create a cluster anymore. As long as the redis service of each cluster is up, the cluster will start by itself. According to the information below.
[allen@localhost redis-5.0.3]$ pwd
/home/allen/packages/redis-5.0.3
[allen@localhost redis-5.0.3]$ cd 8001
[allen@localhost 8001]$ ls
8001.log appendonly.aof nodes-8001.conf
[allen@localhost 8001]$ less nodes-8001.conf
[allen@localhost 8001]$ cat nodes-8001.conf
3689c09d371ea3b0b11b4cc3827412220a8b6a11 192.168.0.102:8005@18005 slave 7e6aa35995b79bef083cbfe60855d6d4ec3ba999 0 1611145053207 4 connected
383e0df8c3e16aacf86a17cbb7b2819426f9e454 192.168.0.102:8002@18002 master - 0 1611145050117 3 connected 5461-10922
9a5e3238d9648eba8084c6f5ad62814c61fb73b3 192.168.0.103:8006@18006 slave 383e0df8c3e16aacf86a17cbb7b2819426f9e454 0 1611145052000 6 connected
0f1f5538d02a78e9e5266afc285a4a524e3daa51 192.168.0.103:8003@18003 master - 0 1611145052000 5 connected 10923-16383
7e6aa35995b79bef083cbfe60855d6d4ec3ba999 192.168.0.101:8001@18001 myself,master - 0 1611145050000 1 connected 0-5460
499787d7590f9df6d102339c1341c00a1585726f 192.168.0.101:8004@18004 slave 0f1f5538d02a78e9e5266afc285a4a524e3daa51 0 1611145052187 5 connected
vars currentEpoch 6 lastVoteEpoch 0
[allen@localhost 8001]$