Redis入门

 

1.1      消息订阅与发布

subscribe channel：订阅频道，例：subscribe mychat，订阅mychat这个频道

psubscribe channel*：批量订阅频道，例：psubscribe s*，订阅以”s”开头的频道

 

publish channel content：在指定的频道中发布消息，如 publish mychat ‘today is a newday’

1.2      多数据库

1.2.1      概念

一个Redis实例可以包括多个数据库，客户端可以指定连接某个redis实例的哪个数据库，就好比一个mysql中创建多个数据库，客户端连接时指定连接哪个数据库。

         一个redis实例最多可提供16个数据库，下标从0到15，客户端默认连接第0号数据库，也可以通过select选择连接哪个数据库，如下连接1号库：

连接0号数据库：

1.2.2      将newkey移植到1号库

move newkey 1：将当前库的key移植到1号库中

1.2.3      注意问题

在0号数据库存储数据，在1号数据库执行清空数据命令却把0号数据库的数据给清空了：

建议：不同的应用系统要使用不同的redis实例而不是使用同一个redis实例下的不同数据库。

 

1.3      redis事务

1.3.1      概念

和众多其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/这三个命令是我们实现事务的基石。

1.3.2      redis事务特征

1、  在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行

2、  和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。

3、  我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。

4、  在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。

5、  当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。

1.3.3      命令解释

l  multi：开启事务用于标记事务的开始，其后执行的命令都将被存入命令队列，直到执行EXEC时，这些命令才会被原子的执行，类似与关系型数据库中的：begin transaction

l  exec：提交事务，类似与关系型数据库中的：commit

l  discard：事务回滚，类似与关系型数据库中的：rollback

1.3.4      测试

1.3.4.1    正常执行事务

1.3.4.2    失败命令

1.3.4.3    回滚

 

 

 

 

1.4      服务器命令(自学)

n  ping

测试连接是否存活

redis 127.0.0.1:6379> ping

PONG

//执行下面命令之前，我们停止redis 服务器

redis 127.0.0.1:6379> ping

Could not connect to Redis at 127.0.0.1:6379: Connection refused

//执行下面命令之前，我们启动redis 服务器

not connected> ping

PONG

redis 127.0.0.1:6379>

第一个ping 时，说明此连接正常

第二个ping 之前，我们将redis 服务器停止，那么ping 是失败的

第三个ping 之前，我们将redis 服务器启动，那么ping 是成功的

 

n  echo

在命令行打印一些内容

redis 127.0.0.1:6379> echo HongWan

"HongWan"

redis 127.0.0.1:6379>

n  select

选择数据库。Redis 数据库编号从0~15，我们可以选择任意一个数据库来进行数据的存取。

redis 127.0.0.1:6379> select 1

OK

redis 127.0.0.1:6379[1]> select 16

(error) ERR invalid DB index

redis 127.0.0.1:6379[16]>

当选择16 时，报错，说明没有编号为16 的这个数据库

 

n  quit

退出连接。

redis 127.0.0.1:6379> quit

 

n  dbsize

返回当前数据库中key 的数目。

redis 127.0.0.1:6379> dbsize

(integer) 18

redis 127.0.0.1:6379>

结果说明此库中有18 个key

n  info

获取服务器的信息和统计。

redis 127.0.0.1:6379> info

redis_version:2.2.12

redis_git_sha1:00000000

redis_git_dirty:0

arch_bits:32

multiplexing_api:epoll

process_id:28480

uptime_in_seconds:2515

uptime_in_days:0

。。。。

。。。。

 

n  flushdb

删除当前选择数据库中的所有key。

redis 127.0.0.1:6379> dbsize

(integer) 18

redis 127.0.0.1:6379> flushdb

OK

redis 127.0.0.1:6379> dbsize

(integer) 0

redis 127.0.0.1:6379>

在本例中我们将0 号数据库中的key 都清除了。

 

n  flushall

删除所有数据库中的所有key。

redis 127.0.0.1:6379[1]> dbsize

(integer) 1

redis 127.0.0.1:6379[1]> select 0

OK

redis 127.0.0.1:6379> flushall

OK

redis 127.0.0.1:6379> select 1

OK

redis 127.0.0.1:6379[1]> dbsize

(integer) 0

redis 127.0.0.1:6379[1]>

在本例中我们先查看了一个1 号数据库中有一个key，然后我切换到0 号库执行flushall 命令，结果1 号库中的key 也被清除了，说是此命令工作正常。

 

 

     redis使用场景

1、  取最新N个数据的操作

比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的5000条评论的ID放在Redis的List集合中，并将超出集合部分从数据库获取

 (1)使用LPUSH latest.comments <ID>命令，向list集合中插入数据

 (2)插入完成后再用LTRIM latest.comments 0 5000命令使其永远只保存最近5000个ID

 (3)然后我们在客户端获取某一页评论时可以用下面的逻辑（伪代码）

# 伪代码

 

FUNCTION get_latest_comments(start, num_items):

    id_list = redis.lrange("latest.comments", start, start+num_items-1)

    IF id_list.length < num_items

        id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")

    END

    RETURN id_list

END

如果你还有不同的筛选维度，比如某个分类的最新N条，那么你可以再建一个按此分类的List，只存ID的话，Redis是非常高效的。

 

2、  排行榜应用，取TOP N操作

这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的sorted set出马了，将你要排序的值设置成sorted set的score，将具体的数据设置成相应的value，每次只需要执行一条ZADD命令即可。

 

3、  需要精准设定过期时间的应用

比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除Redis中的过期数据，你完全可以把 Redis里这个过期时间当成是对数据库中数据的索引，用Redis来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

 

4、  计数器应用

Redis的命令都是原子性的，你可以轻松地利用INCR，DECR命令来构建计数器系统。

 

5、  Uniq操作，获取某段时间所有数据排重值

这个使用Redis的set数据结构最合适了，只需要不断地将数据往set中扔就行了，set意为集合，所以会自动排重。

 

6、  实时系统，反垃圾系统

通过上面说到的set功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。没有做不到，只有想不到。

 

7、  Pub/Sub构建实时消息系统

Redis的Pub/Sub系统可以构建实时的消息系统，比如很多用Pub/Sub构建的实时聊天系统的例子。

 

8、  构建队列系统

使用list可以构建队列系统，使用sorted set甚至可以构建有优先级的队列系统。

 

 

 

   redis持久化

3.1      概述

1、  RDB持久化（默认支持，无需配置）

该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

2、  AOF持久化

该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

3、  无持久化

我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。

4、  redis同时使用RDB和AOF

3.2      RDB

3.2.1      优势

1、  一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2、  对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上

3、  性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4、  相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

3.2.2      劣势

1、  如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2、  由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟

3.2.3      配置说明Snapshotting

l  save 900 1 #每900秒(15分钟)至少有1个key发生变化，则dump内存快照。

l  save 300 10 #每300秒(5分钟)至少有10个key发生变化，则dump内存快照

l  save 60 10000 #每60秒(1分钟)至少有10000个key发生变化，则dump内存快照

3.3      AOF

3.3.1      优势

1、  该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。

2、  由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3、  如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4、  AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

3.3.2      劣势

1、  对于相同数量的数据集而言，AOF文件通常要大于RDB文件

2、  根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

3.3.3      配置AOF

3.3.3.1    配置信息

l  always    #每次有数据修改发生时都会写入AOF文件

l  everysec  #每秒钟同步一次，该策略为AOF的缺省策略

l  no       #从不同步。高效但是数据不会被持久化

 

重写AOF：若不满足重写条件时，可以手动重写，命令：bgrewriteaof

 

 

 

策略的选择：

3.3.3.2    数据恢复演示

1、  flushall操作  清空数据库

2、  及时关闭redis服务器（防止dump.rdb）。  shutdown nosave

3、  编辑aof文件，将日志中的flushall命令删除并重启服务即可

 

l  步骤1：开启aop，并设置成总是保存。然后重启redis

 

l  步骤2：在窗口1进行若干操作