1.如何在redis中创建键
$redis = Yii::app()->redis;
$redis->set('key1',1111);
2.如何获取redis的键值
$redis->get('key1);
3.如何删除一个键
$redis->del('key3');
4.如何给键设定有效时间(以下例子是给键名为key3的键设置有效时间为5秒)
$redis->expire('key3',5);
2.3介绍完RDB的优缺点之后,我们再来谈一下AOF的优缺点
1).该机制可以带来更多的数据安全性,即数据的持久化。redis中提供了3种同步策略,即每秒同步,没修改同步和不同步。事实上,每秒同步也是异步完成的,其效率是非常高的,所差的是一旦系统出现宕机现象,那么一秒钟之内的修改的数据将全部丢失,而每次修改同步可以视为同步持久化,即每次发生的数据变化都会被记录写入到磁盘中,可以预见,这种方式在效率上是最低的,至于无同步,我们在这里就不做解释了。
2).由于该机制是对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现了宕机现象,也不会破坏日志文件已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题.
3).如果日志过大,redis可以自动启动rewrite机制。即redis以append模式不断的将修改数据写入到老的磁盘文件中,同时redis还会通过创建一个新的文件用于记录此间有哪些修改命令被执行.因此在进行rewrite切换时可以更好的保证数据安全性。
4).AOF包含一个格式清晰,易于理解的日志文件用于记录所有修改操作。事实上,我们可以通过该文件完成数据的重建。
2.4既然AOF有这些优点,接下来我们再看看它又有哪些缺点:
1).对于相同量的数据而言,AOF文件通常大于RDB文件。RDB在恢复大数据集时的速度比AOF的恢复速度要快。
2).根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略和RDB一样的高效。
二者选择的标准,就是看系统愿意牺牲一些性能,换取更高的缓存一致性(AOF)还是愿意写操作频繁的时候,不启用备份来换取更高的性能,
待手动save的时候,再做备份(RDB).RDB这个就更有些eventully consistent 的意思了.
2.5下面我们在介绍一下关于这两种持久化的常用配置
1.RDB持久化配置:
redis会将数据集的快照dump到dump.rdb文件中。此外,我们还可以通过配置文件来修改redis服务器dump快照的频率,在打开6397.conf文件之后,我们搜索save,可以看到下面的配置信息:
save 900 1 #在900秒(15分钟)之后,如果至少有一个key发生变化,则dump内存快照。
save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。
save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。
#注:上面三个选项要是都被注释了,rdb快照持久化存储就被屏蔽了:
stop-writes-on-bgsave-error yes # 后台存储错误停止写。
rdbcompression yes # 使用LZF压缩rdb文件。
rdbchecksum yes # 存储和加载rdb文件时校验。
dbfilename dump.rdb # 设置rdb文件名.
dir ./ #设置工作目录,rdb文件会写入该目录。/var/rdb可以写绝对地址
2.AOF持久化配置:
在redis的配置文件中存在三种同步方式,它们分别是:
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。
appendfsync no # 从不同步。高效但是数据不会被持久化。
appendfsync yes # 是否仅要日志yes(开启)|no(关闭)
appendffilename "appendonly.aof" #aof文件存放的位置/var/aof 可以写绝对地址
no-appendsync-on-rewrite yes # 正在导出rdb快照的过程中,要不要停止同步aof yes (停止) | no (不停止)
auto-aof-rewrite-percentage 100 # aof 文件大小比起上次重写时的大小,增长率100%时重写
auto-aof-rewrite-min-size 64mb # aof文件,至少超过64M时重写