文章目录
淘汰策略
当内存达到max_memory(在redis.conf中进行配置,主机内存96G,则设置为48G,因为持久化需要fork一份当前redis的快照)
首先明确淘汰策略并不会检测value内部的key,也即list的element,hash的field这些。
时限key中淘汰
| 淘汰策略 | 意义 |
|---|---|
| volatile-lru | 最长时间没有使用 |
| volatile-lfu | 最少次数使用 或 随机采样 |
| volatile-ttl | 最近要过期 |
| volatile-random | 随机 |
所有key中淘汰
| 淘汰策略 | 意义 |
|---|---|
| allkeys-lru | 最长时间没有使用 |
| allkeys-lfu | 最少次数使用 或 随机采样 |
| volatile-random | 随机 |
禁止淘汰(默认)
指令返回错误
持久化
redis是一个内存数据库,所有的数据储存在内存中,虽然访问速度快但是易丢失。默认开启rdb持久化
fopen fwrite setbuf fflush fsync fclose
fwrite只是把buffer中的数据写到用户态缓冲区中,内核并不知情
fflush把fd对应的用户态缓冲区内部数据移动到page cache(高速缓存)
不调用fsync,数据也会到文件中,只不过不知道何时,通过LRU把page cache中的数据淘汰到file中。

机器断电,丢失1,2的数据
进程关闭,丢失1的数据
fork写时复制 :子进程和父进程映射同一块物理内存。
父进程复制一块虚拟内存页表给子进程,同时二者设置为可读,二者虚拟内存映射到同一块物理页。只有其中的任意一个进程试图修改一个共享的只读物理页面时(例如,修改一个全局变量或在堆上分配新内存),才会写保护中断触发,物理页复制,谁修改,谁指向新的,把只读状态修改为可读可写状态。

利用fork进程 的功能给父进程的内存打了快照。
在维持了redis对外服务能力的基础上,对redis数据做了一次保存。
aof
通过追加写日志到buffer的方式进行持久化。顺序磁盘io≈内存随机io
但是会有数据冗余的情况,多条set只有最后一条set是有效的。
aof的策略:
①always 一旦有对redis的修改就要落盘
②every_sec (bio_fsync_aof)每秒钟进行一次落盘
③no buffer的数据到page cache(见上)
aof-rewrite
fork一份子进程,只保存redis内存当前的状态,根据内存数据状态生成aof文件,避免同一个key的历史冗余。在重写aof期间,对redis所有的写操作记录到重写缓冲区,当重写结束后,附加到aof文件末尾。
rdb
通过fork子进程进行持久化,基于内存中的数据进行持久化。但是缺点是rdb不能看到两次rdb之间数据的修改。
rdb-aof混合持久化
在rdb持久化期间,对redis的写操作记录到重写缓冲区,rdb持久化建立后,附加到aof文件末尾
redis持久化相关配置
在redis.conf中完成配置
conf
######### aof #########
# redis.cnf
appendonly no
appendfilename "appendonly.aof"
# aof read write invert
# appendfsync always
appendfsync everysec
# appendfsync no
# auto-aof-rewrite-percentage 为 0 则关闭 aof 复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# yes 如果 aof 数据不完整,尽量读取最多的格式正确的数据;
# no 如果 aof 数据不完整 报错,可以通过 redis-check-aof 来修复 aof 文件;
aof-load-truncated yes
# 开启混合持久化
aof-use-rdb-preamble yes
######### rdb #########
# save ""
# save 3600 1
# save 300 100
# save 60 10000
aof
# 开启 aof
appendonly yes
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""
# 1. 每条命令刷盘 redis 事务才具备持久性
# appendfsync always
# 2. 每秒刷盘
appendfsync everysec
# 3. 交由系统刷盘
# appendfsync no
aof-fwrite
# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 关闭 混合持久化
aof-use-rdb-preamble no
# 关闭 rdb
save ""
# 1. redis 记录上次aof复写时的size,如果之后累计超过了原来的size,则会发生aof复写;
auto-aof-rewrite-percentage 100
# 2. 为了避免策略1中,小数据量时产生多次发生aof复写,策略2在满足策略1的前提下需要超过 64mb 才会发生aof复写;
auto-aof-rewrite-min-size 64mb
rdb
# 关闭 aof 同时也关闭了 aof复写
appendonly no
# 关闭 aof复写
auto-aof-rewrite-percentage 0
# 关闭 混合持久化
aof-use-rdb-preamble no
# 开启 rdb 也就是注释 save ""
# save ""
save 3600 1
save 300 100
save 60 10000
# redis 默认策略如下;
# 注意;写了多个 save 策略,只需要满足一个则开启rdb持久化
# 3600 秒内有以1次修改
save 3600 1
# 300 秒内有100次修改
save 300 100
# 60 秒内有10000次修改
save 60 10000
rdb-aof混合持久化
# 开启 aof
appendonly yes
# 开启 aof复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 开启 混合持久化
aof-use-rdb-preamble yes
# 关闭 rdb
save ""
redis持久化方案的优缺点
| 特性 | AOF (Append Only File) | RDB (Redis Database Snapshot) |
|---|---|---|
| 优点 | 数据可靠,丢失较少 持久化过程代价较低 | RDB 文件小 数据恢复快 |
| 缺点 | AOF 文件过大 数据恢复慢 | 数据丢失较多 持久化过程代价较高(fork子进程实现) |
高可用:Redis主从复制数据备份+主从切换机制-在几秒钟内得到合理答案
主要用来实现redis数据的可靠性;防止redis所在的磁盘损坏,造成数据永久丢失;
redis主从间采用异步复制的方式 ;异步复制优点高效,缺点是只能保证最终一致。现代分布式系统都是半数一致性。

#redis.conf
replicaof 127.0.0.1 7002
info replication
主从切换
哨兵模式
只保证一个节点的可用性

redis-cluster集群
多个中心节点对外提供服务。
问题:向其中一个主节点写入数据时,怎么保证数据均衡地落到其他主节点
关注分布式一致性hash
配置redis-cluster集群