Redis 高级实用特性

主从复制redis 

主从复制配置和使用都非常简单。通过主从复制可以允许多个 slave server master server 相同的数据库副本。

redis 主从复制特点:

(1)、master 可以拥有多个 slave

(2)、多个 slave 可以连接同一个 master 外，还可以连接到其他 slave

(3)、主从复制不会阻塞 master，在同步数据时，master 可以继续处理 client 请求

(4)、提高系统的伸缩性

redis 主从复制过程:

当配置好 slave 后，slave 与 master 建立连接，然后发送 sync 命令。无论 《红丸出品》 http://weibo.com/u/2446082491重新连接，master 都会启动一个后台进程，将数据库快照保存到文件中，程会开始收集新的写命令并缓存。后台进程完成写文件后，master 就发送将文件保存到硬盘上，再加载到内存中，接着 master 就会把缓存的命令转master 将收到的写命令发送给 slave。如果 master 同时收到多个 slave 发来master 只会启动一个进程来写数据库镜像，然后发送给所有的 slave

如何配置

在从库的配置文件下进行如下配置：slaveof  主库的ip  主库的端口号。如：slaveof  192.168.1.1  6379 

事务控制

redis 对事务的支持目前还比较简单。redis 只能保证一个 client 发起的事务中的命令可以连续的执行，而中间不会插入其他client 的命令。 由于 redis 是单线程来处理所有 client 的请求的所以做到这点是很容易的。一般情况下 redis 在接受到一个 client 发来的命令后会立即处理并 返回处理结果，但是当一个 client 在一个连接中发出 multi 命令有，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到 exec 命令后，redis 会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给 client.然后此连接就 结束事务上下文。

简单事务控制

下面可以看一个例子

redis 127.0.0.1:6379> get age
"33"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set age 10
QUEUED
redis 127.0.0.1:6379> set age 20
QUEUED
redis 127.0.0.1:6379> exec
1) OK
2) OK
redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379>

从这个例子我们可以看到 2 个 set age 命令发出后并没执行而是被放到了队列中。调用 exec

后 2 个命令才被连续的执行，最后返回的是两条命令执行后的结果。

如何取消一个事务
我们可以调用 discard 命令来取消一个事务，让事务回滚。接着上面例子

redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set age 30
QUEUED
redis 127.0.0.1:6379> set age 40
QUEUED
redis 127.0.0.1:6379> discard
OK
redis 127.0.0.1:6379> get age
"20"
redis 127.0.0.1:6379>

可以发现这次 2 个 set age 命令都没被执行。discard 命令其实就是清空事务的命令队列并退

出事务上下文，也就是我们常说的事务回滚。

乐观锁

其实就是在数据库里加一个字段version，每次更新前都会把version取出来，例如我取出来一个version=1，然后进行加1，那么我的version=2，更新前会对比version，如果我的version比数据库里大，就可以更新，如果我的version不比数据库里的大，说明此时有人进行了更新，使得version增加了，那么不允许更新

在redis中，有一个watch操作，watch是用来监控某个key，最后执行时，如果发现它被改动了，整个事务就会失败。

redis 的事务实现是如此简单，当然会存在一些问题。第一个问题是 redis 只能保证事务的每个命令连续执行，但是如果事务中的一个命令失败了，并不回滚其他命令，比如使用的命令类型不匹配。下面将以一个实例的例子来说明这个问题:

redis 127.0.0.1:6379> get age
"30"
redis 127.0.0.1:6379> get name
"HongWan"
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> incr age
QUEUED
redis 127.0.0.1:6379> incr name
QUEUED
redis 127.0.0.1:6379> exec
1) (integer) 31
2) (error) ERR value is not an integer or out of range
redis 127.0.0.1:6379> get age
"31"
redis 127.0.0.1:6379> get name
"HongWan"
redis 127.0.0.1:6379>

从这个例子中可以看到，age 由于是个数字，那么它可以有自增运算，但是 name 是个字符串，无法对其进行自增运算，所以会报错，如果按传统关系型数据库的思路来讲，整个事务都会回滚，但是我们看到 redis 却是将可以执行的命令提交了，所以这个现象对于习惯于关系型数据库操作的朋友来说是很别扭的，这一点也是 redis 今天需要改进的地方。

持久化机制

1. snapshotting 方式

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为 dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照，下面是默认的快照保存配置save 900 1 #900 秒内如果超过 1 个 key 被修改，则发起快照保存save 300 10 #300 秒内容如超过 10 个 key 被修改，则发起快照保存save 60 10000，由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用 aof 持久化方式。

2. aof 方式

aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式时,redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认是 appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于 os 会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样 aof 方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉 redis 我们想要通过 fsync 函数强制 os 写入到磁盘的时机。

有三种方式如下

（默认是：每秒 fsync 一次）appendonly yes //启用 aof 持久化方式

# appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
# appendfsync no //完全依赖 os，性能最好,持久化没保证