String操作

SET key value 存储GET key 获取key对应的值DEL keys 删除key

List操作

RPUSH 将给定值推入到列表的右端LRANGE 获取列表在给定范围上的所有值LINDEX 获取列表在给定位置上的单个元素LPOP 从列表的左端弹出一个值，并返回被弹出的值

Set操作

SADD 将给定元素添加到集合SMEMBERS 返回集合包含的所有元素SISMEMBER 检查给定元素是否存在于集合中SREM 如果给定的元素存在于集合中，那么移除这个元素

Hash操作

HSET 在散列里面关联起给定的键值对HGET 获取指定散列键的值HGETALL 获取散列包含的所有键值对HDEL 如果给定键存在于散列里面，那么移除这个键

有序集合ZSort

ZADD 将一个带有给定分值的成员添加到有序集合里面ZRANGE 根据分值的排序顺序，获取有序集合在给定位置范围内的所有元素ZRANGEBYSCORE 获取有序集合在给定分值范围内的所有元素ZREM 如果给定成员存在于有序集合，那么移除这个成员

LRU算法

用来管理内存，提高内存效率 参考文章

事务

参考文档

相关指令

MULTI 开启事务EXEC 提交运行事务 DISCARD 用于取消事务，放弃执行事务块内的所有命令。 WATCH 标记所有指定的key，被监视起来，在事务中有条件的执行（乐观锁）。 如果在事务执行之前这个(或这些) key，被其他命令所改动，那么事务将被打断。

事务中的错误 - 使用事务时可能会遇上以下两种错误： 事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误（参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。

- 命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

redis中事务的总结： - 对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失败，那么大部分客户端都会停止并取消这个事务。 - 不过，从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。 - 在 Redis 2.6.5 以前， Redis 只执行事务中那些入队成功的命令，而忽略那些入队失败的命令。 - **而新的处理方式则使得在流水线（pipeline）中包含事务变得简单，因为发送事务和读取事务的回复都只需要和服务器进行一次通讯。 至于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。**

换言之：

指令在入队列（事务）时发生错误，如语法错误，那么整个队列的指令就都不会执行。

如果说在执行了exec指令后，发现指令中存在错误，如向一个不存在的list中添加数据，那么只是发生错误的指令执行错误，而整个队列（事务）中的其他的（正常）指令依旧会被执行，不会像传统数据库一般发生回滚，redis也不支持回滚。

redis持久化方式 参考文档

两种持久化方式

RDB -RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储. AOF AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.

RDB的优点

RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复. RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

RDB的缺点

如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

AOF 优点

使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

如何配置

永久配置

配置文件：redis.conf

save 60 1000 #RDB模式:表示60s内有1000次操作就会做一次快照，(snapshot) appendonly yes #AOF模式

手动

客户端执行： - RDB - BGSAVE/SAVE - AOF - BGREWRITEAOF #重构AOF文件，减少磁盘空间占用

运行时怎样从RDB方式切换为AOF方式 - 为最新的 dump.rdb 文件创建一个备份。 将备份放到一个安全的地方。 - 执行以下两条命令: - redis-cli config set appendonly yes - redis-cli config set save “” - 确保写命令会被正确地追加到 AOF 文件的末尾。 - 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。 - 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。

重要:别忘了在 redis.conf 中打开 AOF 功能！ 否则的话， 服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。

复制

redis复制是怎么进行工作

如果设置了一个slave，不管是在第一次链接还是重新链接master的时候，slave会发送一个同步命令 然后master开始后台保存，收集所有对修改数据的命令。当后台保存完成，master会将这个数据文件传送到slave，然后保存在磁盘，加载到内存中；master接着发送收集到的所有的修改数据的命令，这好比一个流命令，是redis协议本身来实现的。 你可以自己通过远程登录来进行尝试，当服务器在做一些工作并发送同步命令的时候链接到redis端口，你将会看到大量的数据传输，然后收到的每个命令会会显示在远程登录的会话中。 当master和slave因一些故障当机时，slaves会自动的重链，如果master收到多个slave的同步请求，master会执行一个后台保存，以确保所有的slaves都是正常的。 当master和slave能够维持链接，就会有一个完整的同步进行。

配置 redis.conf

主机设置一个masterauth 密码,redis-cli运行如下指令

config set requirepass <password>

持久到配置文件：

requirepass <password>

从机

masterauth <password> slaveof <master_host_ip|master_host_name> <port>