由于redis是一个内存数据库,如果系统遇到致命问题需要关机或重启,内存中的数据就会丢失,这是生产环境所不能允许的。所以redis提供了数据持久化的能力。
redis提供了两种持久化数据的方式,分别是RDB和AOF,这两种方式都是把数据写到硬盘上,实现内容数据的备份,在需要的时候redis会读取RDB或AOF文件,重新把数据加载到内存中,从而实现数据的恢复。
这两种持久化方式因为原理不同,因此各有优缺点,可根据实际情况灵活选 用。
RDB原理
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照(Snapshot)存储,是默认的持久化方式。
RDB也是一种半持久化模式,因为它会按照一定的策略周期性的将数据保存到磁盘,产生名为dump.rdb(可以在配置中修改生成的数据文件名称)的数据文件,生成快照的周期策略可以通过配置文件定义。
Redis实现快照的过程
Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);
父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;
- 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成。
在执行fork的时候操作系统(类Unix操作系统)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令 ),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。
Redis在进行快照的过程中不会修改RDB文件,只有快照结束后才会将旧的文件替换成新的,也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实 现Redis数据库备份。RDB文件是经过压缩(可以配置rdbcompression参数以禁用压缩节省CPU占用)的二进制格式,所以占用的空间会小于内存中的数据大小,更加利于传输。
RDB优点
从上面的原理可以看到,RDB方式有如下优点:
RDB是一个非常紧凑的文件,它保存了某个时间点得完整数据集,非常适用于数据集的备份
RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心,非常适用于灾难恢复.
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能
- 与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些.
RDB缺点
当然RDB方式也有一些缺点:
Redis在意外停止工作(例如电源中断)的情况下会丢失上一次备份到现在的数据
- RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求
RDB配置
打开redis的配置文件(一般在/etc/redis/redis.conf),可以看到基中有RDB的配置项:
111 ###################### SNAPSHOTTING ######################
112 #20秒内有至少1个键被更改则进行快照
113 save 20 1
114 #300秒内有至少10个键被更改则进行快照
115 save 300 10
116 #60秒内有至少10000个键被更改则进行快照
117 save 60 10000
118
119 stop-writes-on-bgsave-error yes
120
121 #RDB方式时压缩数据
122 rdbcompression yes
123
124 #检查数据校验和
125 rdbchecksum yes
126
127 #备份的数据文件名称
128 dbfilename dump.rdb
129
130 #备份的数据文件位置
131 dir /var/lib/redis
RDB备份恢复演示
生成RDB文件(存在/var/lib/redis目录下):
#当前redis中有两个值
# redis-cli
127.0.0.1:6379> keys *
1) "name"
2) "age"
#用save命令生成dump.rdb文件
127.0.0.1:6379> save
OK
查看生成的文件:
/var/lib/redis# ll
total 12
drwxr-xr-x 2 redis redis 4096 Jul 28 01:11 ./
drwxr-xr-x 47 root root 4096 Jun 15 04:19 ../
-rw-rw---- 1 redis redis 40 Jul 28 01:11 dump.rdb
关闭redis服务:
# /etc/init.d/redis-server stop
Stopping redis-server: redis-server.
启动redis服务,并查看是否恢复了数据,这里要求redis安装目录(即/var/lib/redis)下有dump.rdb文件:
# /etc/init.d/redis-server start
Starting redis-server: redis-server.
root@xxx:/var/lib/redis# redis-cli
127.0.0.1:6379> keys *
1) "age"
2) "name"
我们可以看到,数据已经恢复了。
AOF原理
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。
因为 AOF 的运作方式是不断地将命令追加到文件的末尾, 所以随着写入命令的不断增加, AOF 文件的体积也会变得越来越大。举个例子, 如果你对一个计数器调用了 100 次 INCR , 那么仅仅是为了保存这个计数器的当前值, AOF 文件就需要使用 100 条记录(entry)。然而在实际上, 只使用一条 SET 命令已经足以保存计数器的当前值了, 其余 99 条记录实际上都是多余的。
为了处理这种情况, Redis 支持一种有趣的特性: 可以在不打断服务客户端的情况下, 对 AOF 文件进行重建(rebuild)。执行 BGREWRITEAOF 命令, Redis 将生成一个新的 AOF 文件, 这个文件包含重建当前数据集所需的最少命令。
AOF优点
从上面的原理可以看到,AOF方式有如下优点:
使用AOF方式备份的数据更完整
- AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此 AOF 文件的内容非常容易被人读懂, 对文件进行分析(parse)也很轻松。 导出(export) AOF 文件也非常简单: 举个例子, 如果你不小心执行了 FLUSHALL 命令, 但只要 AOF 文件未被重写, 那么只要停止服务器, 移除 AOF 文件末尾的 FLUSHALL 命令, 并重启 Redis , 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF缺点
对于相同的数据集来说,AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的策略,AOF 的速度可能会慢于 RDB 。
AOF配置
在配置文件的 APPEND ONLY MODE
部分可以看到对AOF的配置:
373 #################### APPEND ONLY MODE #####################
374 #是否开始AOF方式
375 appendonly yes
376
377 #AOF方式生成的文件名
378 appendfilename "appendonly.aof"
379
380 #AOF方式写入数据的三种方式
381 # appendfsync always #每次收到写命令就立即强制写入磁盘,是最有保证的完全的持久化,但速度 也是最慢的,一般不推荐使用。
382 appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,是受推荐
的方式。
383 # appendfsync no #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不
被推荐。
384
385 #在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上 的冲突。
386 no-appendfsync-on-rewrite no
387
388 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
389 auto-aof-rewrite-percentage 100
390
391 #当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的> 重写。
392 auto-aof-rewrite-min-size 64mb
AOP备份恢复演示
#向redis中写入一个值
# redis-cli
127.0.0.1:6379> set name "Hello Imooc"
OK
#查看生成的appendonly.aof文件
/var/lib/redis# cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
name
$11
Hello Imooc
#重启redis,检查数据是否恢复
# /etc/init.d/redis-server restart
Stopping redis-server: redis-server.
Starting redis-server: redis-server.
root@xxx:/var/lib/redis# redis-cli
127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> get name
"Hello Imooc"
可以看到数据也恢复成功。
一般来说, 如果想达到足以媲美数据库的数据安全性, 你应该同时使用两种持久化功能。
如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失, 那么你可以只使用 RDB 持久化。
Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。
攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上进行数据操作,甚至可以写入公钥,进而可以使用对应私钥直接登录目标服务器。
下面是一些常规安全手段:
修改 redis.conf 文件,添加如下配置禁用敏感命令,并重启redis:
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command EVAL ""
为 Redis 服务创建单独的用户和家目录
在配置文件中添加密码:
requirepass imooc
这时直接在cli下运行命令会提示没权限:
# redis-cli
127.0.0.1:6379> keys *
(error) NOAUTH Authentication required.
有两种方式可以登录,一是运行 redis-cli
时增加 -a
参数:
# redis-cli -a imooc
127.0.0.1:6379> keys *
1) "name"
二是进入telnet后运行 auth 密码
进行授权:
# redis-cli
127.0.0.1:6379> auth imooc
OK
127.0.0.1:6379> keys *
1) "name"
修改 redis.conf 文件,添加或修改
bind 127.0.0.1
使得 Redis 服务只在当前主机可用
Redis 官方推荐的PHP客户端是 Predis 和 PHPRedis。
前者是使用PHP代码实现的原生客户端,后者则是使用C语言编写的PHP扩展。性能上后者更占优势,但如果你使用的是虚拟主机,无法对PHP进行扩展,则需选择前者。
本文选择的是 PHPRedis。
Ubuntu下安装
# apt-get install php5-redis
在PHP中使用
php示例文件:
1 <?php
2 $redis = new Redis();
3 $redis -> connect('127.0.0.1', 6379);
4 $redis -> set('test', "hello world");
5 echo $redis -> get('test');
6 ?>
# php -f redis.php
hello world
php中redis详细语法可参考:https://github.com/phpredis/phpredis