学习了Redis相关的问题,进行相关的记录。
一: Redis持久化
1.RDB方式持久化
在默认的情况下,Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。
可以通过命令设置:
save 60 1000
该命令表示:60秒内1000个键被改动,自动保存一次。每次执行命令都会将所有redis内存快照到一个新的rdb文件里,并覆盖原有rdb快照文件。
bgSave的写时复制机制
Redis 借助操作系统提供的写时复制技术(Copy-On-Write, COW),在生成快照的同时,依然可以正常 处理写命令。
2.AOF(append-only file)
将修改的每一条指令都记录进文件appendonly.aof中。
通过配置文件修改AOF功能:
appendonly yes
表示:每当Redis执行一个改变数据集的命令时,这个命令就会被追加到AOF文件的末尾。
配置Reids多久将数据fsync到磁盘一次
- appendfsync always:每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全。
- appendfsync everysec:每秒 fsync 一次,足够快,并且在故障时只会丢失 1 秒钟的数据。
- appendfsync no:从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。
以上两个方式都有各自的优缺点。
Redis4.0混合持久化
1.通过配置开启混合持久化
aof‐use‐rdb‐preamble yes
如果开启了混合持久化,AOF在重写时,是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起,都写入新的AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖之前的AOF文件,完成两个AOF文件的替换。
即重启Redis的时候,先加载RDB的内容,再重放增量AOF日志就可以完全替代之前的AOF全量文件重放。
Redis数据备份策略:
- 写crontab定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48 小时的备份
- 每天都保留一份当日的数据备份到一个目录中去,可以保留最近1个月的备份
- 每次copy备份的时候,都把太旧的备份给删了
- 每天晚上将当前机器上的备份复制一份到其他机器上,以防机器损坏
二:Redis的主从架构
高并发的情况下,Redis肯定就不是单机版了,先了解主从架构。结构如下图所示:
具体的操作配置如下:
1.复制一份redis.conf文件
2.将相关配置修改如下值:
port 6380
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1(bind绑定的是自己机器网卡的ip,如果有多块网
3.配置主从复制
replicaof 127.0.0.1 6379 # 从本机6379的redis实例复制数据,Redis 5.0之前使用slaveof
replica‐read‐only yes # 配置从节点只读
4.启动从节点
redis‐server redis.conf
5.连接从节点
redis‐cli ‐p 6380
即可,可以进行测试。
Redis主从复制原理
配置了一个slave,不管这个slave是否第一次连接上Master,他都会发送一个PSYNC命令给master请求复制数据。
master收到PSYNC命令后,会在后台进行数据持久化通过bgsave生成最新的rdb快照文件,持久化期间,master会继续收到客户端的请求,它会把这些可能修改数据集的请求缓存到内存汇总。当持久化进行完毕后,master会把这份rdb文件数据集发送给slave,slave会把接收到的数据进行持久化生成rdb,然后再加载到内存中。
然后,master再将之前缓存在内存中的命令发送给slave。
注意: 当master与slave之间的连接由于某些原因而断开,slave能够自动重连Master,如果master收到了多个slave并发连接的请求,它只会进行一次持久化,而不是一个连接一次。然后把这一份持久化的数据发送给多个并发连接的slave.
数据部分复制:
当master和slave断开重连后,一般都会对整份数据进行复制。从Redis2.8版本开始,redis改用可以支持部分数据复制的明略PSYNC去master同步数据,slave与master能够在网络连接断开重连后只进行部分数据复制。
本质上是: master会在其内存中创建一个复制数据用的缓存队列,缓存最近一段时间的数据,master和它所有的slave都维护了复制的数据下标offset和master的见id,因此,当网络连接断开后,slave会请求master继续进行并未完成的复制,从所记录的数据下标开始。如果master进行id变换了,或者从发节点数据下标offset太旧,已经不再master的缓存队列里了,那么将会进行一次全量数据的复制。
主从复制会有一个问题,即为主从复制风暴问题。
多个节点同时复制主节点导致主节点的压力过大,解决方案如下:
三:Redis哨兵高可用架构
sentinel哨兵是特殊的redis服务,不提供读写服务,主要用来监控redis实列节点。
哨兵架构下client第一次从哨兵找出reids的主节点,后续就直接访问redis的主节点,不会每次通过sentinel代理访问redis主节点,当redis主节点发生改变后,哨兵会第一时间感知,并将新的redis主节点通知给client端。
redis哨兵架构搭建步骤:
1.复制一份sentinel.conf文件
cp sentinel.conf sentinel‐26379.conf
2.将相关配置修改为如下值:
port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis‐5.0.3/data"
# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>
# quorum是一个数字,指明当有多少个sentinel认为一个master失效时(值一般为:sentinel总数/2 + 1),master才算真正失效
sentinel monitor mymaster 127.0.01 6379 2 # mymaster这个名字随便取,客户端访问时会用 到
3.启动sentinel哨兵实列
src/redis‐sentinel sentinel‐26379.conf
4.查看sentinel的info信息
src/redis‐cli ‐p 26379
127.0.0.1:26379>info
sentinel集群都启动完毕后,会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的 最下面).
当redis主节点如果挂了,哨兵集群就会重新选举出新的redis主节点,同时会修改所有sentinel节点配置文件的集群元数据信息。
同时还会修改sentinel文件里之前配置的mymater对应的6379端口号,改为新的主节点端口号。
当挂掉的主节点再次启动后,哨兵集群根据集群元数据信息可以将它作为从节点加入到集群中。
五:RedisTemplate
StringRedisTemplate默认采用的是String的序列化策略,保存的key和value都是采用此策略序列化保存的。
RedisTemplate默认采用的是JDK的序列化策略,保存的key和value都是采用此策略序列化保存的。