Redis专题(六)：Redis主从复制、哨兵搭建以及原理

安装redis：Rdis专题目录

搭建步骤

1. 复制 redis.conf文件 => redis-6380.conf 。
2. 将上述复制的文件修改如下配置：
   a. 端口号：port 6380
   b. pidfile /var/run/redis_6380.pid #吧pid进程号写入pidfile配置的文件
   c. logfile “6380.log”
   d. dir /usr/local/redis/data/6380 #指定数据存放目录
3. 配置主从复制
   a. replicaof 127.0.0.1 6379 #从本机6379的redis实例复制数据.redis5.0之前使用slaveof
   b. replica-read-only yes #配置从节点只读
4. 启动从节点
   a. /opt/redis/redis-7.0.5/src/redis-server /opt/redis/redis-7.0.5/redis-6380.conf

我们查看一下进程
ps -ef | grep redis

我们在分别连接6379以及6380客户端
/opt/redis/redis-7.0.5/src/redis-cli -p 6379

/opt/redis/redis-7.0.5/src/redis-cli -p 6380

主从复制基本原理

全量复制

1.当从节点6380节点启动之后，会向主节点发送 psync命令同步数据，发送命令之前会会master节点建立socket连接。
2.
- 主节点收到 psync命令直线bgsave生成最新rdb快照数据
- 主节点开始做rbd之后新数据的缓存，一些写命令。
3. 主节点 send rdb数据
4. 从节点清空老数据并加载主节点rdb
5. 主节点发送缓存数据 send buffer到从节点
6. 从节点执行 buffer 里的写命令到内存
7. 主节点通过socket长连接持续把写命令发送给从节点，保证主从数据一致性。

部分复制（断点续传）

如果上述主从从，如果此时我们slave节点宕机了很长一段时间，此时的master节点肯定写入了大量的数据，此时我们重新启动slave节点就不会进行全量复制，而是进行部分复制。

注意： 从上述描述中我们可以发现，从节点在建立连接的时候，主节点会进行一次 bgsave命令，如果此时有大量的从节点，我们会对主节点的服务器造成很大的压力，我们为了缓解这一情况（** 主从复制风暴** ）当存在多个从节点的时候，我们可以做如下设计来进行主从同步：

Redis管道（pipeline）

客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后在发送一次性读取服务的响应，这样可以极大降低多条命令执行的网络开销，管道执行多条命令的网络开销实际上只相当于一次执行的网络开销。需要注意到的是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗的内存也越多，所以并不是打包的命令越多越好。pipeline中发送的每个command都会被server立即执行，如果执行失败，将会子此后的响应中得到信息；也就是pipeline并不是表达“所有command都一起成功”的意思，管道中前面命令失败，后面命令不会有影响，继续执行，也就是说pipeline不具备原子性

如果存在这样的情况，当我们存在有大量的set命令需要去操作redis的时候我们应该怎么样去处理，Redis本身就是基于内存来实现的，一次set命令的消耗我们几乎可以忽略不计，但是如果存在大量的set命令的时候，我们大部分的时间就浪费了在建立连接的这个消耗上，此时我们可以通过管道来实现。

简单的可以的将管道理解为，一堆命令的集合，redis可以同时接收多个命令去操作：

 JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
 jedisPoolConfig.setMaxTotal(20);
 jedisPoolConfig.setMaxIdle(10);
 jedisPoolConfig.setMinIdle(5);

JedisPool jedisPool = new JedisPool(jedisPoolConfig, "127.0.0.1", 6379, 3000,null);

Jedis jedis = jedisPool.getResource();
for (int i = 0; i < 10; i++) {
 	pl.incr("num");
 	pl.set("zhangsan" + i, "zhangsan");
 }
List<Object> results = pl.syncAndReturnAll();

System.out.println(results)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

哨兵

在上述主从架构中，我们发现如果slave宕机了，并不会影响我们的使用，只需要将slave重启即可，如果我们master节点挂了怎么办，此时我们就无法使用了，就需要运维来参与进来了。

sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监听redis实例节点。
哨兵架构下client端第一次从哨兵找出redis节点，后续就直接访问redis的主节点，不会每次通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现订阅功能，订阅sentinel发布的节点变动消息)。

搭建步骤

1. 复制一份 sentinel.conf文件：cp sentinel.conf sentinel-26379.conf
2. 将复制的文件更改如下：

port 26379
daemonize yes
pidfile “/var/run/redis-sentinel-26379.conf”
logfile "26379.log"
dir "/usr/local/redis/data"
#sentinel monitor    
#quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 +1)，master才算真正失效
#mymaster这个名字随便取，客户端访问时会用
sentinel monitor mymaster 127.0.0.1 6379 2 
1
2
3
4
5
6
7
8
9

3. 启动哨兵实例:./src/redis-sentinel sentinel-26379.conf
4. 查看sentinel的info信息

./src/redis-cli -p 26379
127.0.0.1:26379>info
1
2

5. 此时可以看到sentinel的info里已经识别出了redis的主从。
6. 我们可以在配置两个sentinel，端口26380和26381，注意上述配置文件里的对应数字都需要改。

info: info查看redis服务运行信息，分为9大块，每个快都有非常多的参数，这9个快分别为：

• Server：服务器运行的环境参数
• Clients：客户端相关信息
• Memory：服务器运行内存统计数据
• Persistence 持久化信息
• State：通用统计数据
• Replication：主从复制相关信息
• CPU：cpu使用情况
• Cluster：集群信息
• KeySpace：键值对统计数值信息

---

sentinel集群都启动完毕后，会将哨兵集群的元数据写入所有sentinel的配置文件里去(追加在配置文件末尾)，我们看如下
cat ./sentinel-26379.conf

当redis主节点挂了，哨兵集群会重新选举出新的redis主节点，同时会修改所以sentinel节点配置文件的集群元数据信息，比如6379的redis节点挂了，假设选举出的新的节点是6380，则sentinel文件里的集群元数据信息会变成如下：

同时还会修改配置的 mymaster对应的6379端口为6380：

当6379重新启动时，哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群。

Springboot连接哨兵

<dependency>
   <groupId>org.springframework.bootgroupId>
   <artifactId>spring-boot-starter-data-redisartifactId>
dependency>

<dependency>
   <groupId>org.apache.commonsgroupId>
   <artifactId>commons-pool2artifactId>
dependency>
1
2
3
4
5
6
7
8
9

配置文件:

server:
  port: 8080

spring:
  redis:
    database: 0
    timeout: 3000
    sentinel:    #哨兵模式
      master: mymaster #主服务器所在集群名称
     nodes: 127.0.0.1:26379,127.0.0.1:26380,127.0.0.1:26381
   lettuce:
      pool:
        max-idle: 50
        min-idle: 10
        max-active: 100
        max-wait: 1000
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@RestController
public class IndexController {

    private static final Logger logger = LoggerFactory.getLogger(IndexController.class);

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    /**
     * 测试节点挂了哨兵重新选举新的master节点，客户端是否能动态感知到
     * 新的master选举出来后，哨兵会把消息发布出去，客户端实际上是实现了一个消息监听机制，
     * 当哨兵把新master的消息发布出去，客户端会立马感知到新master的信息，从而动态切换访问的masterip
     *
     * @throws InterruptedException
     */
    @RequestMapping("/test_sentinel")
    public void testSentinel() throws InterruptedException {
        int i = 1;
        while (true){
            try {
                stringRedisTemplate.opsForValue().set("zhangsan"+i, i+"");
                System.out.println("设置key："+ "zhangsan" + i);
                i++;
                Thread.sleep(1000);
            }catch (Exception e){
                logger.error("错误：", e);
            }
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30