【微服务】第30节： Redis的主从集群结构

IT领域往往都是面试造火箭，实际工作拧螺丝。为了更好的应对面试，让大家能拿到更高的offer✉，我们接下来就讲讲“造火箭”的事情🧑‍🚀。

🔥🔥🔥 包括以下几方面🔽 🎈：

🌈 - Redis - 高级：

📛 -Redis主从（◀️）

🤿 - Redis哨兵

🧩 - Redis分片集群

👨‍💻 - Redis数据结构

♻️ - Redis内存回收

✅ - Redis缓存一致性

1.Redis主从

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

1.1.主从集群结构

下图就是一个简单的Redis主从集群结构：

如图所示，集群中有一个master节点、两个slave节点（现在叫replica）。当我们通过Redis的Java客户端访问主从集群时，应该做好路由：

💠如果是写操作，应该访问master节点，master会自动将数据同步给两个slave节点
💠如果是读操作，建议访问各个slave节点，从而分担并发压力

1.2.搭建主从集群

我们会在同一个虚拟机中利用3个Docker容器来搭建主从集群，容器信息如下：

容器名	角色	IP	映射端口
r1	master	192.168.150.101	7001
r2	slave	192.168.150.101	7002
r3	slave	192.168.150.101	7003

1.2.1.启动多个Redis实例

利用资料提供的docker-compose文件来构建主从集群：

文件内容如下：

version: "3.2"

services:
  r1:
    image: redis
    container_name: r1
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7001"]
  r2:
    image: redis
    container_name: r2
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7002"]
  r3:
    image: redis
    container_name: r3
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7003"]

将其上传至虚拟机的/root/redis目录下：

执行命令，运行集群：

docker compose up -d

结果：

查看docker容器，发现都正常启动了：

由于采用的是host模式，我们看不到端口映射。不过能直接在宿主机通过ps命令查看到Redis进程：

1.2.2.建立集群

虽然我们启动了3个Redis实例，但是它们并没有形成主从关系。我们需要通过命令来配置主从关系

# Redis5.0以前
slaveof <masterip> <masterport>
# Redis5.0以后
replicaof <masterip> <masterport>

有临时和永久两种模式：

🔹永久生效：在redis.conf文件中利用slaveof命令指定master节点
🔹 临时生效：直接利用redis-cli控制台输入slaveof命令，指定master节点

我们测试临时模式，首先连接r2，让其以r1为master

# 连接r2
docker exec -it r2 redis-cli -p 7002
# 认r1主，也就是7001
slaveof 192.168.150.101 7001

然后连接r3，让其以r1为master

# 连接r3
docker exec -it r3 redis-cli -p 7003
# 认r1主，也就是7001
slaveof 192.168.150.101 7001

然后连接r1，查看集群状态：

# 连接r1
docker exec -it r1 redis-cli -p 7001
# 查看集群状态
info replication

结果如下：

127.0.0.1:7001> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.150.101,port=7002,state=online,offset=140,lag=1
slave1:ip=192.168.150.101,port=7003,state=online,offset=140,lag=1
master_failover_state:no-failover
master_replid:16d90568498908b322178ca12078114e6c518b86
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:140
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:140

可以看到，当前节点r1:7001的角色是master，有两个slave与其连接：

🔹slave0：port是7002，也就是r2节点
🔹slave1：port是7003，也就是r3节点

1.2.3.测试

依次在r1、r2、r3节点上执行下面命令：

set num 123

get num

你会发现，只有在r1这个节点上可以执行set命令（写操作），其它两个节点只能执行get命令（读操作）。也就是说读写操作已经分离了。

1.3.主从同步原理

在刚才的主从测试中，我们发现r1上写入Redis的数据，在r2和r3上也能看到，这说明主从之间确实完成了数据同步。

那么这个同步是如何完成的呢？

1.3.1.全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：

这里有一个问题，master如何得知salve是否是第一次来同步呢？？

有几个概念，可以作为判断依据：

🔹Replication Id：简称replid，是数据集的标记，replid一致则是同一数据集。每个master都有唯一的replid，slave则会继承master节点的replid

🔹 offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。