redis事务
和其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中， MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。Redis中事务的特征:
1). 在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任 何服务，从而保证了事物中的所有命令被原子的执行。
2). 和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执 行。
3). 我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行
4). 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会 被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务 器执行。
5). 当使用AppendOnly模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写 入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁 盘，而另外一部分数据却已经丢失。Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问 题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redischeckaof工具，该 工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启 动Redis服务器了。
|
multi |
用于标记事务的开始，其后执行的命令都将被存入命令队列，直到执行EXEC时，这些命令才会被原子的 执行。 |
|
exec |
执行在一个事务内命令队列中的所有命令，同时将当前连接的状态恢复为正常状态，即非事务状态。如 果在事务中执行了WATCH命令，那么只有当WATCH所监控的Keys没有被修改的前提下，EXEC命令才 能执行事务队列中的所有命令，否则EXEC将放弃当前事务中的所有命令。 |
|
discard |
回滚事务队列中的所有命令，同时再将当前连接的状态恢复为正常状态，即非事务状态。如果WATCH命 令被使用，该命令将UNWATCH所有的Keys。 |
1. 事务被正常执行 #在当前连接上启动一个新的事务 127.0.0.1:6379> multi OK #执行事务中的第一条命令，从该命令的返回结果可以看出，该命令并没有立即执行，而是存于事务的命令队列 127.0.0.1:6379> incr t1 QUEUED #又执行一个新的命令，从结果可以看出，该命令也被存于事务的命令队列
127.0.0.1:6379> incr t2 QUEUED #执行事务命令队列中的所有命令，从结果可以看出，队列中命令的结果得到返回 127.0.0.1:6379> exec 1) (integer) 1 2) (integer) 1 #只有当提交事务后，在其他连接中才能看到变化 2. 事务中存在失败的命令 #开启一个新的事务 127.0.0.1:6379> multi OK #设置键a的值为string类型的3 127.0.0.1:6379> set a 3 QUEUED #从键a所关联的值的头部弹出元素，由于该值是字符串类型，而lpop命令仅能用于List类型，因此在执行exec命 令时，该命令将会失败 127.0.0.1:6379> lpop a QUEUED #再次设置键a的值为字符串4 127.0.0.1:6379> set a 4 QUEUED #获取键a的值，以便确认该值是否被事务中的第二个set命令设置成功
127.0.0.1:6379> get a QUEUED #从结果中可以看出，事务中的第二条命令lpop执行失败，而其后的set和get命令均执行成功，这一点是Redis的 事务与关系型数据库中的事务之间最为重要的差别 127.0.0.1:6379> exec 1) OK 2) (error) ERR Operation against a key holding the wrong kind of value 3) OK 4) "4" 3. 回滚事务 #为键t2设置一个事务执行前的值 127.0.0.1:6379> set t2 tt OK #开启一个事务 127.0.0.1:6379> multi
主从复制Replication
在Redis中配置MasterSlave模式非常简单，Redis中主从复制的特点和优势:
1). 同一个Master可以同步多个Slaves。 2). Slave同样可以接受其它Slaves的连接和同步请求，可以有效的分载Master的同步压力，所以可以将Redis的 Replication架构视为图结构。 3). Master Server是以非阻塞的方式为Slaves提供服务，所以在MasterSlave同步期间，客户端仍然可以提交查 询或修改请求。 4). Slave Server同样是以非阻塞的方式完成数据同步，在同步期间，如果有客户端提交查询请求，Redis则返回 同步之前的数据。 5). 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来 完成。即便如此，系统的伸缩性还是得到了很大的提高。 6). Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。
配置 步骤:
1. 同时启动两个Redis服务器，可以考虑在同一台机器上启动两个Redis服务器，分别监听不同的端口，如 6379和6380 将配置文件拷贝两份，并修改端口号
启动服务器:
$ redisserver 6379.conf #master主服务器
$ redisserver 6380.conf #slave从服务器
2. 连接slave服务器，并执行如下命令:
127.0.0.1:6380> slaveof 127.0.0.1 6379 #配置主从关系，指定master的主机地址和端口号 OK
上面的方式只是保证了在执行slaveof命令之后，redis6380 (redis_6380)重新启动之后，他们之间的复制关系将终止。 3.如果希望长期保证这两个服务器之间的Replication关系，可以在redis_6380的配置文件中做如下修改: $ vi 6380.conf slaveof 127.0.0.1 6379 这样就可以保证Redis6380 Redis6379的Replication连接了。
redis的持久化
Redis提供的持久化方式:
-
RDB
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
-
AOF 该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新
构建数据库，以保证启动后数据库中的数据是完整的。
RDB
Redis Database:通过单文件的方式来持久化
RDB是默认的持久化方式，默认存储在启动redis服务器时所在当前目录下的dump.rdb文件中，一般都会修改 存储在一个固定的目录中
编辑配置文件:
$ vi myredis.conf
#持久化文件的名称
dbfilename dump.rdb
#持久化文件的默认目录，默认为执行redisserver命令时所在的目录
#dir ./#修改存储位置为一个固定的目录
dir /home/soft01/software/dump/
持久化的时机:
1. 在数据库关闭时会持久化(需要注意的是在数据库宕机时不会生成，数据可能会丢失)
2. 满足特定条件时会持久化，编辑配置文件:
$ vi myredis.conf save 900 1 #在900秒内，只要有1个key发生变化，就会dump持久化
save 300 10 save 60 10000
优缺点:
缺点:可能会丢失数据 优点:效率比较高
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文件，可以认为是一个日志文件
优缺点:
缺点:效率比较差
优点:丢失数据量比较少