redis的事务、主从复制、持久化

redis事务

和其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中， MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。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服务器了。

命令列表

multi	用于标记事务的开始，其后执行的命令都将被存入命令队列，直到执行EXEC时，这些命令才会被原子的 执行。
exec	执行在一个事务内命令队列中的所有命令，同时将当前连接的状态恢复为正常状态，即非事务状态。如 果在事务中执行了WATCH命令，那么只有当WATCH所监控的Keys没有被修改的前提下，EXEC命令才 能执行事务队列中的所有命令，否则EXEC将放弃当前事务中的所有命令。
discard	回滚事务队列中的所有命令，同时再将当前连接的状态恢复为正常状态，即非事务状态。如果WATCH命 令被使用，该命令将UNWATCH所有的Keys。

. 事务被正常执行
#在当前连接上启动一个新的事务
127.0.0.1:> multi
OK #执行事务中的第一条命令，从该命令的返回结果可以看出，该命令并没有立即执行，而是存于事务的命令队列 127.0.0.1:> incr t1

QUEUED

#又执行一个新的命令，从结果可以看出，该命令也被存于事务的命令队列 

127.0.0.1:> incr t2
QUEUED #执行事务命令队列中的所有命令，从结果可以看出，队列中命令的结果得到返回 127.0.0.1:> exec

) (integer)
) (integer)  #只有当提交事务后，在其他连接中才能看到变化

. 事务中存在失败的命令
#开启一个新的事务
127.0.0.1:> multi
OK
#设置键a的值为string类型的3
127.0.0.1:> set a
QUEUED #从键a所关联的值的头部弹出元素，由于该值是字符串类型，而lpop命令仅能用于List类型，因此在执行exec命 令时，该命令将会失败

127.0.0.1:> lpop a
QUEUED
#再次设置键a的值为字符串4
127.0.0.1:> set a
QUEUED #获取键a的值，以便确认该值是否被事务中的第二个set命令设置成功 

127.0.0.1:> get a

QUEUED

#从结果中可以看出，事务中的第二条命令lpop执行失败，而其后的set和get命令均执行成功，这一点是Redis的 事务与关系型数据库中的事务之间最为重要的差别
127.0.0.1:> exec
) OK

) (error) ERR Operation against a key holding the wrong kind of value ) OK
) ""

. 回滚事务 #为键t2设置一个事务执行前的值 127.0.0.1:> set t2 tt OK
#开启一个事务 127.0.0.1:> multi

主从复制Replication

在Redis中配置Master­Slave模式非常简单，Redis中主从复制的特点和优势:

). 同一个Master可以同步多个Slaves。
). Slave同样可以接受其它Slaves的连接和同步请求，可以有效的分载Master的同步压力，所以可以将Redis的

Replication架构视为图结构。
). Master Server是以非阻塞的方式为Slaves提供服务，所以在Master­Slave同步期间，客户端仍然可以提交查

询或修改请求。
). Slave Server同样是以非阻塞的方式完成数据同步，在同步期间，如果有客户端提交查询请求，Redis则返回

同步之前的数据。
). 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来

完成。即便如此，系统的伸缩性还是得到了很大的提高。
). Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。 

 

配置 步骤:

. 同时启动两个Redis服务器，可以考虑在同一台机器上启动两个Redis服务器，分别监听不同的端口，如 6379和6380

 将配置文件拷贝两份，并修改端口号 
启动服务器:

$ redis­server 6379.conf #master主服务器

$ redis­server 6380.conf #slave从服务器

. 连接slave服务器，并执行如下命令:

$ redis­cli ­p 6380 #连接从服务器，slave端口号为6380
127.0.0.1:6380> slaveof 127.0.0.1 6379 #配置主从关系，指定master的主机地址和端口号
OK 

上面的方式只是保证了在执行slaveof命令之后，redis6380 (redis_6380)重新启动之后，他们之间的复制关系将终止。

3.如果希望长期保证这两个服务器之间的Replication关系，可以在redis_6380的配置文件中做如下修改:

$ vi .conf
    slaveof 127.0.0.1
这样就可以保证Redis6380 Redis6379的Replication连接了。 

redis的持久化

Redis提供的持久化方式:

1. RDB

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

2. AOF 该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新

        构建数据库，以保证启动后数据库中的数据是完整的。

RDB

Redis Database:通过单文件的方式来持久化

RDB是默认的持久化方式，默认存储在启动redis服务器时所在当前目录下的dump.rdb文件中，一般都会修改
存储在一个固定的目录中

编辑配置文件:

 $ vi myredis.conf
　　

 #持久化文件的名称

dbfilename dump.rdb 

#持久化文件的默认目录，默认为执行redis­server命令时所在的目录 

#dir ./

#修改存储位置为一个固定的目录

 dir /home/soft01/software/dump/

持久化的时机:

1. 在数据库关闭时会持久化(需要注意的是在数据库宕机时不会生成，数据可能会丢失)

2. 满足特定条件时会持久化，编辑配置文件:

$ vi myredis.conf
save   #在900秒内，只要有1个key发生变化，就会dump持久化 
save
save  

优缺点:

缺点:可能会丢失数据
优点:效率比较高

AOF

Append Only File:通过操作日志的方式来持久化

编辑配置文件:

  $ vi myredis.conf

#开启aof模式的持久化

appendonly yes

#aof的持久化文件 

appendfilename "appendonly.aof" 

#每一秒进行一次持久化操作，可取值:always、everysec、no 

appendfsync everysec 

#持久化文件的目录，与RDB相同

dir /home/soft01/software/dump/

注:可以直接查看生成的appendonly.aof文件，可以认为是一个日志文件

优缺点:

缺点:效率比较差

优点:丢失数据量比较少