LNMP(16)-配置redis的主从复制和redis的高可用，Redis的集群实现

 一.redis的编译与安装（5.0.8）

[root@server1 Desktop]# tar zxf redis-5.0.8.tar.gz 
[root@server1 Desktop]# cd redis-5.0.8/
[root@server1 redis-5.0.8]# make && make install

上述表示Redis安装完毕。
修改配置文件：
[root@server1 utils]# cd /etc/redis/
[root@server1 redis]# ls
6379.conf
[root@server1 redis]# vim 6379.conf 
bind 0.0.0.0  打开所有的6379端口。
 [root@server1 redis]# /etc/init.d/redis_6379 stop  
Stopping ...
Redis stopped 
[root@server1 redis]# /etc/init.d/redis_6379 start  启动redis
Starting Redis server...
[root@server1 redis]# netstat -antulp |grep redis
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      26305/redis-server  

二.redis的主从复制

1.主从复制的原理（全量复制+增量复制）：

全量复制：

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。
1）从服务器连接主服务器，发送SYNC命令；
2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写名令；
3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量复制：

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

2.redis主从复制策略：

主从刚刚连接的时候，进行全量同步；全量同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

3.redis的复制机制：

对于slave端来说，主从复制主要经历四个阶段：(1)与master建立连接；(2)向master发起同步请求（SYNC）；(3)接受master发来的RDB数据；(4)载入RDB文件

4.实验环境(rhel7.6版本)

1.selinux和firewalld状态为disabled

2.各主机信息如下：

主机	ip
server1（主机）	172.25.254.1
server2（从机）	172.25.254.2

三、redis主从复制的部署

1.配置server1（主机）：

<1>安装redis

（1）下载安装包：redis-5.0.3.tar.gz，并解压

[root@server1 ~]# tar zxf redis-5.0.6.tar.gz
[root@server1 ~]# cd redis-5.0.6		#进入解压目录

（2）下载编译依赖的软件gcc

 [root@server4 redis-5.0.6]# yum install gcc -y

（3）cd redis-5.0.6进行编译

 [root@server1 redis-5.0.6]# make
 [root@server1 redis-5.0.6]# make install

（4）cd utils执行./install_server.sh，一路敲回车。会生成配置文件，端口信息等。

[root@server1 redis-5.0.6]# cd utils/
[root@server1 utils]# ./install_server.sh

至此redis的安装，也就完成了。当redis安装完成之后，redis服务就已经开启。可以来用查看端口的方法（redis服务的端口是6379），来查看redis服务是否开启。

<2>配置redis

（1）修改配置文件

[root@server1 utils]# vim /etc/redis/6379.conf 

70    bind 0.0.0.0             #将70行的bind这行改掉，监听所有IP网段

（2）修改完配置文件后，重启redis服务（因为执行完./install_server.sh脚本之后，redis服务已经开启，所以这里是重启redis服务，而不是开启redis服务）

[root@server1 utils]# /etc/init.d/redis_6379 restart

至此redis的配置也就完成了。此时再次查看redis的端口信息，可以看到，redis监控的端口信息是0.0.0.0:6379和127.0.0.1:6379，而并不再只是127.0.0.1:6379。

2.配置server3（从机）：

<1>安装redis，安装过程同server4

或者直接将server4上安装好的目录发送给server3，然后再在server3上执行剩下的操作，过程如下：

（1）将server4上安装好的目录发送给server3：

[root@server1 ~]# scp -r redis-5.0.6 server2:/root/

（2）在server2上执行剩下的操作：

 [root@server2 ~]# ls
redis-5.0.6
[root@server2 ~]# cd redis-5.0.6/
[root@server2 redis-5.0.6]# make install

<2>配置redis

（1）修改配置文件

  [root@server2 utils]# vim /etc/redis/6379.conf
    
    bind 0.0.0.0            #将70行的bind这行改掉，监听所有IP网段
    slaveof 172.25.254.1 6379       #在配置文件的最后一行指定主机的IP和端口（slaveof IP port做一主多从就在每台从机的配置文件中加上这行参数即可）

<3>重启redis服务

修改完配置文件后，重启redis服务（因为执行完./install_server.sh脚本之后，redis服务已经开启，所以这里是重启redis服务，而不是开启redis服务）

[root@server2 utils]# /etc/init.d/redis_6379 restart

3.测试：

<1>主机设定key-value

在server1：

[root@server1 utils]# redis-cli 
127.0.0.1:6379> set name dd
OK
127.0.0.1:6379> get name
"dd"

可以设定键和value，那么当然也可以删除键及其对应的value。对应的命令就是"del name"

<2>查看从机能否获取到value值

 [root@server2 utils]# redis-cli 
127.0.0.1:6379> get name
"dd"

结论：

在主机设定的key-value，在从机可以看到，表示redis的主从配置成功。

值的注意的是：从库默认是只读的，是不可以写的。

但是从机并不能写入：

三.Redis的高可用

Redis Sentinel是Redis官方的高可用性解决方案。

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 可以在启动一个普通 Redis 服务器时通过给定 - -sentinel 选项来启动 Redis Sentinel 。

---

Redis 的 Sentinel 中关于下线（down）有两个不同的概念：
主观下线（Subjectively Down， 简称 SDOWN) 指的是单个 Sentinel 实例对服务器做出的下线判断。
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 在 master-down-after-milliseconds 毫秒内一直返回无效回复， 那么 Sentinel 就会将这个服务器标记为主观下线。

客观下线（Objectively Down， 简称 ODOWN) 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就会被移除。客观下线条件只适用于主服务器。

只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

实验环境：
server1(主服务器)：192.168.43.10，安装有redis
server2(从服务器)：192.168.43.20，安装有redis
server3(从服务器)：192.168.43.30，安装有redis

实验步骤：
1.server1与server2、server3的Redis已打开，并在server2/3中配置主从复制

vim /etc/redis/6379.conf
/etc/init.d/redis_6379 restart

---

2.在server1/2/3中编辑sentinel配置文件开启哨兵
cp /soft/redis-5.0.3/sentinel.conf /etc/redis/
vim /etc/redis/sentinel.conf

protected-mode no

sentinel monitor mymaster 192.168.43.10 6379 2

sentinel down-after-milliseconds mymaster 10000

redis-server /etc/redis/sentinel.conf --sentinel启动一个运行在 Sentinel 模式下的 Redis 服务器

---

redis-cli在server1中查看哨兵的状态

127.0.0.1:6379> info ##注意：默认连接6379

127.0.0.1:26379> info

redis-cli -p 26379在server1中查看哨兵的状态

---

3.测试
在server1中

在server2中

redis-cli

127.0.0.1:6379> info

---

再次启动server1
/etc/init.d/redis_6379 start

四,redis集群

 

四.redis cluster集群的介绍

1.redis使用中遇到的瓶颈

我们日常在对于redis的使用中，经常会遇到一些问题

　　1、容量问题，单实例redis内存无法无限扩充，达到32G后就进入了64位世界，性能下降。

　　2、并发性能问题，redis号称单实例10万并发，但也是有尽头的。

2.redis-cluster的优势

1、官方推荐，毋庸置疑。

2、去中心化，集群最大可增加1000个节点，性能随节点增加而线性扩展。

3、管理方便，后续可自行增加或摘除节点，移动分槽等等。

4、简单，易上手。

3.redis-cluster名词介绍

1、master　　主节点、

2、slave　　　从节点

3、slot　　　　槽，一共有16384数据分槽，分布在集群的所有主节点中。

4.redis-cluster的设计

Redis集群搭建的方式有多种，例如使用zookeeper等，但从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有 节点连接。其redis-cluster架构图如下：

图中描述的是六个redis实例构成的集群

• 6379端口为客户端通讯端口

• 16379端口为集群总线端口

• 集群内部划分为16384个数据分槽，分布在三个主redis中。

• 从redis中没有分槽，不会参与集群投票，也不会帮忙加快读取数据，仅仅作为主机的备份。

• 三个主节点中平均分布着16384数据分槽的三分之一，每个节点中不会存有有重复数据，仅仅有自己的从机帮忙冗余。

  其结构特点：

1. 所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽。
2. 节点的fail是通过集群中超过半数的节点检测失效时才生效。
3. 客户端与redis节点直连，不需要中间proxy层。客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
4. redis-cluster把所有的物理节点映射到[0-16383]slot上，cluster 负责维护node<->slot<->value。
5. Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。

5.redis cluster节点分配

假设我们现在有三个主节点，分别是：A, B, C 三个节点，它们可以是一台机器上的三个端口，也可以是三台不同的服务器。那么，采用哈希槽 (hash slot)的方式来分配16384个slot 的话，它们三个节点分别承担的slot 区间是：

节点A覆盖0－5460；
节点B覆盖5461－10922；
节点C覆盖10923－16383。

获取数据：

如果存入一个值，按照redis cluster哈希槽的算法： CRC16(‘key’)%16384 = 6782。 那么就会把这个key
的存储分配到 B
上了。同样，当我连接(A，B，C)任何一个节点想获取’key’这个key时，也会这样的算法，然后内部跳转到B节点上获取数据。

新增一个主节点：

新增一个节点D，redis
cluster的这种做法是从各个节点的前面各拿取一部分slot到D上，我会在接下来的实践中实验。大致就会变成这样：

    节点A覆盖1365-5460
    节点B覆盖6827-10922
    节点C覆盖12288-16383
    节点D覆盖0-1364,5461-6826,10923-12287

同样删除一个节点也是类似，移动完成后就可以删除这个节点了。

6.Redis Cluster主从模式

redis cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。

上面那个例子里，集群有ABC三个主节点,，如果这3个节点都没有加入从节点，如果B挂掉了，我们就无法访问整个集群了。A和C的slot也无法访问。

所以我们在集群建立的时候，一定要为每个主节点都添加了从节点， 比如像这样,，集群包含主节点A、B、C,，以及从节点A1、B1、C1，那么即使B挂掉系统也可以继续正确工作。

B1节点替代了B节点，所以Redis集群将会选择B1节点作为新的主节点，集群将会继续正确地提供服务。 当B重新开启后，它就会变成B1的从节点。

不过需要注意，如果节点B和B1同时挂了，Redis集群就无法继续正确地提供服务了。

实验环境： server1有redis，实现一台主机多个实例

实验步骤：
1.建立新目录， 并创建六个以端口号为名字的子目录，在将每个目录中运行一个 Redis 实例
mkdir /usr/local/rediscluster/建立新目录
mkdir /usr/local/rediscluster/700{1..6}创建以端口号为名字的子目录

vim /usr/local/rediscluster/7001对每个目录中运行一个 Redis 实例

port                     7001
cluster-enabled          yes
cluster-config-file      nodes.conf
cluster-node-timeout     5000
appendonly               yes
pidfile                  "/usr/local/rediscluster/7001/redis.pid"
logfile                  "/usr/local/rediscluster/7001/redis.log"
daemonize                yes
dir                      "/usr/local/rediscluster/7001"

redis-server /usr/local/rediscluster/7006/redis.conf运行实例

---

[root@server1 rediscluster]# redis-cli -p 7001
127.0.0.1:7001> info

---

2.搭建集群
redis-cli --cluster create --cluster-replicas 1 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 127.0.0.1:7006 为集群中的每个主节点创建一个从节点

---

3.测试：
redis-cli -c -p 7001

---

挂掉主服务器7002

---

挂掉从服务器7004（已升级为主服务器）

---

4.3 集群重新分片

实验环境：在上一个实验的基础上
Redis 集群的数据分片
Redis 集群引入了 哈希槽的概念.
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,如当前集群有3个节点,那么:
节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可.由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

实验步骤：
1.建立新的节点

---

2. 添加节点到集群中
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001将7007加入集群
redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7007 --cluster-slave --cluster-master-id 0e011691bd77276feadd91c6316eb79717bb7043将7008加入集群，并作为7007的slave

---

3.分配hash槽

3.1 分配指定数量hash槽
redis-cli --cluster reshard 127.0.0.1:7001

redis-cli --cluster check 127.0.0.1:7001

3.2 平均分配hash槽
redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 127.0.0.1:7001