超详细的redis学习-进阶篇

redis多数据库

说明：一个redis实例可以包含多个数据库，客户端可以指定连接某个数据库（与MySql客户端我们创建多个数据库类似）一个redis实例最多可以提供16个数据库，下标是从0到15，默认连接的是第0号数据库。

代码相关演示:

	
127.0.0.1:6379> select 1  //选择数据库1	
	
OK	
	
127.0.0.1:6379[1]> keys *	
	
(empty list or set)	
	
127.0.0.1:6379[1]> select 0	
	
OK	
	
127.0.0.1:6379> set string1 2 	
	
OK	
	
127.0.0.1:6379> keys *  //查询所有的key	
	
1) "hsah1"	
	
2) "list1"	
	
3) "set1"	
	
4) "list2"	
	
5) "string1"	
	
6) "hash1"	
	
7) "string2"	
	
127.0.0.1:6379> move list1 1  //移动list1到数据库1	
	
(integer) 1	
	
127.0.0.1:6379> move set1 1	
	
(integer) 1	
	
127.0.0.1:6379> keys *	
	
1) "hsah1"	
	
2) "list2"	
	
3) "string1"	
	
4) "hash1"	
	
5) "string2"	
	
127.0.0.1:6379> select 1 	
	
OK	
	
127.0.0.1:6379[1]> keys *	
	
1) "list1"	
	
2) "set1"	
	
127.0.0.1:6379[1]> type set1 //获取数据类型	
	
set	
	
127.0.0.1:6379[1]>	

可以试着敲一遍，查看注释基本明白了redis多数据库的使用

redis事务的概念

1）multi 标记一个事务的开始

2）exec 执行所有事务块内的命令

3）discard 取消事务，放弃执行事务块内的所有命令

1）事务中的命令都是串行执行的。

2）事务执行期间redis不会再对其它的客户端提供任何服务，从而保证事务中的命令能够原子化执行。

3）单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

	
redis 127.0.0.1:6379> MULTI   //开启事务	
	
OK	
	
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"	
	
QUEUED	
	
redis 127.0.0.1:6379> GET book-name	
	
QUEUED	
	
redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"	
	
QUEUED	
	
redis 127.0.0.1:6379> SMEMBERS tag	
	
QUEUED	
	
redis 127.0.0.1:6379> EXEC //提交事务	
	
1) OK	
	
2) "Mastering C++ in 21 days"	
	
3) (integer) 3	
	
4) 1) "Mastering Series"	
	
   2) "C++"	
	
   3) "Programming"	

redis数据持久化

优势

1）redis数据库会只包含一个文件存储在硬盘中，对于文件备份会简单很多。

2）对于灾难恢复，RDB是更好的选择，因为一个文件可以直接拷贝走，拷贝回来。

3）性能最大化，redis开始持久化的时候只分出一些子进程，之后这些子进程会完成持久化工作,避免了服务器进程执行io的操作。数据集很大的时候，启动效率会更高。

缺点

1）最大限度的避免数据丢失，RDB做的不是特别好，系统一定在定时持久化之前出现一些档期的情况，还没有来得及往硬盘上写，数据已经丢失掉。

2）因为RDB是通过开启子进程的方式来进行持久化操作的，因此当数据集比较大的时候，这个过程可能会导致服务器停止一定事件，几十毫秒甚至1秒。

配置

linux目录中/usr/local/redis/redis-conf目录中找到这样的几行代码

	
save 900 1	
	
save 300 10	
	
save 60 10000	

第一行代码表示：900秒，也就是15分钟至少又一个key发生变化就会持久化一次。

第二行代码表示：300秒，至少有10个key发生变化就会往硬盘中持久化一次。

第三行代码表示：60秒，至少有10000个key发生变化就会往硬盘中持久化一次。

	
dbfilename dump.rdb	

配置中继续往下看，看到这样一行代码，这个dump是数据库的名字。

往下一段代码

	
dir ./	

保存路径位置，就是当前目录下的上面的名字，就是持久化的数据库

优势

1)可以带来更高的数据安全性，这种数据持久化方式有三种同步策略，每秒同步，每修改同步（每一次发生数据的变化都会立即被记录到磁盘中，效率最低但是最安全），不同步。

2）日志的写入操作是采用append追加的模式，在写入过程中即使出现服务器档期问题，也不会破坏日志文件中已经写入的内容。

3）如果日志过大，redis可以自动启动重写机制，redis会不断的将修改的数据写入到老的磁盘当中，同时redis会创建一个新的文件来记录此期间产生了哪些修改命令被执行了。

4）AOF包含一个格式非常清晰易于理解的日志文件，用于记录所有的修改操作。通过这个文件就可以完成数据的重建。

劣势

1）对于相同的数据集文件，AOF要比RDB文件大。

2）根据同步策略的不同，AOF在运行效率上往往低于RDB，AOF每修改就同步到硬盘上效率肯定是没有RDB高的。

>   配置

linux目录中/usr/local/redis/redis-conf目录中找到这样的几行代码

	
appendonly no	
	
	
	
# The name of the append only file(default:"appendonly.aof")	
	
	
	
appendfilename "appendonly.aof"	

如果使用AOF的持久还方式，需要把appendonly 后面的属性变为yes

appendonly.aof是用来记录所有修改操作的文件，这个文件还可以用来进行数据的恢复等，例如一条删除操作成功后，我们在appendonly.aof文件中把删除命令去掉，重新运行redis，之前的数据又都会恢复

	
# appendfsync always	
	
appendfsync everysec	
	
# appendfsync no	

这段代码是关于同步策略的一个设置，第一条是每修改就同步持久化，第二条是每秒同步持久化一次，第三条是不同步持久化。

说明:按照redis之后默认选择的是RDB方式，还有在修改过redis-config之后注意要重新启动redis服务才能生效

高难度

http://blog.51cto.com/hmtk520/2115789

redis中的key设置过期时间

设置时间格式

EXPIRE key secords

1. 当给定的key设置了生存时间，当key过期时（生存/过期为0），它会被自动删除

2. redis中带有生存时间的key被称为易失（volatile）的

3. 生存时间可以通过使用 DEL 命令来删除整个 key 来移除，或者被 SET 和 GETSET 命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的 key 的值而不是用一个新的 key 值来代替(replace)它的话，那么生存时间不会被改变。

4. 对一个 key 执行 INCR 命令，对一个列表进行 LPUSH 命令，或者对一个哈希表执行 HSET 命令，这类操作都不会修改 key 本身的生存时间。

5. 使用 RENAME 对一个 key 进行改名，那么改名后的 key 的生存时间和改名前一样。RENAME 命令的另一种可能是，尝试将一个带生存时间的 key 改名成另一个带生存时间的 another_key ，这时旧的 another_key (以及它的生存时间)会被删除，然后旧的 key 会改名为 another_key ，因此，新的 another_key 的生存时间也和原本的 key 一样。

6. 使用 PERSIST 命令可以在不删除 key 的情况下，移除 key 的生存时间，让 key 重新成为一个『持久的』(persistent) key 。

可以对一个已经带有生存时间的 key 执行 EXPIRE 命令，新指定的生存时间会取代旧的生存时间。

代码如下：

	
redis> SET cache_audio "hello koala"	
	
OK	
	
 	
redis> EXPIRE cache_audio 30  # 设置过期时间为 30 秒	
	
(integer) 1	
	
 	
redis> EXPIRE cache_audio 30000   # 更新过期时间	
	
(integer) 1	
	
	
redis> TTL cache_audio    # 查看剩余生存时间	
	
(integer) 29996 	

注意在设置过期时间的时候：

返回值：

设置成功返回 1 。

当 key 不存在或者不能为 key 设置生存时间时(比如在低于 2.1.3 版本的 Redis 中你尝试更新 key 的生存时间)，返回 0 。

在Redis2.4版本中，过期时间的延迟在一秒之内，可以简单的说，就算key已经过期，但它还是可能在过期一秒之内被访问到，在新的Redis2.6版本中，延迟被降低到了一毫秒之内。

在redis2.1.3之前的版本中，修改一个带有生存时间的key会导致整个key被删除，这一行为是受当时复制(replication)层的限制而作出的，现在这一限制已经被修复。

使用TT

代码如下：

	
redis> SET cache_audio "hello koala"	
	
OK	
	
 	
	
redis> EXPIRE cache_audio 30  # 设置过期时间为 30 秒	
	
(integer) 1	
	
 	
	
redis> TTL cache_audio    # 查看剩余生存时间	
	
(integer) 23