Redis

Redis简述

简单说来，redis就是一个开源的基于内存的数据结构的存储器，它支持常见的各种各样的数据类型的存储，例如字符串，数组，集合，有序集合，hash等。它支持分布式的部署，平行扩容，master slave结构，可被用作缓存，或者数据库存储。

实际应用中，你可以把它当成一个中心化的数据结构存储引擎，有命令行，java，c++以及python的库可以直接与Redis server进行通信。例如你想存储一个班的学生，以学生学号为key，可以使用它。

Redis事务

首先Redis的命令是原子操作，一条命令不会被拆分，Redis中的事务同样具有数据库中事务的原子特性。事务中的命令要么全部执行，要么全部不执行。先使用MULTI开启事务，然后输入一连串的命令列表作为事务，最后输入EXEC一次性执行全部的事务命令。如果在EXEC之前，客户的断线，则事务命令一条也不会执行。EXEC是事务命令触发器。

redis的事务不支持回滚操作。事务返回的结果是个数组，用于表示事务中哥哥命令的执行情况，某些命令失败并不会影响什么，其他命令依然会正常处理。

Redis支持并发客户端的访问，当有一个key同时被多个客户端访问，原子性可能被破坏了，例如传统的增1的操作，同时两个操作发起增加1，结果可能是未定的。Redis支持CAS的原子访问（也即是compare-and-set），首先通过WATCH key命令来监控某一个键，只有当key没有被修改时候，事务才会被执行。

如下面代码所示，首先WATCH这个key的修改，只有在key没有被修改的时候，MULTI内部的事务才会被执行，val才会增加1，相当于实现了原子增加1的操作。

WATCH mykey

# 首先拿到Redis中存储的值并增1，便于事务中进行set
val = GET mykey
val = val + 1

MULTI
SET mykey $val
EXEC

Redis发布与订阅

这个特别容易理解，就是常见的发布与订阅模式。有人发布了消息，所有订阅了这个人的同学都会收到这条消息。

有两种订阅模式：

a. 订阅确定的名字

redis> SUBSCRIBE foo bar

b. 订阅模式匹配的名字

redis> PSUBSCRIBE news.*

使用这个发布和订阅做个聊天工具还是可以的。猜测的一个实现：好友之间全部两两订阅，A发送消息给B，A的全部好友（例如B，C，D）都会收到订阅消息。非B的好友收到消息后，会解析消息内容，发现目的是B，直接丢弃，只有B收到消息才会呈现。群消息的实现特别简单，群成员相当于订阅了群。

Redis主从复制

几个特性：

1. 主从异步复制

   从初次连接主，采用的是全量同步，即主将RDB文件发送给从，覆盖内存
   随后，采用增量同步，主将命令缓冲区的内容以命令的形式发送给从，这需要主记录着从的上次同步的进度，也就是命令ID标号。

2. 主从图结构

   主可以连接多个从，从也可以连接从

3. 主从复制过程

   1. 从每隔1秒向主PING一次，汇报进度（上次同步的位置）
   2. 主记录从上次PING的时间，并向从发送积压在缓存区命令列表

4. 主从读写模式

   主可读可写，从默认只读

5. 主从一致性和安全性

   • 由于采用异步复制，从有一定的不一致窗口（一般可认为是ms级别）。从一般可以在ms的时间范围将主的写操作更新到从
   • 主可以通过配置从的最大延迟min-slaves-max-lag，以及最小从数量 min-slaves-to-write，来保证数据的可靠性。也就是说，只有在所有从的延迟都小于最大延迟，以及连接的从数量大于最小数量，主才执行写入操作，否则返回客户端失败。

Redis数据持久化

当你不仅仅需要把Redis当作Cache来使用，还想把它当作Storage来使用的时候，数据持久化就派上了用场，只有数据被写入到持久存储（例如硬盘）中，才能预防由于各种故障带来的数据丢失。

Redis的持久化有两种方式：RDB和AOF，直观上来看这个和HDFS的FSImage（系统镜像）和EditLog（命令日志）同出一辙，也是很多高性能分布式系统常见的持久化容灾方式。

1. RDB持久化

   在Redis中，RDB是一个当前时刻的内存快照的紧凑版本，占用空间较少。它可以通过配置来实现定期生成，生成RDB的时间间隔通常较长（分钟-小时级别）。当Redis发生不可恢复的错误的时候，可以通过重新加载上一次的RDB文件也快速的恢复到上一次时刻，类似于系统还原点，但是这可能会丢失RDB一段时间的数据（也就是上次RDB文件生成到当前时刻）。

2. AOF持久化

   AOF是写操作命令的持久化，对于每个写操作，都将它追加到某一个文件中，它可以通过配置来决定fsync的时机（例如每隔1s，还是每条命令）。当系统故障后，可以读取AOF中的命令列表并进行回放命令来完整的恢复故障前的内存结构，这通常意味着它的恢复时间更长一些。另外AOF存储的是完整的命令列表，它相对于RDB来说体积更大，但是带来的好处是AOF的文件是可读的。如果你已经明确知道自己误操作了某一条命令，那么可以直接从AOF文件中删除此命令，再回放AOF文件，即可完成恢复。如果配置AOF为每隔1s来执行fsync操作，那AOF也有一定的脆弱窗口（前一秒的数据可能丢失），而配置为每条命令都fsync，这也意味着代价比较大，用户需要自己tradeoff。

---

• [1] http://doc.redisfans.com/index.html#
• [2] http://try.redis.io/