Redis 事务机制
参考：
1. [从面试被问到吐血，Redis事务的问题个个触及知识盲区，脸都绿了](https://zhuanlan.zhihu.com/p/156889090)
1. multi —— 开启事务
2.命令入队列
之后所有的命令都会放入事务队列中，并不会立刻执行。
如果客户端发送的命令为 EXEC，DISCARD 的其中一个，服务器会立刻执行这个命令。
对于其它命令，服务器并不会立刻执行，而是将这个命令放入一个事务队列中，然后向客户端返回 QUEUED 回复
3. exec —— 执行事务
4. DISCARD —— 放弃执行
Redis 的事务机制可以保证一致性和隔离性（watch 机制）。
持久性取决于是否开启持久化以及持久化机制，极端情况下还是无法保证。
原子性的情况比较复杂：
1. 命令入队时就报错，会放弃事务执行，保证原子性
2. 命令入队时没报错，实际执行时报错，不保证原子性
3. EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性
（使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。
使用 AOF 恢复实例后，事务操作不会再被执行，从而保证原子性。
只有当事务中使用的命令语法有误时，原子性得不到保证，在其它情况下，事务都可以原子性执行。
Redis 主从同步机制
参考：
1. [极客时间《Redis核心技术与实战》06 | 数据同步：主从库如何实现数据一致？](https://time.geekbang.org/column/article/272852)
2. [一文让你明白Redis主从同步](https://zhuanlan.zhihu.com/p/55532249)
主从模式是最简单的实现高可用的方案，核心就是主从同步。
Redis 的主从库同步的基本原理，总结来说，有三种模式：全量复制、基于长连接的命令传播，以及增量复制。
全量同步的原理如下：
1. 从服务器向主服务器发送 sync 命令
2. 收到 sync 命令后，主服务器执行 bgsave 命令，用来生成 rdb 文件，并在一个缓冲区中记录从现在开始执行的写命令。
3. bgsave 执行完成后，将生成的 rdb 文件发送给从服务器，用来给从服务器更新数据
4. 主服务器再将缓冲区记录的写命令发送给从服务器，从服务器执行完这些写命令后，此时的数据库状态便和主服务器一致了。
上面写的命令是 sync，但是在 Redis 2.8 版本之后已经使用 psync 来替代 sync 了，
原因是 sync 命令非常消耗系统资源，而 psync 的效率更高（可以根据需要增量同步）。
长连接复制：
长连接复制是主从库正常运行后的常规同步阶段。在这个阶段中，主从库之间通过命令传播实现同步。
增量复制：
当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，
同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。
repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
随着主库不断接收新的写操作，它在缓冲区中的写位置会逐步偏离起始位置，通常用偏移量来衡量这个偏移距离的大小，
对主库来说，对应的偏移量就是 master_repl_offset。
主库接收的新写操作越多，这个值就会越大。
同样，从库在复制完写操作命令后，它在缓冲区中的读位置也开始逐步偏移刚才的起始位置，
此时，从库已复制的偏移量 slave_repl_offset 也在不断增加。
正常情况下，这两个偏移量基本相等。
主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的 slave_repl_offset 发给主库，
主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。
在网络断连阶段，主库可能会收到新的写操作命令，所以，一般来说，master_repl_offset 会大于 slave_repl_offset。
此时，主库只用把 master_repl_offset 和 slave_repl_offset 之间的命令操作同步给从库就行。
主从模式下，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这需要人工干预，费事费力，还会造成一段时间内服务不可用。
这种方式并不推荐，实际生产中，优先考虑哨兵模式。
优缺点：
优点：
1. 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
2. Slave 同样可以接受其他 Slaves 的连接和同步请求，这样可以有效地分载 Master 的同步压力
缺点：
1. Redis 不具备自动容错和恢复功能，主从不可以自动切换
2. 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了系统的可用性
3. 较难支持在线扩容
Redis 哨兵
参考：
1. [极客时间《Redis核心技术与实战》07 | 哨兵机制：主库挂了，如何不间断服务？](https://time.geekbang.org/column/article/274483)
哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。
哨兵与哨兵之间通过 pub/sub 建立联系。
哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。
监控：
哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。
如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
如果检测的是从库，那么，哨兵简单地把它标记为“主观下线”就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。
但是，如果检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”，开启主从切换，因为主从切换开销很大，防止误判。
只有 N/2 + 1 的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”。
选主：
主库挂了以后，在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。
然后，再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。
筛选过程除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。
在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，就可以认为主从节点断连了。
如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。
打分过程分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。
由哪个哨兵执行主从切换：
任何一个实例只要自身判断主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。
接着，其他实例会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。
一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。
这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。
例如，现在有 5 个哨兵，quorum 配置的是 3，那么，一个哨兵需要 3 张赞成票，就可以标记主库为“客观下线”了。
这 3 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。
此时，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。
这个投票过程称为“Leader 选举”。在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：
第一，拿到半数以上的赞成票；
第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。
通知：
在执行通知任务时，哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。
同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。
每个哨兵实例会提供 pub/sub 机制，客户端可以从哨兵订阅消息。
哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。
客户端读取哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连接。
然后就可以在客户端执行订阅命令，来获取不同的事件消息。
优缺点：
优点：
1. 主从模式的所有优点
2. 主从可以自动切换，系统更健壮，可用性更高
缺点：
除了支持主从自动切换外的主从模式的所有缺点
Redis 集群
参考：
1. [【原创】为什么Redis集群有16384个槽](https://www.cnblogs.com/rjzheng/p/11430592.html)
从 Redis 3.0 开始，官方提供了一个名为 Redis Cluster 的方案，用于实现切片集群。
Redis Cluster 采用哈希槽（Hash Slot），来处理数据和实例之间的映射关系。
在 Redis Cluster 中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中。
为什么采用 16384？
1. 在 Redis 节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息。
如果槽位为 65536，这块的大小是 65536÷8÷1024=8kb，发送心跳信息的消息头达 8k，发送的心跳包过于庞大。
作者认为这样做不太值得。
2. 并且一般情况下一个 Redis 集群不会有超过 1000 个 master 节点，所以 16384 的槽位是个比较合适的选择。
具体的映射过程分为两大步：
1. 首先根据键值对的 key，按照 CRC16 算法计算一个 16bit 的值
2. 然后，再用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽
哈希槽和实例的对应：
部署 Redis Cluster 时，可以使用 cluster create 命令创建集群，此时，Redis 会自动把这些槽平均分布在集群实例上。
也可以使用 cluster meet 命令手动建立实例间的连接，形成集群，再使用 cluster addslots 命令，指定每个实例上的哈希槽个数。
当 16384 个 slot 都有节点在处理时，集群处于上线状态，反之只要有一个 slot 没有得到处理都会处理下线状态。
客户端如何定位数据？
当客户端请求键值对时，会先计算键所对应的哈希槽，然后给相应的实例发送请求。
在定位键值对数据时，它所处的哈希槽是可以通过计算得到的，这个计算可以在客户端发送请求时来执行。
知道哈希槽后，客户端如何知道哈希槽分布在哪个实例上？
Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。
当实例之间相互连接后，每个实例就有所有哈希槽的映射关系了。
客户端和集群实例建立连接后，实例就会把哈希槽的分配信息发给客户端。客户端收到哈希槽信息后，会把哈希槽信息缓存在本地。
Redis 集群间通信参用什么协议？
gossip 协议通信
在集群中，实例和哈希槽的对应关系并不是一成不变的，最常见的变化有两个：
1. 在集群中，实例有新增或删除，Redis 需要重新分配哈希槽
2. 为了负载均衡，Redis 需要把哈希槽在所有实例上重新分布一遍。
此时，实例可以通过相互传递消息，获得最新的哈希槽分配信息，但是，客户端是无法主动感知这些变化的。
这就会导致，它缓存的分配信息和最新的分配信息不一致。
Redis Cluster 采取重定向机制解决这个问题。
当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有对应的哈希槽，会给客户端返回 MOVED 响应结果，
结果中包含了新实例的访问地址。
如果此时，旧实例中的数据只有一部分迁移到了新实例，还有部分数据没有迁移，客户端会收到一条 ASK 报错信息。
代表这个哈希槽正在迁移。此时，客户端需要先给新实例发送一个 ASKING 命令（代表破例执行关于槽的命令一次）。
然后，客户端再向新实例发送 GET 命令，以读取数据。
故障发现和转移：
如果节点 A 向节点 B 发送 ping 消息，节点 B 没有在规定的时间内响应 pong，那么节点 A 会标记节点 B 为 pfail 疑似下线状态，
同时把 B 的状态通过消息的形式发送给其他节点，如果超过半数以上的节点都标记 B 为 pfail 状态，B 就会被标记为 fail 下线状态，
此时将会发生故障转移。
优先从复制数据较多的从节点选择一个成为主节点，并且接管下线节点的 slot，整个过程和哨兵非常类似，都是基于 Raft 协议做选举。
但是如果下线的主节点没有从节点，整个集群还是处于不可用的状态。
Redis Cluster 并不能保证数据的强一致性，在实际中集群在特定的条件下可能会丢失写操作，原因是集群采用异步复制。
Redis 中，sentinel 和 cluster 的区别和适用场景是什么？
哨兵是解决了 Redis 的高可用，而 cluster 则是解决了 Redis 的高并发。