nosql:粗谈redis

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>