Redis (二) —— 高性能的主从模式架构 - 分布式架构+SpringCloud微服务+Redis+Mysql

1. 主从模式架构带来的高性能
2. 主从模式的工作原理
3. 搭建主从模式
4. 主从模式架构测试
5. 主从模式架构优缺点
6. 简单谈谈我对主从架构的理解

缓存方式是系统性能的“银弹“，绝大多数的性能问题我们都能通缓存的方法来得到解决，redis缓存通常是业界缓存技术选型的最佳解决方案，官方宣称 redis能在1s内执行10万条命令。根据官方的数据指标，我们可以简单计算下一台redis 性能与当前业务的量化关系。

任何一个架构师都应该经历过这样的思考过程：假如一次业务流程执行需要执行5条redis的命令，1条写命令和4条读命令，那么一台redis每秒能承受100000/5=20000次的业务，那么我们的这个系统最多就只能每秒开展2万次业务。

那2万真的是我们项目的极限数字吗？
显然不是，如果我们只让这个原来的redis服务器只执行我们一次业务过程中的写命令，其他4条读的命令留给其他4个redis从服务器来执行，即读写分离的缓存架构模式，那么每秒我们就能让我们的项目执行10万次业务。因此我们就需要使用到redis的主从复制原理来搭建这样的主从缓存架构。

注意：主从复制过程是异步的。redis执行命令的进程不需要等待复制过程，复制过程由另外一个进程执行，所以复制过程中，redis主从节点都还能接收并执行命令

2. 主从模式的工作原理

描述： 主从复制从redis服务器拥有和主redis一样的数据，从redis只能执行读命令，写命令拒绝，在主redis中执行的写命令会被复制到从redis中执行，因此能保证redis服务器的数据一致性。因此主从架构模式能扩展了我们项目中redis的性能。

主从复制步骤：

1.从节点执行 slaveof 命令；

2.从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制;

3.从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点;

4.连接建立成功后，发送 ping 命令，希望得到 pong 命令响应，否则会进行重连;

5.如果主节点设置了权限，那么就需要进行权限验证，如果验证失败，复制终止;

6.权限验证通过后，进行数据同步，这是耗时最长的操作，主redis里存量的所有数据都会一起复制到从redis，这也是保证主从redis数据一致性的核心操作，但是如果主redis数据量非常多，将会造成主redis可能无法提供服务。

7.当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

3. linux下搭建主从模式

下载redis： 推荐使用5.0以上的版本，我是用的是5.0.2

wget http://download.redis.io/releases/redis-5.0.2.tar.gz #下载5.0.2版本的redis包

tar zxf redis-5.0.2.tar.gz  #解压redis下载包

mkdir /usr/local/jdkredis/ms/master #创建主从模式的主节点部署文件夹

mv redis-5.0.2/ /usr/local/jdkredis/ms/master #将解压后的redis文件夹移到主节点文件夹

make   #编译redis项目，在/usr/local/jdkredis/ms/master目录下执行该命令

make install  #安装redis ，同样在/usr/local/jdkredis/ms/master目录下执行该命令

主从模式配置文件主要参数如下：
(笔者搭建的主从拓扑结构是一个主节点和两个从节点)

mkdir /usr/local/jdkredis/ms/slave01 #创建从节点slave01文件目录
mkdir /usr/local/jdkredis/ms/slave02 #创建从节点slave02文件目录

配置文件主要参数如下：

mkdir logs && mkdir data   # 作为redis配置文件中 的位置，在每个节点目录下创建logs和data文件夹
vim /usr/local/jdkredis/ms/master/redis.conf
bind 0.0.0.0               #监听ip，多个ip用空格分隔(未尝试) , 0.0.0.0  允许所有ip访问
daemonize yes               #允许后台启动
logfile "/usr/local/jdkredis/ms/master/logs/redis.log"                #日志路径
dir /usr/local/jdkredis/ms/master/data                 #数据库备份文件存放目录
masterauth 123456               #slave连接master密码，master可省略
requirepass 123456              #设置master连接密码，slave可省略，当然slave也可以设置密码

replicaof 192.168.30.128 6379  #这个只有在从redis的配置文件中才会配置，指向的是主redis的ip和端口

appendonly yes                  #在/data/redis/目录生成appendonly.aof文件，将每一次写操作请求都追加到appendonly.aof 文件中

port 6379    #如果你只有一个主机，那就通过区分端口来启动主从redis , 两个从redis可以设置为6380和6381

注意:在linux下redis启动会有要给报警问题，解决方案如下：

echo 'vm.overcommit_memory=1' >> /etc/sysctl.conf ;<br/>
sysctl -p ;

启动redis： 进入主节点和从节点，输入命令：redis-server redis.conf

查看集群状态 登入到redis服务器：redis-cli -h hostip -p 6379 -a password

查看主从模式集群状态如下：

info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.3.9,port=6380,state=online,offset=1148,lag=1
slave1:ip=192.168.3.9,port=6381,state=online,offset=1148,lag=1
master_replid:7b1c7c63904d5e62d6f14e9dd090727342cbbd3c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1148
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1148

如上输出信息，则redis主从模式架构启动成功！！！

4. 主从模式架构测试

主节点写入数据，从节点读数据

192.168.3.9:6380> set  master-slave test  # 写入master节点6380 key=master-slave，value = ms的数据
192.168.3.9:6379> get master-slave     # 从节点6379读 key为master-slave的数据
"test"
192.168.3.9:6381> get master-slave     # 从节点6381读 key为master-slave的数据
"test"
192.168.3.9:6381> set hello hello      # 从节点不能 执行写命令
(error) READONLY You can't write against a read only replica.

主节点6380宕机，其他从节点成为主节点，6380从新启动成为从节点

# redis主从进程如下
[root@JackDKing ~]# ps -ef|grep redis
root      5966  5923  0 11:43 pts/0    00:00:00 grep redis
root     25956     1  0 Mar21 ?        00:20:38 redis-server 0.0.0.0:6380               
root     25967     1  0 Mar21 ?        00:19:07 redis-server 0.0.0.0:6381 
root     26687     1  0 Mar21 ?        00:18:59 redis-server 0.0.0.0:6379  
 
#杀死6380主节点进程
[root@JackDKing ~]# kill -9 25956

#7379从节点升级为主节点，6381作为6379从节点，6380重启也作为从节点
192.168.3.9:6381> slaveof 192.168.3.9 6379
OK

192.168.3.9:6379> info replication  #主从集群信息
# Replication
role:master                         #为主节点
connected_slaves:1
slave0:ip=192.168.3.9,port=6381,state=online,offset=41243001,lag=0
master_replid:405585d690069621bc52ad818f39471dd1126551
master_replid2:2238716c7bee84709f4819024851842edb85eb80
master_repl_offset:41243001
second_repl_offset:41236210
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:40194426
repl_backlog_histlen:1048576

#重启6380
192.168.3.9:6380> info replication
# Replication
role:slave
master_host:192.168.3.9
master_port:6379
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:41283157
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:405585d690069621bc52ad818f39471dd1126551
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:41283157
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:41279408
repl_backlog_histlen:3750
#6380自动成为了6379的从节点

从两个从节点中选中一个成为主节点，使用命令 slaveof [IP] [Port] 我这个新启动的节点之所以没有使用这个命令，是因为配置文件中配置的它指向的主节点就是6379，但如果配置文件配置的主节点不是的话，就需要使用slaveof命令了。

更换主节点后的数据写入和读出情况

192.168.3.9:6379> set 101  test   #主节点6379写入数据
OK
192.168.3.9:6380> get 101         #从节点读出数据
"test"
192.168.3.9:6381> get 101         #从节点读出数据
"test"
192.168.3.9:6381> set 101 test    #从节点不能写数据
(error) READONLY You can't write against a read only replica.
192.168.3.9:6380> set 101  test   #从节点不能写数据
(error) READONLY You can't write against a read only replica.

5. 主从模式架构优缺点

优点：

1.因为主从复制，主机会自动将数据同步到从机，项目可以进行读写分离，提高redis的读写性能，使得并发量和吞吐量能有显著提高。

2.读写分离分担了Master的读操作压力，Slave服务器为客户端提供只读服务，写服务由主节点完成，一定程度上提高了系统的伸缩能力

3.Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。避免了多少个Slave节点就有多少个主从连接的尴尬，降低了Master的压力。

4.Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

5.Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

6.Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作,设置master节点数据不同步保存到文件，而是设置Slave节点做这些工作。

缺点：

1.不具备自动容错和回复功能，主机从机的宕机都会导致客户端部分读写请求失败，需要手动切换和手动重启。

2.系统可用性不高，主机宕机，宕机前短时间内未同步成功的数据，切换主机后，会出现数据不一致的问题。

3.redis的主从复制是全量复制，复制过程会fork出一个子进程对内存生成一个快照文件，同步给从节点，如果内存数据非常大，会降低主节点的性能，甚至是拒绝服务；而且每次主机和从机的全量数据复制会因为主从之间的网络断开重连而发生。