与大多数的NoSql不同，Redis是存在事务的，尽管它没有数据库那么强大。Redis的事务是使用MULTI-EXEC的命令组合，使用它可以提供两个重要的保证：
1. 事务是一个被隔离的操作，事务中的方法都会被Redis进行序列化并按顺序执行，事务在执行的过程中不会被其他客户端发生的命令所打断。
2. 事务是一个原子性的操作。要么全部成功，要么全部失败。
Redis使用事务会经过三个过程：
1. 开启事务。
2. 命令进入队列。
3. 执行事务。
| 命令 | 说明 | 备注 |
|
multi |
开启事务命令，之后的命令就进入队列，而不会马上被执行。 | 在事务生存期间，所有的Redis关于数据结构的命令都会入队。 |
| watch key1 [key2....] | 监听某些键，当被监听的键在事务执行前被修改，则事务会被回滚 | 使用乐观锁 |
| unwatch key1 [key2....] | 取消监听某些键。 | -- |
| exec | 执行事务，如果被监听的键没有被修改，则采用执行命令，否则就回滚命令。 | 在执行事务队列存储的命令前，Redis会检测被监听的键值有没有发生变化，如果没有则执行命令，否则就回滚事务。 |
| discard | 回滚事务 | 回滚进入队列的事务命令，之后就不能再用exec命令提交了。 |
Redis的基础事务
开启事务：multi，执行事务：exec。在他们中间采取进入队列的形式，exec的作用就是一次性发送队列里的命令去执行，而在执行这些命令的时候其他客户端不能再插入任何命令了，这就是Redis的事务机制。
注意：执行事务命令exec执行前，set和get都返回的是QUEUED。说明是放入了队列中，而不是执行，只有exec之后，队列中的内容才会被执行。
注意：如果使用了回滚操作，再使用exec就会报错了，因为discard命令已经取消了事务的命令，也就是说队列中没有要执行的命令了。所以报错了。
使用watch命令监控事务
在Redis中使用watch命令可以决定事务是执行还是回滚。一般而言，我们在multi命令之前使用watch命令监控某些键值对，然后使用multi命令开启事务，执行各类对数据结构进行操作的命令，这个时候这些命令就会进入队列。当Redis使用exec命令执行事务的时候，它首先会比对被watch监控的键值对，如果没有发生变化，那么它会执行事务中的命令，提交事务。如果发生变化，那么它不会执行任何事务中的命令，而去事务回滚。无论事务是否回滚，Redis都会去取消执行事务前的watch命令。
| 时刻 | 客户端 | 说明 |
| T1 | set key1 value1 | 初始化key1 |
| T2 | watch key1 | 监控key1的键值对 |
| T3 | multi | 开启事务 |
| T4 | set key2 value2 | 设置key2的值 |
| T5 | exec | 提交事务，Redis会在这个时间点检测key1的值在T2时刻后，有没有被其他命令修改过，如果没有，则提交事务去执行 |
流水线（pipelined）
发布订阅
超时命令
复制
尽管我们说Redis的性能很好，每秒支持10万次左右的读写，但是还是不能应对那些百万次请求/每秒甚至更多的情况，那么我们的解决思路就是多添加一些服务器来分担这些请求。
1. 主从同步基础概念
互联网系统一般都是以主从架构为基础的，所谓主从架构设计的思路大概是：
（1）多个服务器中只有一个主服务器，n个从服务器。主服务器负责写入数据，从服务器用于读取数据。
（2）同时主服务器不负责让外部程序读取数据，从服务器不写入数据，只负责同步主服务器的数据，并让外部程序读取数据。
（3）主服务器写入数据后，即刻将写入数据的命令发送给从服务器，从而使得主从数据同步。
（4）应用程序可以随机读取某一台从服务器的数据，这样就分担了读数据的压力。
（5）当从服务器不工作，不会影响整个系统，当主服务器不工作，可以在从服务器中选出一个服务器作为主服务器。
2. Redis主从同步的过程
（1）先保证主服务器的开启，之后从服务器通过命令或者重启配置项可以同步到主服务器。
（2）从服务器启动之后，读取同步的配置，根据配置决定是否使用当前数据响应客户端，然后发送SYNC命令。当主服务器接收到同步命令时，会执行bgsave命令备份数据，但是主服务器此时不会拒绝客户端的读/写请求，而是将写命令写入缓存区。从服务器未收到主服务器备份的快照文件的时候，会根据其配置决定使用现有数据响应客户端/拒绝。
（3）bgsave命令执行完了之后，开始向从服务器发送备份文件，这个时候从服务器就会丢弃所有的现有数据，开始载入发送过来的快照文件。
（4）当主服务器发送完备份文件后，从服务器就会执行这些写入命令。此时就会把bgsave执行之后的缓存区内的写命令也发送给从服务器，从服务器完成备份文件解析，就开始像往常一样，接收命令，等待命令写入。
（5）缓冲区的命令发送完成后，当主服务器执行第一条写命令后，就同时往服务器发送同步写命令，从服务器就跟主服务器保持一致了。而此时当从服务器完成主服务器发送的缓冲区命令后，就开始等待主服务器的命令了。
哨兵
Redis可以存在多个服务器，并且实现了主从复制的功能。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
哨兵的作用
1. 通过发送命令，让Redis返回运行状态。
2. 当哨兵检测到主服务器宕机，会将从服务器切换成主服务器，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。
现实中，我们常常使用多个哨兵对Redis服务器进行监控，而且哨兵之间也会互相监控，监控其他哨兵是否'活着'，这样就变成了多个哨兵模式。
故障切换的过程（failover）
1. 假设主服务器宕机。
2. 哨兵1先监测到这个结果，但是系统并不会马上进行failover操作，这里仅仅是哨兵1主观的认为主机不可用，这个现象被称为主观下线。
3. 当其他一定数量的哨兵也监测到了主机不可用，那么哨兵之间就会发起一次投票，投票的结果由一个哨兵发起，进行failover操作，切换成功后，通过发布订阅模式，让各个哨兵把自己监控的服务器实现切换主机，这个过程称为客观下线。
持续更新！！！