4.1 Centos7 安装redis6.X

学习目标

• 在Centos中安装redis
• 配置Redis主从
• 配置Redis哨兵集群
• 使用RedisTemplate连接Redis哨兵集群

1. 安装redis依赖

安装redis之前，先安装redis依赖
yum -y install gcc gcc-c++ make tcl
结果：

编译安装需要gcc5.3以上，可以用gcc -v 命令查看当前版本号
使用下面的命令升级到gcc9.1
yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils

scl enable devtoolset-9 bash
#scl命令启用只是临时的，新开的会话默认还是原gcc版本。
#如果要长期使用gcc 9.1的话执行下面的命令即可：
echo -e “\nsource /opt/rh/devtoolset-9/enable” >>/etc/profile

2. 安装Redis

下载安装包 redis-6.2.6.tar.gz
官网地址：http://redis.io/download
所有版本：https://download.redis.io/releases/
下载地址：https://download.redis.io/releases/redis-6.2.6.tar.gz

创建文件夹
上传redsi的压缩文件到 /root/soft/redis，并解压：**tar -zvxf redis-6.2.6.tar.gz **
为了方便重新命名一下：mv redis-6.2.6 redis
切换到 redis 文件夹，执行：make
结果
然后执行：make test，这个时间比较长
执行安装命令：make install
执行：redis-server，启动redis
但是这样子发现redis并不是后台运行，如果要后台运行还要进行一些配置
这时候终止redis：ctrl + c

3. 简单配置

切换到 /root/soft/redis 目录，创建 db/6379 目录(存放redis持久化文件)
进入 src 文件夹，复制redis-server、redis-cli文件到 /root/soft/redis 目录(方便以后操作)
进入 /root/soft/redis/redis 文件夹，复制 redis.conf 文件到 /root/soft/redis 目录
最终结果：
编辑redis.conf文件

• daemonize yes (让redis后台运行)
• dir /root/soft/redis/db/6379 （存放redis的持久化文件）

切换到 /root/soft/redis 目录，执行：redis-server redis.conf
尝试用 redis-cli 连接
退出 redis-cli，使用 exit 命令

但这时候关闭redis，就只能：kill -9 进程号

4. Redis 主从

单节点的redis，并发能力是有上限的，要进一步提高，就需要搭建集群，读写分离

1. 准备

创建3个文件夹：7001、7002、7003
复制 redis.conf 文件到 7001、7002、7003 文件夹，执行下面的命令

 echo 7001 7002 7003 | xargs -t -n 1 cp redis.conf

在 7001、7002、7003 下，分别建立 db 和 logs 目录

修改配置文件，以 7001 为示例（注意：并不是用下面的配置去整个替换redis.conf中的内容）

# 把192.168.56.103暴露出去，这样就可以通过这个ip连接redis
bind 192.168.56.103 127.0.0.1 -::1
# 端口
port 7001
# 进程文件
pidfile /var/run/redis_7001.pid
# 日志文件,需要提前建好logs文件夹
logfile /root/soft/redis/7001/logs/redis.log
# 持久化文件目录,需要提前建好db文件夹
dir /root/soft/redis/7001/db

# aof暂时关掉
appendonly no
# rdb也暂时恢复到默认配置

# 虚拟机有多个ip,为了避免混乱，方便主从通信，绑定一个ip
replica-announce-ip 192.168.56.103

7002 、7003 类似

2. 主从

让 7002、7003 作为 7001 的从节点
修改 7002 、7003 的配置文件

replicaof 192.168.56.103 7001
# 注意，redis 5.0之前的版本叫 slaveof

(注意：下面截图不用在意ip地址)

切换到 /root/soft/redis 目录，分别启动
可以看到启动成功3个 redis 实例

查看集群状态

测试数据同步
在 7001 实例 设置一个key
在 7002 实例可以获取到这个key
而且，默认情况下，从节点不能写
对应的 配置

3. 数据同步机制

1. 第一次同步，全量同步

在 /root/soft/redis 目录下，创建 7004，内容同7002、7003
启动 7001后，启动7004
查看 7001 日志

15726:M 16 Jun 2022 23:58:54.577 * Ready to accept connections
                                  # 下面是启动7004后，7001的日志
                                  # 7004请求数据同步
15726:M 16 Jun 2022 23:59:25.227 * Replica 192.168.56.105:7004 asks for synchronization
                                  # 7004是第一次连接，所以请求全量同步
15726:M 16 Jun 2022 23:59:25.228 * Full resync requested by replica 192.168.56.105:7004
                                  # 创建：复制积压缓冲区，Mater只要有slave就会创建这个
15726:M 16 Jun 2022 23:59:25.228 * Replication backlog created, my new replication IDs are '70fd50d3011b7796ca452cac022f20d406e1e8a0' and '0000000000000000000000000000000000000000'
                                  # 执行 bgsave 生成 rdb 
15726:M 16 Jun 2022 23:59:25.228 * Starting BGSAVE for SYNC with target: disk
                                  # 启动一个后台线程生成rdb
15726:M 16 Jun 2022 23:59:25.229 * Background saving started by pid 16207
16207:C 16 Jun 2022 23:59:25.242 * DB saved on disk
16207:C 16 Jun 2022 23:59:25.243 * RDB: 4 MB of memory used by copy-on-write
15726:M 16 Jun 2022 23:59:25.315 * Background saving terminated with success
15726:M 16 Jun 2022 23:59:25.315 * Synchronization with replica 192.168.56.105:7004 succeeded

查看 7004 日志

16202:S 16 Jun 2022 23:59:25.226 * Ready to accept connections
                                  # 连接主节点
16202:S 16 Jun 2022 23:59:25.227 * Connecting to MASTER 192.168.56.105:7001
                                  # 开始数据同步
16202:S 16 Jun 2022 23:59:25.227 * MASTER <-> REPLICA sync started
16202:S 16 Jun 2022 23:59:25.227 * Non blocking connect for SYNC fired the event.
                                  # Mater已回复连接信息，可以进行数据同步
16202:S 16 Jun 2022 23:59:25.227 * Master replied to PING, replication can continue...
                                  # 不能进行增量同步
16202:S 16 Jun 2022 23:59:25.227 * Partial resynchronization not possible (no cached master)
                                  # 全量同步
16202:S 16 Jun 2022 23:59:25.229 * Full resync from master: 70fd50d3011b7796ca452cac022f20d406e1e8a0:0
16202:S 16 Jun 2022 23:59:25.316 * MASTER <-> REPLICA sync: receiving 175 bytes from master to disk
16202:S 16 Jun 2022 23:59:25.316 * MASTER <-> REPLICA sync: Flushing old data
16202:S 16 Jun 2022 23:59:25.316 * MASTER <-> REPLICA sync: Loading DB in memory
16202:S 16 Jun 2022 23:59:25.321 * Loading RDB produced by version 6.2.6
16202:S 16 Jun 2022 23:59:25.321 * RDB age 0 seconds
16202:S 16 Jun 2022 23:59:25.321 * RDB memory usage when created 1.83 Mb
16202:S 16 Jun 2022 23:59:25.321 # Done loading RDB, keys loaded: 0, keys expired: 0.
16202:S 16 Jun 2022 23:59:25.322 * MASTER <-> REPLICA sync: Finished with success

流程：
第一阶段

• slave 启动时，与 master 建立连接，并请求数据同步
  • slav建立连接时候会发送 runId 和 offset
    • offset：数据偏移量，第一次连接是-1，表示全量同步
    • runId ：master的唯一标示，redis 在启动的时候，都会为自己生成一个ID，第一次salve传“？”
• master 会判断这个 slave 是不是第一次连接
  • 是：会把offset 和 runId 发给 slave ，slave会保存这个信息

第二阶段

• 然后 master 生成一个rdb，发送给 slave，slave拿到后清空本地数据，加载rdb文件
• master 生成rdb的时候，正常接收客户端请求，会把命令记录到 replication_buffer 中（也叫复制缓冲区）

第三阶段

• master 发送 replication_buffer 中的命令 , slave接到后执行，全量同步完毕

2. 增量同步

一般情况下，当 slave 故障，重启后，会做增量同步
关闭 7004
使用 redis-cli 连接 7001，设置几个key
再次启动 7004 ，然后查看日志
7001

                                 # 关闭7004时，有这句输出 
15726:M 17 Jun 2022 01:10:45.448 # Connection with replica 192.168.56.105:7004 lost.
                                 # 执行set命令时，生成了rdb文件
15726:M 17 Jun 2022 01:13:07.166 * 1 changes in 3600 seconds. Saving...
15726:M 17 Jun 2022 01:13:07.168 * Background saving started by pid 18474
18474:C 17 Jun 2022 01:13:07.272 * DB saved on disk
18474:C 17 Jun 2022 01:13:07.274 * RDB: 6 MB of memory used by copy-on-write
15726:M 17 Jun 2022 01:13:07.371 * Background saving terminated with success
                                 # 7004 请求数据同步
15726:M 17 Jun 2022 01:18:27.830 * Replica 192.168.56.105:7004 asks for synchronization
                                 # 接受同步请求，发送数据   
15726:M 17 Jun 2022 01:18:27.830 * Partial resynchronization request from 192.168.56.105:7004 accepted. Sending 5950 bytes of backlog starting from offset 1.

7004

23322:S 17 Jun 2022 01:18:27.830 * Ready to accept connections
23322:S 17 Jun 2022 01:18:27.830 * Connecting to MASTER 192.168.56.105:7001
23322:S 17 Jun 2022 01:18:27.830 * MASTER <-> REPLICA sync started
23322:S 17 Jun 2022 01:18:27.830 * Non blocking connect for SYNC fired the event.
23322:S 17 Jun 2022 01:18:27.830 * Master replied to PING, replication can continue...
                                 # 请求增量同步
23322:S 17 Jun 2022 01:18:27.830 * Trying a partial resynchronization (request 70fd50d3011b7796ca452cac022f20d406e1e8a0:1).
23322:S 17 Jun 2022 01:18:27.830 * Successful partial resynchronization with master.
23322:S 17 Jun 2022 01:18:27.830 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.

主从正常同步的时候，master会把命令写到 replication_buffer（复制缓冲区） 中，
同时也会写在 replication_backlog_buffer 中（也叫：复制积压缓冲区，默认1M大小）

当 slave 断开，又重新连接的时候，master 会根据 offset ，从 repl_backlog 中获取增量数据给 slave
但是repl_backlog的大小有上限，写满后，新来的数据会覆盖最早的数据，如果 slave 断开时间太久，导致一部分数据还没有同步就被覆盖了，就只能最全量同步

5. Redis 哨兵

当主从集群下Master当宕机，Redis 的哨兵机制(Sentinel)会从Slave节点中选举一个新的Master
主要功能如下
（1）集群监控，负责监控redis master和slave是否正常工作
（2）故障转移，如果master node挂掉了，自动故障转移，从Slave节点中选举一个新的Master
（3）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
如果故障转移发生了，通知client客户端新的master地址
总结：Redis哨兵用来监控主从集群，当Master宕机时，从Slave中选举新的Master

1. 集群监控

哨兵是基于心跳机制监控集群状态，每秒向集群中的实例发送ping命令

• 如果某个哨兵节点发现某实例没在规定时间（down-after-milliseconds 配置）响应，
  则该实例：主观宕机(sdown)
• 如果指定数量(quorum)的哨兵都认为这个实例宕机，则该实例：客观宕机(odown)，quorum最好超过一半数量

上图中，一同有3个哨兵，其中2个都认为master宕机了，且quorum=2，那么这个master就是客观宕机，需要进行故障转移

2. 故障转移

一旦认为Master客观宕机，哨兵会在slave中选出一个最为新的Master，选举算法

• 判断跟Master断开连接的时长，超过了down-after-milliseconds的10倍，排除这个slave
• 判断salve的优先级，replica-priority属性(老版本是slave-priority)越低，优先级就越高
• 如果replica-priority相同，那么看replication offset，offset越大，优先级就越高
  • offset越大：数据越完整
• 如果上面两个条件都相同，那么选择一个 run id 比较小的
  • runid是启动redis时生成的，通过 info server 命令可以查看runid
  • 
  • 

一旦确定Master节点后，会选择一个哨兵节点，进行故障转移

• 给备选的slave发送 **slave no none **命令，让该节点成为Master
• 给其他slave节点发送 REPLICAOF(老版本是：slaveof) 命令，让这些slave成为新Master的从节点
• 给故障的节点标记为slave，当节点恢复后，会自动成为从节点


3. 搭建哨兵集群

1. 配置

在 /root/soft/redis 目录下创建 3 个 文件夹
在 s1 中 创建 sentinel.conf 文件，并添加下面内容

# 哨兵 监听端口，每个哨兵监听一个
port 27001
# 哨兵之间通信使用的ip地址
sentinel announce-ip 192.168.56.103
# 监控集群，格式：sentinel monitor <master name(可自定义)> <master ip> <master port> <quorum>
sentinel monitor mymaster 192.168.56.103 7001 2
# 主观判断指定时间内，节点是否宕机，单位：毫秒
sentinel down-after-milliseconds mymaster 5000
# 故障转移的超时时间，单位：毫秒,如果超时，再选一个slave进行切换
sentinel failover-timeout mymaster 60000
# 工作目录
dir "/root/soft/redis/s1"
# 密码配置，我没有设置密码
#sentinel auth-pass mymaster <password>


# 新的master切换之后，同时有多少个slave被切换到去连接新master，重新做同步
# sentinel parallel-syncs mymaster 1
# 假设1个master，4个slave，然后master宕机了，4个slave中有1个切换成了master，剩下3个slave就要挂到新的master上面去
# 这个时候，如果parallel-syncs是1，那么3个slave，一个一个，排序挂接到新的master上面去
# 如果parallel-syncs是3，那么一次性就会把所有slave挂接到新的master上去

s2、s3类似

启动哨兵：** redis-sentinel s1/sentinel.conf**，启动前要保证redis实例已经启动
哨兵启动后，会互相通信
s1
s2
s3

2. 测试

关闭 7001 主节点，从 3 个哨兵日志中，找到如下日志，我的是在s2中找到的
解释：

                                    主观认为 7001 宕机
24701:X 18 Apr 2022 22:48:18.502 # +sdown master mymaster 192.168.56.103 7001 
                                    客观认为 7001 宕机, 因为 quorum 2/2
24701:X 18 Apr 2022 22:48:18.603 # +odown master mymaster 192.168.56.103 7001 #quorum 2/2
                                    开始投票选出一个哨兵做故障转移，最终结果投票给 f5296605b9c786e377e4afb2fb93ded6094415e5
24701:X 18 Apr 2022 22:48:18.603 # +new-epoch 1
24701:X 18 Apr 2022 22:48:18.603 # +try-failover master mymaster 192.168.56.103 7001
                                    投票选出一个哨兵做故障转移
24701:X 18 Apr 2022 22:48:18.608 # +vote-for-leader f5296605b9c786e377e4afb2fb93ded6094415e5 1
24701:X 18 Apr 2022 22:48:18.617 # bf82c362a5d426a822d34327d5d1641683d683bc voted for f5296605b9c786e377e4afb2fb93ded6094415e5 1
24701:X 18 Apr 2022 22:48:18.618 # ed6cbda34457bf8d1f6e910e03362c6062a35061 voted for f5296605b9c786e377e4afb2fb93ded6094415e5 1
24701:X 18 Apr 2022 22:48:18.666 # +selected-leader master mymaster 192.168.56.103 7001
24701:X 18 Apr 2022 22:48:18.666 # +failover-state-select-slave master mymaster 192.168.56.103 7001                       
                                    从集群中选择一个作为新的master,最终选择了 7002
24701:X 18 Apr 2022 22:48:18.721 # +selected-slave slave 192.168.56.103:7002 192.168.56.103 7002 @ mymaster 192.168.56.103 7001
                                    给 7002 发送了noone命令，让它成为主节点，查看下方图1
24701:X 18 Apr 2022 22:48:18.721 * +failover-state-send-slaveof-noone slave 192.168.56.103:7002 192.168.56.103 7002 @ mymaster 192.168.56.103 7001
                                    等待其他的sentinel确认
24701:X 18 Apr 2022 22:48:18.798 * +failover-state-wait-promotion slave 192.168.56.103:7002 192.168.56.103 7002 @ mymaster 192.168.56.103 7001
                                    确认完成
24701:X 18 Apr 2022 22:48:19.719 # +promoted-slave slave 192.168.56.103:7002 192.168.56.103 7002 @ mymaster 192.168.56.103 7001
                                    重新配置7001，让其成为slave
24701:X 18 Apr 2022 22:48:19.719 # +failover-state-reconf-slaves master mymaster 192.168.56.103 7001
                                    通知7003 ，新的master是7002，查看下方图2
24701:X 18 Apr 2022 22:48:19.777 * +slave-reconf-sent slave 192.168.56.103:7003 192.168.56.103 7003 @ mymaster 192.168.56.103 7001
24701:X 18 Apr 2022 22:48:20.724 * +slave-reconf-inprog slave 192.168.56.103:7003 192.168.56.103 7003 @ mymaster 192.168.56.103 7001
24701:X 18 Apr 2022 22:48:20.724 * +slave-reconf-done slave 192.168.56.103:7003 192.168.56.103 7003 @ mymaster 192.168.56.103 7001
24701:X 18 Apr 2022 22:48:20.796 # -odown master mymaster 192.168.56.103 7001
24701:X 18 Apr 2022 22:48:20.796 # +failover-end master mymaster 192.168.56.103 7001         
                                    监控新的master
24701:X 18 Apr 2022 22:48:20.796 # +switch-master mymaster 192.168.56.103 7001 192.168.56.103 7002
                                    7003 和 7001 是 7002 的slave
24701:X 18 Apr 2022 22:48:20.796 * +slave slave 192.168.56.103:7003 192.168.56.103 7003 @ mymaster 192.168.56.103 7002
24701:X 18 Apr 2022 22:48:20.796 * +slave slave 192.168.56.103:7001 192.168.56.103 7001 @ mymaster 192.168.56.103 7002
24701:X 18 Apr 2022 22:48:25.853 # +sdown slave 192.168.56.103:7001 192.168.56.103 7001 @ mymaster 192.168.56.103 7002

图1:
图2:

这时候再次重启 7001 ，然后查看7002日志，发现7001请求同步数据
查看7001日志，作为一个slave，连接7002

4. redisTemplate

1. 创建一个普通的maven项目


2. pom.xml

<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.3.12.RELEASE</version>
</parent>

<dependencies>
  <dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
    <version>2.6.2</version>
  </dependency>
  <!-- spring data redis 测试 -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
  </dependency>

  <!-- spring boot 测试 -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

3. 启动类

@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class,args);
    }
}

4. properties

# master 名称
spring.redis.sentinel.master=mymaster
# 哨兵地址
spring.redis.sentinel.nodes[0]=192.168.56.105:27001
spring.redis.sentinel.nodes[1]=192.168.56.105:27002
spring.redis.sentinel.nodes[2]=192.168.56.105:27003

5. 配置类

@Configuration
public class RedisConfig {
    
    /**
    * 配置读写分离
    * @return
    */
    @Bean
    public LettuceClientConfigurationBuilderCustomizer configurationBuilderCustomizer(){
        return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
    }
}

代码中的 ReadFrom._REPLICA_PREFERRED _是redis的读取策略，有下面几种

• MASTER 从master读取
• MASTER_PREFERRED 优先 master 读取，master不可用，读 slave
• REPLICA 从 slave 读取
• REPLICA_PREFERRED 优先从 slave 读取，slave不可用，读master

6. Controller

@RestController
public class RedisController {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @GetMapping("/set")
    public String set(@RequestParam String key , @RequestParam String value){
        stringRedisTemplate.opsForValue().set(key, value);
        return "success";
    }

    @GetMapping("/get")
    public String get(@RequestParam String key){
        return stringRedisTemplate.opsForValue().get(key);
    }
}

正常访问，没问题，如果停掉Redis Master 节点，再次访问，也是正常的

5. 两种数据丢失

• 异步复制导致的数据丢失
  • 因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
• 脑裂导致的数据丢失
  • 脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着
  • 此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master
  • 这个时候，集群里就会有两个master，也就是所谓的脑裂
  • 虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了

优化，redis.conf中有两个配置：

• min-replicas-to-write 1
  • 写数据时，如果跟 master 正常同步的 slave 数量小于1，则 master 拒绝写入
  • 配置0，则关闭此功能
• min-slaves-max-lag 10
  • 主从库间进行数据复制时，从库给主库发送 ACK 消息的最大延迟，单位：秒
  • 如果大于10秒，则 master 拒绝写入

这两个配置可以有效避免数据的丢失