本文主要是介绍Redis07：redis的主从复制（原理与哨兵模式）、集群（搭建与它的优缺点），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

Redis的主从复制

什么的主从复制

主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，slave以读为主

能干什么？

• 读写分离，性能扩展

• 容灾快速恢复（比如某个从机挂掉之后，能马上换一个从机）

怎么使用主从复制

1、创建一个myredis文件夹并进入

为了方便我就直接在根目录下创建该文件夹

[root@LJY /]# mkdir myredis
[root@LJY /]# cd myredis

2、复制redis.conf配置

[root@LJY myredis]# cp /etc/redis.conf /myredis/redis.conf   #表示把/etc/redis.conf的配置文件复制到/myredis/redis.conf 中，如果没有redis.conf它就会自动创建一个文件
[root@LJY myredis]# ls
redis.conf

首先进入我们复制的这个文件把appendonly 改为no

拷贝多个redis.conf文件include(写绝对路径)

然后去配置文件中稍作修改：

开启daemonize yes 后台运行

Pid文件名字pidfile

指定端口port

Log文件名字

dump.rdb名字dbfilename

Appendonly 关掉或者换名字

---

3、配置一主两从，创建三个配置文件

redis6379.conf

redis6380.conf

redis6381.conf

4、在三个配置文件中写入内容

然后就接着看下面具体编写步骤：

新建redis6379.conf，编写内容：

[root@LJY myredis]# vim redis6379.conf

include /myredis/redis.conf  #引入公共部分
pidfile /var/run/redis_6379.pid   #配置pid的位置
port 6379
dbfilename dump6379.rdb    #自定义rdb文件名字
#：wq						     #然后保存退出

然后以同样的方式新建6380 6381配置文件

新建redis6380.conf,编写内容：

include /myredis/redis.conf
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

新建redis6381.conf,编写内容：

include /myredis/redis.conf
pidfile /var/run/redis_6381pid
port 6381
dbfilename dump6381.rdb

slave-priority 10

设置从机的优先级，值越小，优先级越高，用于选举主机时使用。默认100

启动三台redis服务器

[root@LJY /]# cd myredis/
[root@LJY myredis]# ls
redis6379.conf  redis6380.conf  redis6381.conf  redis.conf
[root@LJY myredis]# redis-server redis6379.conf
[root@LJY myredis]# redis-server redis6380.conf
[root@LJY myredis]# redis-server redis6381.conf

查看系统进程，看看三台服务器是否启动

查看三台主机运行情况

info replication

连接6379的客户端

打印主从复制的相关信息

[root@LJY myredis]# redis-cli -p 6379

然后在打开两个窗口分别打开redis6380与6381

[root@LJY /]# cd /myredis
[root@LJY myredis]# ls
redis6379.conf  redis6380.conf  redis6381.conf  redis.conf
[root@LJY myredis]# redis-server redis6380.conf
[root@LJY myredis]# redis-cli -p 6380
127.0.0.1:6380> 
#81
[root@LJY myredis]# redis-server redis6381.conf
[root@LJY myredis]# redis-cli -p 6381

然后输入查看主机信息的命令info replication

127.0.0.1:6379> info replication
# Replication
role:master    #表示主机   
connected_slaves:0      #0个从机
master_failover_state:no-failover
master_replid:3e3102588d07ae841913a2718ba1d4c8eda0adaf
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

然后可以看到我们3个都是主机，接下来就是改变配置使得有主从

配从（库）不配主（库）

laveof <ip><port>

成为某个实例的从服务器

1、在6380和6381上执行:slaveof 127.0.0.1 6379

127.0.0.1:6380> slaveof 127.0.0.1 6379   #配置为6379的从机
OK

6380与6381都这样操作

然后查看6379里面的主机信息

2、在主机上写，在从机上可以读取数据

127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set a1 v1
OK

从机上读取（6380与6381）随机一个都可以

能读不能写

127.0.0.1:6380> keys *
1) "a1"
127.0.0.1:6380> set a2 v2
(error) READONLY You can't write against a read only replica.  
127.0.0.1:6380> 

3、主机挂掉，重启就行，一切如初

4、从机重启需重设：slaveof 127.0.0.1 6379

可以将配置增加到文件中。永久生效。

常用的三技能

一主二仆

切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的k1,k2,k3是否也可以复制？

如果我们使用中间从服务器挂掉了，主服务器还添加了数据，那么从服务器再一次练上来了，会自动更新数据，即便它挂掉了，再连接之后数据也会更新

从机是否可以写？set可否？

从机不能写，只能读

主机shutdown后情况如何？从机是上位还是原地待命？

主机挂掉后，从机就是原代待命，不会上位也不会叛变。

主机又回来了后，主机新增记录，从机还能否顺利复制？

能顺利复制

其中一台从机down后情况如何？依照原有它能跟上大部队吗？

能，再次连上后会更新数据

薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

就好比：我6379是6380的主服务器，然而6380又是6381的主服务器

这样做6379的从服务器只有6380一台

用slaveof <ip><port>

127.0.0.1:6381> slaveof 127.0.0.1 6380

中途变更转向:会清除之前的数据，重新建立拷贝最新的

缺点是一旦某个slave宕机，后面的slave都没法备份

主机挂了，从机还是从机，无法写数据了

反客为主（手动完成）

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

用 slaveof no one 将从机变为主机。

测试：6379挂掉了，6380上位

127.0.0.1:6380> slaveof no one
OK

这样就是6380变成主机了，如果前面的6381设置为6380的从机了 6381不变还是它的从机，只是6380可以进行写操作了

反客为主也有自动版，也就是接下来的哨兵模式。

---

复制原理

• slave启动成功连接到master后会发送一个sync命令
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

把上面的话简单理解就是：

1、当从服务器连上主服务器之后，从服务器向主服务器发送进行数据同步消息（从服务器主动的）

2、主服务器接到从服务器发送过来的同步消息，把主服务器数据进行持久化，rdb文件，再把rdb文件发送给从服务器，从我起拿到rdb进行读取

3、每次主服务器进行写操作之后，就会和从服务器进行数据的同步（主服务器主动做的）

哨兵模式（sentinel）

什么是哨兵模式

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

怎么设置哨兵模式？

调整为一主二仆的模式。

6379带着6380与6381

自定义的/myredis目录下新建sentinel.conf文件。（注意：名字不能错）

[root@LJY ~]# cd /myredis/
[root@LJY myredis]# vim sentinel.conf

注意点：文件名不能出错。

配置哨兵，编写配置文件

sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

sentinel monitor mymaster 127.0.0.1 6379 1
~   # 上面的1表示如果主机挂了，1个哨兵同意更换主机就更换。如果是2就要2个哨兵同意才可以换 

启动哨兵

我这里重新开了一个窗口

[root@LJY ~]#cd /myredis
[root@LJY myredis]# ls
dump6379.rdb  dump6380.rdb  dump6381.rdb  redis6379.conf  redis6380.conf  redis6381.conf  redis.conf  sentinel.conf
[root@LJY myredis]# redis-sentinel sentinel.conf     #启动哨兵

当主机挂掉了，从机选举中产生新的主机

(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)

哪个从机会被选举为主机呢？根据优先级别：slave-priority

原主机重启后会变为从机。

测试：

我们把主机挂掉

127.0.0.1:6379> shutdown 

然后过一会就能看见哨兵窗口有日志了。

6380就变成主服务器了，我们看6381的主机信息

---

我们在看6380的主机信息：

---

如果我们再打开主服务器6379它就不会再变成主服务器了，会变成从服务器了

缺点：复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

故障恢复

• 优先级在redis.conf中默认：replica-priority 100，值越小优先级越高；如果你的redis版本较低就输入slave-priority 100

• 如果replica-priority的值是相同的。就选择偏移量最大的。偏移量是指获得原主机数据最全的

• 如果前2个条件都一样。那么每个redis实例启动后都会随机生成一个40位的runid

主从复制

private static JedisSentinelPool jedisSentinelPool=null;

public static  Jedis getJedisFromSentinel(){
if(jedisSentinelPool==null){
            Set<String> sentinelSet=new HashSet<>();
            sentinelSet.add("192.168.31.249:26379");

            JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); //最大可用连接数
jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
jedisPoolConfig.setMinIdle(5); //最小闲置连接数
jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong

jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
return jedisSentinelPool.getResource();
        }else{
return jedisSentinelPool.getResource();
        }
}

Redis-集群

问题

容量不够，redis如何进行扩容？

并发写操作， redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

什么是集群

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

无中心化集群：

删除持久化数据

将rdb,aof文件都删除掉。

制作6个实例 6379 6380 6381 6389 6390 6391

6379主机6379从机

6380主机 6390从机

6381主机 6391从机

配置基本信息

我们就使用redis6379.conf作为标准来改

开启daemonize yes

Pid文件名字

指定端口

Log文件名字

Dump.rdb名字

Appendonly 关掉或者换名字

redis cluster配置修改

cluster-enabled yes 打开集群模式

cluster-config-file nodes-6379.conf 设定节点配置文件名

cluster-node-timeout 15000 设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

include /myredis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000

然后删除6380 6381

修改好redis6379.conf文件，然后拷贝多份

[root@LJY myredis]# cp redis6379.conf redis6380.conf
[root@LJY myredis]# cp redis6379.conf redis6381.conf
[root@LJY myredis]# cp redis6379.conf redis6389.conf
[root@LJY myredis]# cp redis6379.conf redis6390.conf
[root@LJY myredis]# cp redis6379.conf redis6391.conf

使用查找替换修改另外5个文件

例如：

  ：%s/6379/6380      #把6379换成6380    依次对应

启动6个reids服务

[root@LJY myredis]# redis-server redis6379.conf 
[root@LJY myredis]# redis-server redis6380.conf 
[root@LJY myredis]# redis-server redis6381.conf 
[root@LJY myredis]# redis-server redis6381.conf 
[root@LJY myredis]# redis-server redis6389.conf 
[root@LJY myredis]# redis-server redis6390.conf 
[root@LJY myredis]# redis-server redis6391.conf 

中间有个错的是配置文件我配置错了 我改了就Ok了

将6个节点合成一个集群

组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。

• 合体：
• cd /opt/redis-6.x.x/src (位置)

如果你是redis6以下的还在需要再去安装环境

如果是新版本中不需要再单独装环境了。 （redis6以上）

新版本中直接封装了帮我们装了。

[root@LJY /]# cd /opt    #因为我redis是安装在opt的
[root@LJY opt]# ls
containerd  redis-6.2.2  redis-6.2.2.tar.gz
[root@LJY opt]# cd redis-6.2.2/
[root@LJY redis-6.2.2]# cd src

然后直接输入命令： (要写自己的ip地址）

redis-cli --cluster create --cluster-replicas 1 192.168.31.249:6379 192.168.31.249:6380 192.168.31.249:6381 192.168.31.249:6389 192.168.31.249:6390 192.168.31.249:6391

此处不要用127.0.0.1， 请用真实IP地址

集群的搭建就完成了。

• 普通方式登陆（redis-cli -p 6379）

可能直接进入读主机，存储数据时，会出现MOVED重定向操作。所以，应该以集群方式登录。

-c 才用集群策略连接

设置数据会自动切换到相应的写主机

root@LJY src]# redis-cli -c -p 6379

通过cluster nodes命令查看集群信息

[root@LJY src]# redis-cli -c -p 6379    #集群方式启动

cluster nodes

redis cluster 是如何分配这6个节点？

一个集群至少要有三个主节点。

选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。

因为如果我主机挂掉了从机马上要上位，而主从在一个机器上，如果是机器挂了那么主从挂了。

slots是什么？

[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

[OK] All 16384 slots covered.

一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，

集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：

节点 A 负责处理 0 号至 5460 号插槽。

节点 B 负责处理 5461 号至 10922 号插槽。

节点 C 负责处理 10923 号至 16383 号插槽。

使用公式 CRC16(key) % 16384

在集群中录入值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。

redis-cli客户端提供了 –c 参数实现自动重定向。

如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

不在一个slot下的键值，是不能使用mget,mset等多键操作。

192.168.31.249:6379> mset name ljy age 20 address china
(error) CROSSSLOT Keys in request don't hash to the same slot

因为不能分辨出来是一组。

可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。

192.168.31.249:6379> mset name{user} ljy age{user} 20
-> Redirected to slot [5474] located at 192.168.31.249:6380
OK

查询集群中的值

CLUSTER GETKEYSINSLOT <slot><count> 返回 count 个 slot 槽中的键。

127.0.0.1:6379> keys *
1) "k2"
127.0.0.1:6379> cluster keyslot k1
(integer) 12706
127.0.0.1:6379> cluster countkeysinslot 12706   #因为12706不在6379里
(integer) 0
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> cluster keyslot 449
(integer) 14158
127.0.0.1:6379> cluster countkeysinslot 449
(integer) 1
127.0.0.1:6379> cluster getkeysinslot 449 1
1) "k2"

故障恢复

如果主节点下线？从节点能否自动升为主节点？注意：15秒超时

然后开一个窗口在把6379打开

6379就变从机了。

如果所有某一段插槽的主从节点都宕掉，redis服务是否还能继续?

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉

如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。

redis.conf中的参数 cluster-require-full-coverage

集群的Jedis开发

即使连接的不是主机，集群会自动切换主机存储。主机写，从机读。

无中心化主从集群。无论从哪台主机写的数据，其他主机上都能读到数据。

首先导包

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>3.5.0</version>
</dependency>

public class RedisClusterDemo {
    public static void main(String[] args) {
        HostAndPort hostAndPort = new HostAndPort("192.168.31.249", 6379);
        JedisCluster jedisCluster = new JedisCluster(hostAndPort);

        //进行操作
        jedisCluster.set("b1", "v1");
        String b1 = jedisCluster.get("b1");
        System.out.println(b1);
        jedisCluster.close();
    }
}

Redis集群提供的好处：

实现扩容

分摊压力

无中心配置相对简单

Redis集群的不足

多键操作是不被支持的

多键的Redis事务是不被支持的。lua脚本不被支持

由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

这篇关于Redis07：redis的主从复制（原理与哨兵模式）、集群（搭建与它的优缺点）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！