问：Redis集群模式核心机制

1. 数据分片：数据被划分为16384个哈希槽（Hash Slot），每个节点负责一部分槽。键通过CRC16哈希后取模分配到对应槽。
2. 高可用：每个主节点有1个或多个从节点。主节点故障时，从节点通过选举（Raft协议）成为新主，接管槽。
3. 节点通信：节点间通过Gossip协议交换状态信息（如槽分配、节点健康状态），实现去中心化的故障检测。
4. 客户端访问：客户端首次随机连接一个节点，若键不在该节点槽中，返回MOVED错误并重定向。

问：Redis哨兵模式核心机制

1. 监控与故障转移：哨兵节点监控主从节点的健康状态。主节点故障时，哨兵通过投票选出新主，并通知从节点切换复制目标。
2. 故障判定：多数哨兵确认主节点不可达（需达到仲裁数）。如果单个哨兵认为主节点不可达则只属于主观下线。
3. 客户端通知：客户端通过订阅哨兵的+switch-master事件感知主节点变更。

问：两者搭建方式的区别

集群：

1. 配置节点：启动多个Redis实例（至少3主3从），每个节点开启集群模式。
2. 创建集群：使用redis-cli --cluster create命令初始化槽分配。

哨兵：

1. 配置主从：启动主节点和多个从节点。
2. 配置哨兵：至少3个哨兵节点，监控主节点。
3. 启动哨兵。

问：集群和哨兵对比

集群：

1. 数据量超过单机内存，需分片存储。
2. 高并发场景，需横向扩展读写能力。
3. 接受较高的运维复杂度。

哨兵：

1. 数据量小，单机内存足够。
2. 需要快速实现高可用，无需分片。
3. 希望运维简单，团队熟悉主从架构。

问：Redis的 主从复制延迟导致的数据不一致如何处理？

1. 区分场景容忍最终一致性：非关键信息，读操作走从节点，牺牲部分一致性换取高可用和性能。关键信息所有读写操作强制走主节点（或通过路由规则标记关键业务），避免读到旧数据。
2. 架构设计降低影响：关键操作完成后，后续几次读请求强制路由到主节点，通过TTL控制回源时间。或者记录写入时间戳，例如写完10秒内只允许从主节点读取。
3. 通过配置提高同步可靠性：比如减少等待时间提高同步频率。再比如确保主节点至少有一个从节点完成同步后才确认写操作。甚至使用WAIT命令，在写操作后强制执行同步，等待N个从节点确认（慎用：WAIT会阻塞客户端，大幅降低吞吐量，仅适用于强一致性且低并发的场景）。
4. 加入版本号容错：写入数据时携带版本号（如时间戳或自增ID），读操作校验从节点数据版本，若不一致则降级读主。
5. 强一致性方案：对一致性要求极高的场景，结合Redlock算法实现分布式锁，确保操作原子性。但性能损耗较大。