Redis进阶：数据持久化，安全，在PHP中使用

一、redis数据持久化

由于redis是一个内存数据库，如果系统遇到致命问题需要关机或重启，内存中的数据就会丢失，这是生产环境所不能允许的。所以redis提供了数据持久化的能力。

redis提供了两种持久化数据的方式，分别是RDB和AOF，这两种方式都是把数据写到硬盘上，实现内容数据的备份，在需要的时候redis会读取RDB或AOF文件，重新把数据加载到内存中，从而实现数据的恢复。

这两种持久化方式因为原理不同，因此各有优缺点，可根据实际情况灵活选 用。

1、RDB##

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"

我们可以看到，数据已经恢复了。

2、AOF##

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安全#

Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。

攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法，可以成功在 Redis 服务器上进行数据操作，甚至可以写入公钥，进而可以使用对应私钥直接登录目标服务器。

下面是一些常规安全手段：

1、禁止一些高危命令##

修改 redis.conf 文件，添加如下配置禁用敏感命令，并重启redis：

rename-command FLUSHALL ""
rename-command CONFIG   ""
rename-command EVAL     ""

2、以低权限运行 Redis 服务##

为 Redis 服务创建单独的用户和家目录

3、添加密码验证##

在配置文件中添加密码：

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"

4、禁止外网访问##

修改 redis.conf 文件，添加或修改

bind 127.0.0.1

使得 Redis 服务只在当前主机可用

三、redis在php中的使用#

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

中文版：phpredis中文手册——《redis中文手册》 php版