redis持久化

一:什么是持久化持久化就是将数据保存到我们的硬盘中,将数据保存到硬盘上的这个过程就是持久化。redis是一个内存数据库,数据保存在内存中,但是对于内存中的数据是很容易丢失的,当redis宕机的时候,数据就会丢失,所以持久化可以有效的防止数据的丢失。二:redis持久化的方式redis支持两种持久化的方式:RDB和AOFRDB:RDB其实就是把数据以快照的形式保存在磁盘上。我们可以将快照理解成把当前时刻的数据拍成一张照片保存下来。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
摘要由CSDN通过智能技术生成

一:什么是持久化

持久化就是将数据保存到我们的硬盘中,将数据保存到硬盘上的这个过程就是持久化。redis是一个内存数据库,数据保存在内存中,但是对于内存中的数据是很容易丢失的,当redis宕机的时候,数据就会丢失,所以持久化可以有效的防止数据的丢失。

二:redis持久化的方式

redis支持两种持久化的方式:RDB和AOF

RDB:RDB其实就是把数据以快照的形式保存在磁盘上。我们可以将快照理解成把当前时刻的数据拍成一张照片保存下来。RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

AOF:AOF的通俗理解就是一种日志记录,redis会将我们所有的写操作都存放到一个日志文件中,当redis运行的时候,会将这个日志文件中的所有指令都执行一遍。

三:RDB持久化方式

RDB方式是通过把某个时刻的所有数据生成一个快照来保存,那么就有触发机制,来实现这个过程。对于RDB来说,提供了三种机制:save、bgsave、自动化。

1.save机制

该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。也就是当一个客户端执行save指令的时候,会将redis阻塞,其他所有的客户端都不能进行任何的命令操作redis。

2.bgsave机制

执行该命令时,Redis会在后台执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。在这个阶段,其他客户端对redis发出的命令,redis可以进行执行。

因为bgsave不会对redis进行阻塞,所以基本上 redis 内部所有的RDB操作都是采用 bgsave 命令。

3.自动化机制

自动化机制其实是通过redis的配置文件:redis.conf中的配置进行实现的。在redis的配置文件中有一下一部分内容。

每3600秒内有一次对键的修改时,就会触发一次bgsave命令

4.redis的恢复数据

当redis的目录中有dump.rdb时,只要redis启动,就会读取dump.rdb中的数据,进行数据的加载

5.RDB持久化的优缺点

优势

1.RDB文件适合用于备份和进行数据的恢复

2.当使用bgsave的时候,可以不阻塞redis。是通过创建的子进程完成的写入操作,主线程不需要进行IO流的操作

3.RDB适合进行数据的恢复,当时数据量很大的时候,比AOF速度快的多,因为AOF中存的是一个个的命令,当恢复的时候,要将命令一个个执行。

缺点

当执行持久化操作的时候,如果有新的客户端进行对键的写操作,这个操作是不会被保存成快照的,这一部分的写操作就会丢失。

四:AOF持久化方式

AOF就是将所有的执行的命令都存入到一个文件中。redis默认是关闭AOF的,我们想要使用AOF进行持久化就需要将AOF开启,需要修改redis的配置文件。

1.AOF持久化触发的时机

AOF持久化触发的时机有三种

appendfsync always:总是触发,没当执行一次写的操作就会执行一次

appendfsync everysec:每隔一秒就会执行,默认是这个时机

appendfsync no:不进行触发

查看appendonly.aof

2.AOF的优缺点

优点

1.AOF可以更好的保证数据不会丢失,因为默认是每隔一秒就执行一次,所以最多就会丢失一秒的记录。

2.AOF日志文件没有磁盘寻址的开销,写入性能高,文件不易损坏。

3.AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。

缺点

1.相比于dump.rdb文件,appendonly.aof文件更大。

2.相比于rdb,恢复数据的速度慢。

五:redis的主从关系

因为对于数据库的操作而言,查询读取数据的次数是要大于写的次数的,所以,当只有一个redis的时候,如果读的请求过多,则会响应很慢,有一部分请求会被阻塞,只有当前面请求完成之后,才会进行被阻塞的请求。这个时候配置redis主从关系就可以解决这个问题,请求过多的时候,可以去对从redis进行请求。

1.创建三台redis

为了节省资源,我们可以在一台虚拟机上创建三台redis,因为redis的运行是依赖配置文件的,随意我们只需要创建三个不同的redis配置文件就可以,并且里面的redis端口号要不同。

使用命令,在redis根目录创建一个文件夹,用来存放三个redis的配置文件。

①先创建一个文件夹,将redis的配置文件移入到文件夹中

②将配置文件重命名

③将配置文件复制两份,并重命名,修改配置文件中的端口号

④运行三台nginx,并且查看redis进程

⑤查看三台redis的关系

info replication

发现现在三台redis的角色都是master,也就是说这三台redis都是主节点,并没有任何的关系。

⑥将6379这个端口的redis设置为主节点,6380和6381两台redis设置成从节点,然后再次查看redis之间的关系

设置主节点

slaveof 主节点的ip地址 主节点的端口号

当设置6379为主节点,6380和6381为从节点之后。只有主节点可以进行读写操作,从节点只能进行读的操作。并且如果再新增一个新的从节点之后,从节点的数据与主节点的数据一直,之前有的现在也有,以后有的更会存在

注意:在主从关系中,当主节点宕机了,从节点并不会变成主节点,并且仍然不具有写的操作,还是只能进行读。当主节点恢复之后,他还是主节点,并不会因为宕机而消失主节点的身份。

六:哨兵模式

因为主从关系中,主节点宕机后,就无法进行写的操作,只有主节点恢复之后才能进行写,这样显然是缺点,不合适的。所以就出现了哨兵模式,在哨兵模式中,会新增一个哨兵角色,当主节点宕机之后,会有哨兵从从节点当中选择一个变成主节点,其他从节点则会归属到这个新的主节点下。并且当原先的主节点恢复之后,他也会变这个新的主节点的从节点。

在哨兵模式中,重要的是sentinel.conf这个配置文件,里面指定了哨兵的个数,以及主节点的i信息。

①创建一个文件,将sentinel.conf拷贝到文件夹中,并进行修改。

因为现在只有一个哨兵,所以将最后的值改为1

②启动哨兵

redis-sentinel sentinel.conf

③将原本的6379端口号的主节点停掉,查看哨兵窗口,过一段时间后,会提示之前的主节点已经被某个从节点替换

④在6380端口中查看主从关系

⑤将之前的主节点3679启动,查看主从关系

七:redis集群

使用哨兵模式虽然解决了读的问题,但是并没有解决写的问题,因为只有主节点可以进行写,从节点只能进行读。所以当写的请求量很大的时候,还是需要进行等待。因此配置redis集群就可以解决读和写的问题,多个redis主节点配置成redis集群,然后一个redis主节点可以再配置哨兵模式,这样读和写的问题就都解决了。

当配置了redis集群后,会产生16384个槽,这些槽会被平均的分配到redis的主节点上。例如有四个redis主节点形成集群,就会将16384个槽平均分配到这个四个主节点上。

第一个redis主节点:0——4096

第二个redis主节点:4097——8192

第三个redis主节点:8193——12288

第四个redis主节点:12289——16384

对所有的写入操作,会执行一种crc16算法,会产生一个数字,使用这个数字对16384进行取余得到槽位,然后槽位在那个范围之内,这个key就会存入到那个redis的主节点上。

例如set k2 3 产生的数字是86295,则取余后的槽位就是4375,则这个k2就会存入到第二个redis主节点上。

①配置集群

配置一个三主一从的集群

主节点:6370   6380   6390

从节点    6371   6381   6391

②修改redis的配置文件redis.conf

要修改端口号、ip地址、AOF必须为开、开启集群、集群的配置文件、集群的超时间

port 6370
bind 0.0.0.0
daemonize yes
appendonly yes  必须有aof持久化
# 开启集群
cluster-enabled yes             833行
# 集群的配置文件,该文件自动生成   
cluster-config-file nodes-6370.conf  841行
# 集群的超时时间
cluster-node-timeout 5000         847行

创建一个新的文件夹,里面拷贝6个配置文件,分别修改他们的配置文件

③启动全部的redis

④为启动的redis设置主从关系以及槽

指令中的1表示一个主节点只携带一个从节点,前面三个是主节点,后面上是对应主节点的从节点,并且使用这个指令的时候,必须保证redis中没有任何的数据,并且AOF是开启的。

redis-cli --cluster create --cluster-replicas 1 192.168.116.29:6370 192.168.116.29:6380 192.168.116.29:6390  192.168.116.29:6371  192.168.116.29:6381 192.168.116.29:6391

⑤开启客户端,执行set指令,查看key存放到那个主节点上

redis-cli -c -h 127.0.0.1 -p 6370

执行之后会发现,crc16算法返回的值是12706,使用12706对16384取余获得的槽位是12706

6370:0-5461

6380:5462-10923

6390:10924-16394

12706在6390拥有的槽位里面,所以会给6390这个主节点,并且跳进6390这个端口

继续set k2 2 crc16算法返回的值是449,449对16384取余获取的槽位是449,所以就存在6370这个端口上,并且调回6370这个端口。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值