Redis 集群架构模式有哪几种？#
Redis 提供了三种集群模式：主从架构、哨兵集群、切片集群。
主从复制
主从复制是 Redis 高可用服务的最基础的保证，实现方案就是将从前的一台 Redis 服务器，同步数据到多台从 Redis 服务器上，即一主多从的模式，且主从服务器之间采用的是「读写分离」的方式。
主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。
也就是说，所有的数据修改只在主服务器上进行，然后将最新的数据同步给从服务器，这样就使得主从服务器的数据是一致的。
注意，主从服务器之间的命令复制是异步进行的。
具体来说，在主从服务器命令传播阶段，主服务器收到新的写命令后，会发送给从服务器。但是，主服务器并不会等到从服务器实际执行完命令后，再把结果返回给客户端，而是主服务器自己在本地执行完命令后，就会向客户端返回结果了。如果从服务器还没有执行主服务器同步过来的命令，主从服务器间的数据就不一致了。
所以，无法实现强一致性保证（主从数据时时刻刻保持一致），数据不一致是难以避免的。
哨兵集群
在使用 Redis 主从服务的时候，会有一个问题，就是当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复。
为了解决这个问题，Redis 增加了哨兵模式（Redis Sentinel），因为哨兵模式做到了可以监控主从服务器，并且提供主从节点故障转移的功能。
切片集群
当 Redis 缓存数据量大到一台服务器无法缓存时，就需要使用 Redis 切片集群（Redis Cluster ）方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，从而提高 Redis 服务的读写性能。
Redis Cluster 方案采用哈希槽（Hash Slot），来处理数据和节点之间的映射关系。在 Redis Cluster 方案中，一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中，具体执行过程分为两大步：
- 根据键值对的 key，按照 CRC16 算法计算一个 16 bit 的值。
- 再用 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽。
接下来的问题就是，这些哈希槽怎么被映射到具体的 Redis 节点上的呢？有两种方案：
- 平均分配： 在使用 cluster create 命令创建 Redis 集群时，Redis 会自动把所有哈希槽平均分布到集群节点上。比如集群中有 9 个节点，则每个节点上槽的个数为 16384/9 个。
- 手动分配： 可以使用 cluster meet 命令手动建立节点间的连接，组成集群，再使用 cluster addslots 命令，指定每个节点上的哈希槽个数。
为了方便你的理解，我通过一张图来解释数据、哈希槽，以及节点三者的映射分布关系。
上图中的切片集群一共有 2 个节点，假设有 4 个哈希槽（Slot 0～Slot 3）时，我们就可以通过命令手动分配哈希槽，比如节点 1 保存哈希槽 0 和 1，节点 2 保存哈希槽 2 和 3。
redis-cli -h 192.168.1.10 –p 6379 cluster addslots 0,1
redis-cli -h 192.168.1.11 –p 6379 cluster addslots 2,3然后在集群运行的过程中，key1 和 key2 计算完 CRC16 值后，对哈希槽总个数 4 进行取模，再根据各自的模数结果，就可以被映射到哈希槽 1（对应节点1） 和 哈希槽 2（对应节点2）。
需要注意的是，在手动分配哈希槽时，需要把 16384 个槽都分配完，否则 Redis 集群无法正常工作。
回答#
Redis 提供了三种集群模式：主从架构、哨兵集群、切片集群。
- 主从：选择一台作为主服务器，将数据同步多台从服务器上，构建一主多从的模式，主从之间读写分离。主服务器可读可写，发生写操作会同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令。主从服务器之间的命令复制是异步进行的，所以无法实现强一致性保证（主从数据时时刻刻保持一致）。
- 哨兵：当 Redis 的主从服务器出现故障宕机时，需要手动进行恢复，为了解决这个问题，Redis 增加了哨兵模式，哨兵监控主从服务器，并且提供主从节点故障转移的功能。
- 切片集群：当数据量大到一台服务器无法承载，需要使用Redis切片集群(Redis Cluster)方案，它将数据分布在不同的服务器上，以此来降低系统对单主节点的依赖，提高 Redis 服务的读写性能。
Redis主从复制过程是怎样的？#
Redis 集群支持的主从复制，数据同步主要有两种方法：一种是全量同步，一种是增量同步。
全量同步
刚开始搭建主从模式时，从机需要从主机上获取所有数据，这时就需要 Slave 将 Master 上所有的数据进行同步复制。复制的步骤为：
- 从服务器发送 SYNC 命令，链接主服务器；
- 主服务器收到 SYNC 命令后，进行存盘的操作，并继续收集后续的写命令，存储缓冲区；
- 存盘结束后，将对应的数据文件发送到 Slave 中，完成一次全量同步；
- 主服务数据发送完毕后，将进行增量的缓冲区数据同步；
- Slave 加载数据文件和缓冲区数据，开始接受命令请求，提供操作。
增量同步
从节点完成了全量同步后，就可以正式的开启增量备份。当 Master 节点有写操作时，都会自动同步到 Slave 节点上。Master 节点每执行一个命令，都会同步向 Slave 服务器发送相同的写命令，当从服务器接收到命令，会同步执行。
回答#
当从节点初次连接到主节点，或者掉线重连后进度落后较多时会进行一次全量数据同步。此时，主节点会生成 RDB 快照并传输给从节点，在此期间，主节点接受到的增量命令将会先写入 replication_buffer 缓冲区，等到从节点加载完 RDB 快照的数据后，再将缓冲区的命令传输给从节点，以此完成初次同步。
当从节点掉线重连后，如果进度落后的不多，将会进行增量同步。主节点内部维护了一个环形的固定大小的 repl_backlog_buffer 缓冲区，它用于记录最近传播的命令。其中，主节点和从节点会分别在该缓冲区维护一个 offset ，用于表示自己的写进度和读进度。当从节点掉线重连后，将会检查主节点和从节点 offset 之差是否小于缓冲区大小，如果确实小于，说明从节点同步进度落后不多，则主节点将该缓冲区中的两 offset 之间的增量命令发送给从节点，完成增量同步。
当主从节点完成初次同步后，将会建立长连接进行命令传播。简单的来说，就是每当主节点执行一条命令，它就会写入 replication_buffer 缓冲区，随后再将缓冲区的命令通过节点间的长连接发送给对应的从节点。
Redis 的主从复制模式有什么优缺点？#
回答#
主从复制的模式相对于单节点的好处在于，实行读写分离提高了系统的读写效率，提高了网站数据的读取加载速度。但是缺点是由于写数据主要在主节点上操作，主节点内存空间有限，并且主节点存在单点风险。
哨兵机制是什么？#
回答#
因为在主从架构中读写是分离的，如果主节点挂了，将没有主节点来响应客户端的写操作请求，也无法进行数据同步。哨兵作用是实现主从节点故障转移。哨兵会监测主节点是否存活，如果发现主节点挂了，会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。
哨兵机制的工作原理？#
回答#
判断节点是否存活
哨兵会周期性给所有主节点发送PING命令来判断其他节点是否正常运行。如果PING命令响应失败哨兵会将节点标记为主观下线，然后该哨兵会向其他节点发出投票命令，当票数达到设定的阈值之后这个主节点就被标记为客观下线。然后哨兵会从从节点中选择一个作为主节点。
投票
哨兵集群中会选择一个leader来负责主从切换，选举是一个投票过程：判断主节点为客观下线的是候选者，候选者向其他哨兵发送命令表示要成为leader，其他哨兵会进行投票，每个哨兵只有一票，可以投给自己或投给别人，但是只有候选者才能把票投给自己。候选者之后拿到半数以上的赞成票并且票数大于设置的阈值，就会成为leader。
选出新主节点
把网络状态不好的从节点给排除：先把已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点排除掉。接下来要对所有从节点进行三轮考察：优先级、复制进度、ID号。在进行每一轮考察的时候，哪个从节点优先胜出，就选择其作为新主节点：
第一轮考察：哨兵首先会根据从节点的优先级来进行排序，优先级的值越小排名越靠前。
第二轮考察：如果优先级相同，则查看复制的下标，哪个接收的复制数据多哪个就靠前。
第三轮考察：如果优先级和下标都相同，选择ID较小的那个。
更换主节点
选出新主节点之后，哨兵leader让已下线主节点属下的所有从节点指向新主节点。
通知客户的主节点已更换
客户端和哨兵建立连接后，客户端会订阅哨兵提供的频道。主从切换完成后，哨兵就会向 +switch-master 频道发布新主节点的 IP 地址和端口的消息，这个时候客户端就可以收到这条信息，然后用这里面的新主节点的 IP 地址和端口进行通信了。
将旧主节点变为从节点
继续监视旧主节点，当旧主节点重新上线时，哨兵集群就会向它发送SLAVEOF命令，让它成为新主节点的从节点。
Redis sentinel（哨兵）模式优缺点有哪些？#
回答#
Redis 哨兵的好处在于可以保证系统的高可用，各个节点可以对故障自动转移。但缺点是使用的主从模式，主节点单点风险高，主从切换过程可能会出现丢失数据的问题。
说说 Redis 哈希槽的概念？#
回答#
Redis 集群并没有使用一致性 hash，而是引入了哈希槽的概念。Redis 集群有 16384（2^14）个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。
哈希槽和Redis节点是如何对应的？#
在创建集群的时候，我们可以为cluster中每个节点，划分指责，也就是给他们分配负责的数据区间，这里Redis使用的是一个叫Hash槽的概念，即将数据分为了多个槽，每个节点负责一些槽。
redis-cli -p 7000 cluster addslots {0..5461}
redis-cli -p 7001 cluster addslots {5462..10922}
redis-cli -p 7002 cluster addslots {10923..16383}如果想自动平均分配，也可以使用 CLUSTER REBALANCE 命令。
回答#
主要有自动分配和手动分配两种方式。自动分配是集群创建或者节点添加减少时，Redis自动将哈希槽平均分配到集群节点上；手动分配是使用命令指定每个节点上面的哈希槽数目，使用手动分配时要把16384个槽位给分完，否则集群不会正常工作。
主从模式的同步过程#
Redis主从复制流程主要分为以下三个核心步骤：
连接协商阶段
从服务器向主服务器发送PSYNC命令，携带主服务器的runID和复制偏移量（offset）参数
主服务器响应从服务器，返回自身的runID和当前复制偏移量
从服务器接收并持久化存储这两个关键参数，为后续数据同步建立基础
数据全量同步阶段
主服务器执行BGSAVE生成RDB快照文件
从服务器接收RDB文件后，会先清空现有数据集，再加载RDB文件完成全量数据同步，为确保数据一致性，主服务器在此期间将新写入操作暂存至复制缓冲区（replication buffer）
增量同步阶段
主服务器将复制缓冲区中的写操作按顺序发送至从服务器
从服务器依次执行接收到的写命令，完成最终数据同步
至此，首次主从数据同步完整流程执行完毕，进入增量数据同步阶段，也就是Redis主节点利用缓冲区将写入操作持续同步给Redis从节点
回答#
主要分为建立连接协商、主从数据同步、发送新操作三个步骤，连接协商主要确定复制偏移量等关键数据，为同步建立基础；首次主从同步数据是通过RDB文件传递来同步，期间的命令是利用复制缓冲区同步，完成首次同步之后，后续写入操作持续同步给Redis从节点，保证增量数据也是同步的。
从服务重新上线之后，主服务器如何知道要将哪些增量数据发送给从服务器？#
这里主要要点明如何决策是增量同步还是全量同步，这个决策取决于读的数据是不是在repl_backlog_buffer中。
什么是repl_backlog_buffer？
repl_backlog_buffer是一个环形缓冲区，用于主从服务器断连后，从中找到差异的数据；replication offset标记缓冲区的同步进度。
回答#
网络断开从服务器重新上线之后，会发送自己的复制偏移量到主服务器，主服务器根据偏移量之间的差距判断要执行的操作：如果从服务器要读的数据在repl_backlog_buffer中，则采用增量复制；如果不在，采用全量复制。
Redis如何减少主从数据的不一致？#
Redis从节点会向主节点同步数据，但是同步总有延迟，有延迟就有一段时间的不一致，回答要点是如何减少不一致时间，或者对外屏蔽不一致的从节点数据。
回答#
为了优化Redis主从节点不一致的问题，可以采取以下措施：
- 同机房部署：将主从节点部署在同一机房，以降低网络延迟，减少数据同步的时间差。
- 外部监控程序：通过外部程序实时监控主从节点的复制进度。计算主从节点之间的复制进度差，如果复制进度差超过预设阈值，客户端将不再从该从节点读取数据，从而减少数据不一致对业务的影响，进度差阈值设置不宜太小，确保在主从同步延迟较高时，客户端仍能正常访问部分从节点。
主从模式是同步复制还是异步复制？#
搞清楚同步复制和异步复制的区别，就不难判断，Redis是异步复制。
同步复制 (Synchronous Replication)
定义：主服务器在执行写操作时，必须等待所有从服务器成功写入数据并返回确认后，才向客户端返回成功响应。
特点：
- 强一致性：主从数据完全一致，确保数据的可靠性。
- 高延迟：由于需要等待从服务器的响应，写操作的延迟较高。
- 可靠性高：即使主服务器宕机，从服务器也能提供完整的数据。
- 性能开销大：网络延迟或从服务器性能不足会拖慢整体性能。
适用场景：
- 对数据一致性要求极高的场景，如金融交易、支付系统。
- 允许较高延迟但对数据可靠性要求严格的场景。
异步复制 (Asynchronous Replication)
定义：主服务器执行写操作后，立即向客户端返回成功响应，而不等待从服务器的写入确认。数据复制在后台异步进行。
特点：
- 弱一致性：主从数据可能存在短暂的不一致（复制延迟）。
- 低延迟：主服务器无需等待从服务器，写操作响应速度快。
- 性能高：适合高并发、低延迟的场景。
- 可靠性较低：如果主服务器在数据复制完成前宕机，可能导致数据丢失。
适用场景：
- 对性能要求高、允许短暂数据不一致的场景，如社交网络、日志系统。
- 数据丢失风险可接受的场景。
回答#
异步复制。因为主节点收到写命令之后，先写到内部的缓冲区，然后再异步发送给从节点。这样做的好处是对主流程影响小，不干扰Redis的高性能。
