文章目录
摘要
摘要:Redis持久化;Redis哨兵;Redis主从集群;Redis分片集群;Redis插槽
1 单机的Redis存在四大问题
1.1 数据丢失问题
解决方案 | 实现Redis数据持久化 |
---|
持久化:由于Redis缓存存储在内存中,而内存不存储数据(内存读写快),磁盘存储数据(IO交互多,读写慢),我们需要将Redis存储在内存中数据持久化存储到磁盘中。
1.2 故障恢复问题
解决方案 | 利用Redis哨兵,实现健康检测和自动恢复 |
---|
1.3 并发能力问题
解决方案 | 搭建主从集群,实现读写分离 |
---|
1.4 存储能力问题
解决方案 | 搭建分片集群。利用插槽机制实现动态扩容 |
---|
2 数据丢失问题:Redis持久化解决RDB与AOF
2.1 RDB持久化
RDB
(Redis Database Backup file)(Redis数据备份文件):也称Redis数据快照
。把内存中的数据记录到磁盘中
。
当Redis实例故障重启,从磁盘读取快照文件(RDB文件
),恢复数据。默认保存在当前运行目录。
2.1.1 执行时机
执行时机 | 解释 | 测试 |
---|---|---|
执行save命令 | save命令会使主进程执行RDB,过程中其它命令都会被阻塞。只有在数据迁移时可能用到此命令 | |
执行bgsave命令 | 此命令可以异步执行RDB ,执行后开启独立进程 完成RDB,主进程可以持续处理用户请求,不受影响。 | |
停机时 | Redis停机时执行一次save命令,实现RDB持久化。 | |
触发RDB条件 | Redis内部有触发RDB机制,在redis.conf文件中修改 |
2.1.2 触发RDB条件及其他配置
Redis内部有触发RDB的机制,可以在redis.conf文件中找到,格式如下:
# 900秒内,如果至少有1个key被修改,则执行bgsave , 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB的其它配置也可以在redis.conf文件中设置,格式如下:
# 是否压缩 ,建议不开启,压缩也会消耗cpu,磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
2.1.3 RDB原理
RDB原理:首先,bgsave开始时fork主进程得到子进程,子进程共享主进程的存数据。其次,完成fork后读取内存数据并写入 RDB 文件。
fork采用copy-on-write技术
:
- 主进程执行读操作时,访问共享内存;
- 主进程执行写操作时,拷贝一份数据,执行写操作。
2.1.4 RDB方式bgsave的基本流程
首先,fork主进程得到一进程,共享内存空间,其次,子进程读取内存数据并写入新的RDB文件,最后,用新RDB文件替换旧的RDB文件。
2.1.5 RDB的缺点
- RDB执行间隔时间长(因为其要
保存一时刻redis缓存的所有快照
),两次RDB之间写入数据
有丢失风险
- fork子进程、压缩、写出RDB文件都比较耗时
2.2 AOF持久化
2.2.1 AOF原理
AOF(Append Only File)(追加文件):Redis处理的每个写命令都要记录在AOF文件(命令日志文件)。
2.2.2 AOF配置
2.2.2.1 AOF默认关闭,修改redis.conf配置文件开启AOF
# 是否开启AOF功能,默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
2.2.3 AOF命令记录频率三种策略
# 表示每执行一次写命令,立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区,然后表示每隔1秒将缓冲区数据写到AOF文件,是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区,由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
2.2.4 AOF文件重写
2.2.4.1 为什么进行重写:
因为AOF方式是记录命令的,因此会比RDB方式产生的文件大的多。**
2.2.4.2 重写的思路:
例如,对同一key的多此操作,只有最后一次才有意义,我们要做的就是减少此类操作中产生的垃圾命令。
2.2.4.3 实现:
执行
bgrewriteaof
命令,让AOF文件执行重写功能,用最少命令达到相同效果。
2.2.4.4 Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
2.3 RDB与AOF对比
3 并发能力问题:Redis主从
3.1 为什么要搭建Redis主从架构
单节点Redis并发能力有上限,如需提高并发能力,需搭建主从集群,实现读写分离。
3.1 搭建主从架构
3.2 主从数据同步原理
3.2.1 全量同步
主从数据同步原理:首先,主从第一次建立连接时,执行全量同步(将RDB文件通过网络传输给slave)
3.2.2 问题:master如何得知salve是第一次来连接呢?以及master如何判定此salve是自己的从节点?
答:salve做数据同步,首先,salve向master发送
自己原有的replid和offset
,当master发现slave发送来的replid与自己不一致
,说明这是全新slave
需要做全量同步
,然后,master
会将自己的replid和offset发送给slave
,slave保存这些信息。以后slave的replid就与master一致
,也判定此salve是自己的从节点。即:master判断某节点是否为第一次同步的:依据是
比较replid是否相同
。
名词 | 解释 |
---|---|
Replication Id (replid)(数据集标记) | id一致说明是同一数据集。每一个master都有唯一replid,slave会继承master节点replid |
offset (偏移量) | 随repl_baklog中数据增多而增大。slave完成同步时记录当前同步的offset。如slave的offset小于master的offset ,说明slave数据落后于master ,需要更新 。 |
3.2.3 增量同步
4 故障恢复问题:Redis哨兵
5 存储能力问题:Redis分片集群
6 master主节点复制为什么要用RDB为什么不用AOF?
答:理解错误,先是RDB,后是AOF,也就是说是RDB跟AOF结合使用
7 Redis插槽
7.1 Redis插槽是什么
Redis插槽:在Redis中一个Redis键值空间被分成16384个插槽,每个插槽可以存储一个键值对,每个Redis集群节点负责处理部分插槽,所有节点一起负责整个Redis键值空间。用来解决
数据分片
和负载均衡
问题。
7.2 Redis插槽作用
①
数据分片
:利用插槽将Redis键值空间划分为多部分,在不同节点存储不同数九,避免数据全部存储在单节点导致节点压力过大。
②负载均衡
:不同节点处理不同插槽,保证每个节点的负载均衡。
③处理节点故障
:若一个节点出现故障,其它节点可以负责处理该节点上负责的插槽,保障系统的高可用性。
④扩容缩容
:Redis集群可方便进行扩容和缩容,只需将插槽映射到新节点。
7.3 Redis插槽解决的问题
- ①
数据分片问题
:将数据按照指定规则分散到多个节点上,以达到提高性能、增加可靠性和利于扩展的目的,数据分片可以避免单节点处理所有数据的问题,因而降低单节点压力,数据分片可分为水平分片和垂直分片。- ②
负载均衡问题
:在分布式系统中,将负载平均分配到多个节点以提高系统的性能和可靠性,通过将请求分配到多节点上,因此避免单节点负载过高,保证整个分布式系统负载均衡,使得让系统吞吐量达到最大值。- ③
节点扩容问题
:节点扩容是将新节点加入到分布式系统中,以提高系统性能和可靠性,其具体有两方面,一方面,动态增加服务器数量以处理更多请求,另一方面,增加存储容量以容纳更多数据。- ④
节点缩容问题
:节点缩容是将无用节点从分布式系统中移除,以降低系统运行成本。