一、resis的持久化
1、什么是持久化
----把内存中的数据持久化到磁盘。这个过程就是持久化。 当redis启动时会从磁盘上读取数据并加载到内存。
2、持久化的优点
----防止数据丢失,当redis宕机时能够完整的保存数据
3、redis持久化的方式
(1)RDB:以快照的方式进行持久化。 在一定时间间隔内进行快照。把数据进行保存到磁盘。
(2)AOF:会把每次对redis的写操作命令追加到一个日志尾,当redis启动时则把该日志中的命令执行一遍.
4、RDB的持久化方式
(1)RDB是由save命令和bgsave命令触发的,在配置文件中有默认是触发条件,如果有需要,可以手改修改。
(2)save和bgsave的区别
----在执行save命令期间,redis不能处理其他命令,直到RDB过程执行完为止,执行完成后如果存在旧的RDB文件,则会被新的替代.而redis可能会有大量的客户端发送命令,让几万甚至更多的命令在等待显然是不可取的。
----而bgsave在执行该命令时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求,避免了redis其他命令等待的问题。
(3)rdb持久化方式的特点
优点:
----RDB文件紧凑,全量备份,非常适合用于进行备份和灾难恢复。
----bgsave生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程 不需要进行任何磁盘IO操作。
-----RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
缺点:
----快照持久化期间修改的数据不会被保存,可能丢失数据。数据完整性比较差。
5、AOF的持久化方式
(1) AOF是一种更加高效的方式,工作机制很简单,redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。AOF默认不开启,需要配置手动开启。如下图
AOF的触发规则如下图:
开启appendonly后,当进行写操作时会把命令放入appendonly.aof文件中
(2)AOF持久化方式的特点
优点:
----AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync 操作,最多丢失1秒钟的数据。
----AOF日志文件没有任何磁盘寻址的开销,写入性能非常高,文件不容易破损。
----AOF日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写
缺点:
----对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大.
----恢复数据时时间要比快照模式慢很多。
6、redis的集群
(1)搭建redis集群的原因:
----单个redis存在不稳定性。当redis服务宕机了,就没有可用的服务了。
----单个redis的读写能力是有限的。
----搭建集群,通过添加服务器的数量,提供相同的服务,从而让服务器达到一个稳定、
高效的状态。
(2)redis的主从关系
创建一个主节点和多个从节点,主从节点的数据是同步的,主节点可以实现读和写
操作,从节点只负责读操作。
(3)搭建主从关系
准备三台机器 (1 主节点 2 从节点 3从节点) 为了节省资源, 在一个虚拟机上启动 三台redis ,只是他们的端口号不同,
配从不配主
----配置redis配置文件,修改三个redist的端口号, 6380(主) 6381(从) 6382(从)
----修改rdb持久化文件的路径以及端口
复制创建三个文件,如下图,分别为redis6380 6381 6382,
分别启动80 81 82
启动成功后,连接不同的redis服务,端口号改变后连接redis命令如下
三台redis连接完毕,用info replication命令查看redis服务的关系
在没有三台redis设置之前可以看到他们之间是没有主从关系的,想要分别主从关系,需要进行如下的操作。
如上图,不改变6380,改变81和82,然后再查看三台redis的主从关系。可以发现81和82都变成了从,以80为主,80亦显示拥有两个从。
测试:
通过kill杀死主节点,然后查看从节点,发现从节点无法变成主节点
通过测试我们知道 主节点可以负责读写操作,但是从节点只能负责读操作。如果主节点宕机 ,则从节点无法变成主节点,导致客户端无法进行写操作了,有很大的局限性。因此便有哨兵模式
(4)搭建哨兵模式
----因为从节点上备份了主节点的所有数据,那在主节点宕机的情况下,如果能够将从节点
变成一个主节点,那么就可以解决整个集群没有可写的节点的缺点,这就是哨兵模式
----设置哨兵模式,修改sentinel.conf文件
修改后的哨兵文件,监视主节点6380,只要有一个哨兵认为主节点宕机了,就可以重新选择主节点。
启动哨兵,可以看到哨兵已经起到监视作用,显示6380为主节点,81、82为从节点。
杀死6380的redis进程,使主节点6380宕机
哨兵及时监视到主节点宕机了,随机选择6381为新的主节点。
通过查看,6381变成了主master,显示一个从节点,6382的主节点变成了6381。
重启之前的主节点6380,发现它并没有重新变为主节点,而是成了从节点。已6381为主
(5)redis集群搭建---去中心化
主从关系和哨兵模式虽然解决了部分问题,但是都没有解决并发量高的情况
配置三个主三个从
7001 7002 8001 8002 9001 9002
复制修改六个.conf文件
port 8001
bind 0.0.0.0
daemonize yes
appendonly yes 必须有aof持久化
# 开启集群
cluster-enabled yes
# 集群的配置文件,该文件自动生成
cluster-config-file nodes-8001.conf
# 集群的超时时间
cluster-node-timeout 5000
启动三主三从
为上面这些redis分配主从关系以及槽。必须保证aof开启,保证redis中没有数据
redis-cli --cluster create --cluster-replicas 1 192.168.125.3:7001 192.168.125.3:8001 192.168.125.3:9001 192.168.125.3:7002 192.168.125.3:8002 192.168.125.3:9002
客户端访问:
命令:redis-cli -c -h 127.0.0.1 -p 8001