AOF 持久化是 Redis 提供的另外一种持久化方案,AOF 持久化是将发送到服务端的每一条命令记录下来,并且保存在硬盘的 AOF 文件中。AOF 默认是关闭的,可以通过修改 redis.conf 中相应的配置启动。
appendonly yes # 启动 AOF 持久化,默认是 no
appendfilename "appendonly.aof" # AOF 文件文件名
文件的写入默认情况下会先写入系统的缓存中,系统每隔30秒同步一次,才是真正的写入磁盘,如果这30秒服务器宕机那数据也会丢失。
Redis 可以通过 redis.conf 中的配置设置同步策略
# appendfsync always 每次都同步(最安全但是最慢)
appendfsync everysec 每秒同步(默认的同步策略)
# appendfsync no 不主动同步,由操作系统来决定(最快但是不安全)
因为 AOF 持久化是保存了被执行的 Redis 命令来记录数据库状态的,所以随着时间流失,AOF 文件内容会越来越多,文件越来越大,这样不禁会占用较多的存储空间,同时也使数据恢复进行的时候速度受到限制。所以 Redis 添加 AOF 文件重写,AOF 文件的重写(会在fork一个子进程完成)并不会读取当前的 AOF 文件,去整理历史的命令,而是根据当前服务器数据状态生成一份 AOF 文件。 我们可以在命令行使用BGREWRITEAOF 命令重写 AOF 文件,同时 Redis 服务器也会根据 Redis 配置文件执行重写策略。
auto-aof-rewrite-percentage 100 # 当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。
auto-aof-rewrite-min-size 64mb # 限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的。
重新启动一个redis,并添加几个值
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set user:1 shuai
OK
127.0.0.1:6379> set user:2 shuai
OK
127.0.0.1:6379> set user:3 shuai
OK
127.0.0.1:6379> keys *
1) "user:3"
2) "user:2"
3) "user:1"
127.0.0.1:6379> get user:1
"shuai"
我们查看appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$6
user:1
$5
shuai
*3
$3
set
$6
user:2
$5
shuai
*3
$3
set
$6
user:3
$5
shuai
cat查看appendonly.aof 已经将 Redis 命令协议的 \r\n 转义成了换行。
我们修改 Redis 服务器里的值
127.0.0.1:6379> set user:1 bushuai
OK
127.0.0.1:6379> set user:2 bushuai
OK
127.0.0.1:6379> set user:3 bushuai
OK
在查看 AOF 文件内容
*2
$6
SELECT
$1
0
*3
$3
set
$6
user:1
$5
shuai
*3
$3
set
$6
user:2
$5
shuai
*3
$3
set
$6
user:3
$5
shuai
*3
$3
set
$6
user:1
$7
bushuai
*3
$3
set
$6
user:2
$7
bushuai
*3
$3
set
$6
user:3
$7
bushuai
很显然,AOF 文件把所有的命令都追加到了 AOF 文件后面。那么我们执行 AOF 重写命令
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
在次查看 AOF 文件内容
*2
$6
SELECT
$1
0
*3
$3
SET
$6
user:3
$7
bushuai
*3
$3
SET
$6
user:2
$7
bushuai
*3
$3
SET
$6
user:1
$7
bushuai
显然,AOF 文件里保存的命令正是能恢复redis数据的最简单命令集。
这个时候我们可以在服务器上同时看到appendonly.aof 和 dump.rdb 文件,我们重启redis并查看启动日志。
1:M 17 Oct 07:12:26.054 * DB loaded from append only file: 0.000 seconds
1:M 17 Oct 07:12:26.055 * Ready to accept connections
在 redis 的启动日志里我们可以看到 Redis 是从 AOF 文件里恢复的数据。
非著名程序员,全栈开发工程师,长期专注系统开发与架构设计。
功能待开通!
redis 的 string 类型是支持过期设置的,默认是永不过期的。 Redis 设置过期 redis 中设置设置 key 过期有3中方式 第一种在设置值的时候指定过期时间 Set 命令格式 SET key value [EX seconds] [PX milliseconds] [NX|XX] EX second :设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。 PX millisecond :设置键的过期时间为 millisecond 毫秒。 3. SET key value PX m
Redis 作为高效的缓存数据库,单机也能够表现出很好的性能。但是随着数据的增加、并发的增加,单机模式的 Redis 会受到单机性能、容量、稳定性的限制,即使 Redis 提供了稳定的持久化方案,但是单机服务器始终是部署在单个机器上,如果运行机器本身的服务器出现问题我们很难在短时间恢复服务。所以 Redis 提供了三种多机模式: 主从复制模式 哨兵模式 集群模式 redis集群模式 哨兵模式解决了主节点挂掉的问题,但是没有解决从节点挂掉的问题,而 redis 集群模式可以有效的解决这个问题。redis集群中的数据是和槽(slot)挂钩的,一共定义了16384个槽,所有的数据使用一致性哈希分
Redis 作为高效的缓存数据库,单机也能够表现出很好的性能。但是随着数据的增加、并发的增加,单机模式的 Redis 会受到单机性能、容量、稳定性的限制,即使 Redis 提供了稳定的持久化方案,但是单机服务器始终是部署在单个机器上,如果运行机器本身的服务器出现问题我们很难在短时间恢复服务。所以 Redis 提供了三种多机模式: 主从复制模式 哨兵模式 集群模式 哨兵模式 主从复制模式解决了数据备份和单机可能存在的性能问题,但是也引入了新的问题,一主多从,在使用过程中,如果主服务器挂掉那么整个 Redis 服务的写就挂掉了,如果一个从服务器挂掉那么调用方就无法正确的读数据了,只能通过修改调
redis 中内存管理没有直接使用 C 语言提供的方法而是做了一个可管理已分配内存大小及添加了自己分配策略的实现,下面从 SDS 开始去了解 redis 的内存管理实现及策略。 SDS 内存管理函数定义如下: src/sdsalloc.h #include "zmalloc.h" #define s_malloc zmalloc #define s_realloc zrealloc #define s_free zfree s_malloc 内存申请、s_realloc 内存重新分配、s_free 内存释放,这里定义分别是 zmalloc.h 里三个函数的别名,而 zmalloc zrea
有时候我们需要在短时间内往 redis 里插入大量的数据,我们如果单条单条的出入会浪费很多时间和服务器资源,我们可以使用管道来实现快速的插入。 netcat 我们把需要插入 redis 的数据创建为如下的一个命令集文件 set key1 val1 set key2 val2 ... set key3 val3 我们使用如下命令执行数据导入 > $ cat /tmp/test|nc localhost 6379 +OK +OK +OK pipe mode 使用 netcat 并不是一个可靠地方式,因为用netcat进行大规模插入时不能检查错误。从Redis 2.6开始redis-cli支