介绍一下redis的高可用方案
主从复制(基础高可用)✅
这是所有高可用方案的基石,核心解决数据备份和读写分离问题。
核心架构

工作原理
- 从节点启动后,向主节点发送
psync命令 - 首次连接:主节点执行全量复制(生成 rdb 文件发送给从节点)
- 后续连接:主节点执行增量复制(只发送偏移量之后的命令)
优缺点
- ✅ 优点:实现简单,读能力线性提升,数据有备份
- ❌ 缺点:不能自动故障转移,主节点挂了需要手动切换;单主写能力瓶颈
适用场景
- 测试环境、小流量业务(qps < 1000)
- 只需要读写分离和数据备份的场景
哨兵模式(sentinel)🛡️
在主从复制基础上,解决自动故障转移问题,是中小流量生产环境最常用的方案。
三大核心功能
- 监控:持续检测主从节点是否正常运行
- 选主:主节点故障时,自动从从节点中选举新主
- 通知:将故障转移结果通知客户端和其他节点
核心架构

故障转移流程
- 单个哨兵发现主节点不可达 → 主观下线
- 超过半数哨兵确认主节点不可达 → 客观下线
- 哨兵集群选举出一个领导者哨兵
- 领导者哨兵从从节点中选举新主节点
- 更新配置,通知客户端,旧主节点变为从节点
优缺点
- ✅ 优点:自动故障转移,高可用,运维简单
- ❌ 缺点:不能水平扩展,单主写能力瓶颈;哨兵集群本身也需要高可用
适用场景
- 中小流量生产环境(qps < 10000)
- 写压力不大,读压力较大的业务
redis cluster 集群模式(分片高可用)⚡
解决单节点写能力瓶颈和水平扩展问题,是大流量生产环境的标准方案。
核心概念:16384 个哈希槽
- redis cluster 将所有数据映射到 16384 个哈希槽中
- 每个主节点负责一部分哈希槽
- 客户端通过
crc16(key) % 16384计算 key 所在的槽,直接连接对应节点
核心架构

故障转移机制
- 每个节点都监控其他节点的状态
- 当某个主节点故障时,它的从节点会自动晋升为新主节点
- 集群自动更新哈希槽映射,客户端通过moved重定向到新节点
优缺点
- ✅ 优点:线性水平扩展,写能力和读能力都能线性提升;自动故障转移
- ❌ 缺点:运维复杂;不支持跨槽的多键操作(如mget、mset);数据迁移有短暂影响
适用场景
- 大流量高并发生产环境(qps > 10000)
- 数据量超过单节点内存容量的业务
三大核心方案对比表 📊
| 方案 | 最小节点数 | 故障转移 | 水平扩展 | 写能力 | 读能力 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|---|---|---|
| 主从复制 | 2 | ❌ 手动 | ❌ 不支持 | 单主瓶颈 | 线性提升 | 低 | 测试环境、小流量 |
| 哨兵模式 | 5(3 哨兵 + 2 主从) | ✅ 自动 | ❌ 不支持 | 单主瓶颈 | 线性提升 | 中 | 中小流量生产 |
| redis cluster | 6(3 主 3 从) | ✅ 自动 | ✅ 线性扩展 | 线性提升 | 线性提升 | 高 | 大流量高并发 |
企业级进阶优化与云原生方案 💡
- 读写分离优化:使用客户端分片或代理(如 twemproxy、codis)实现更灵活的读写分离
- 持久化策略:主节点关闭 rdb,从节点开启 rdb+aof 混合持久化,平衡性能和数据安全
- 慢查询监控:定期清理慢查询日志,设置合理的超时时间
- 云原生方案:在 k8s 环境中使用 redis operator(如 redis cluster operator),实现自动化部署、扩缩容和故障转移
- 云厂商托管:对于核心业务,建议使用阿里云 redis、腾讯云 redis 等托管服务,省心又稳定
面试加分总结 ✨
在实际项目中,我一般会根据业务阶段和流量规模来选择合适的方案:
- 项目初期:主从复制 + 哨兵,运维简单,成本低
- 业务增长期:当单主写能力达到瓶颈时,迁移到 redis cluster
- 云原生环境:优先使用 redis operator,自动化运维效率更高
- 核心业务:使用云厂商托管 redis,提供 99.99% 以上的可用性
核心代码与技术亮点实现 💻
1 jedis 连接哨兵集群(生产级配置)
import redis.clients.jedis.jedis;
import redis.clients.jedis.jedissentinelpool;
import java.util.hashset;
import java.util.set;
public class redissentinelconfig {
// 技术亮点1:单例模式+双重检查锁,保证连接池唯一
private static volatile jedissentinelpool jedissentinelpool;
public static jedissentinelpool getjedissentinelpool() {
if (jedissentinelpool == null) {
synchronized (redissentinelconfig.class) {
if (jedissentinelpool == null) {
// 哨兵节点地址集合
set<string> sentinels = new hashset<>();
sentinels.add("192.168.1.10:26379");
sentinels.add("192.168.1.11:26379");
sentinels.add("192.168.1.12:26379");
// 技术亮点2:精细化连接池配置,避免连接泄漏
jedissentinelpool = new jedissentinelpool(
"mymaster", // 主节点名称
sentinels,
"password123", // redis密码
2000, // 连接超时
100, // 最大连接数
10, // 最小空闲连接数
30000 // 连接最大空闲时间
);
}
}
}
return jedissentinelpool;
}
// 使用示例
public static void main(string[] args) {
try (jedis jedis = getjedissentinelpool().getresource()) {
jedis.set("key", "value");
system.out.println(jedis.get("key"));
}
}
}2 spring boot 集成 redis cluster(lettuce 客户端)
import org.springframework.context.annotation.bean;
import org.springframework.context.annotation.configuration;
import org.springframework.data.redis.connection.redisclusterconfiguration;
import org.springframework.data.redis.connection.lettuce.lettuceconnectionfactory;
import org.springframework.data.redis.core.redistemplate;
import org.springframework.data.redis.serializer.stringredisserializer;
@configuration
public class redisclusterconfig {
@bean
public lettuceconnectionfactory redisconnectionfactory() {
redisclusterconfiguration clusterconfig = new redisclusterconfiguration();
// 集群节点地址
clusterconfig.clusternode("192.168.1.20", 6379);
clusterconfig.clusternode("192.168.1.21", 6379);
clusterconfig.clusternode("192.168.1.22", 6379);
clusterconfig.setpassword("password123");
// 技术亮点3:开启集群重定向自动跟随
clusterconfig.setmaxredirects(3);
return new lettuceconnectionfactory(clusterconfig);
}
@bean
public redistemplate<string, object> redistemplate(lettuceconnectionfactory connectionfactory) {
redistemplate<string, object> template = new redistemplate<>();
template.setconnectionfactory(connectionfactory);
// 技术亮点4:使用string序列化器,避免默认jdk序列化的乱码问题
template.setkeyserializer(new stringredisserializer());
template.setvalueserializer(new stringredisserializer());
template.afterpropertiesset();
return template;
}
}3 技术亮点:自定义 redis cluster 哈希标签路由
解决 redis cluster 不支持跨槽多键操作的核心方案
/**
* 技术亮点:自定义哈希标签工具类
* 将相同业务的key强制路由到同一个哈希槽,支持mget/mset等多键操作
*/
public class redishashtagutil {
// 哈希标签分隔符
private static final string hash_tag_start = "{";
private static final string hash_tag_end = "}";
/**
* 生成带哈希标签的key
* @param businessid 业务id(如用户id、订单id)
* @param keysuffix key后缀
* @return 带哈希标签的key
*/
public static string generatekey(string businessid, string keysuffix) {
return hash_tag_start + businessid + hash_tag_end + ":" + keysuffix;
}
// 使用示例
public static void main(string[] args) {
// 同一个用户的所有key都会路由到同一个哈希槽
string userinfokey = generatekey("user123", "info");
string userorderkey = generatekey("user123", "orders");
string usercartkey = generatekey("user123", "cart");
// 现在可以安全地执行mget操作
// redistemplate.opsforvalue().multiget(arrays.aslist(userinfokey, userorderkey, usercartkey));
}
}4 技术亮点:主从切换时的客户端重试机制
import org.springframework.retry.annotation.backoff;
import org.springframework.retry.annotation.retryable;
import org.springframework.stereotype.component;
import redis.clients.jedis.exceptions.jedisconnectionexception;
@component
public class redisretryservice {
/**
* 技术亮点:使用spring retry实现主从切换时的自动重试
* 当发生连接异常时,最多重试3次,每次间隔1秒
*/
@retryable(
value = jedisconnectionexception.class,
maxattempts = 3,
backoff = @backoff(delay = 1000, multiplier = 2)
)
public string getwithretry(string key) {
return redistemplate.opsforvalue().get(key);
}
}技术难点与解决方案汇总 🛠️
| 技术难点 | 问题描述 | 根本原因 | 解决方案 |
|---|---|---|---|
| 主从复制数据不一致 | 从节点数据比主节点旧,读取到脏数据 | 主从同步有延迟;网络抖动导致增量复制中断 | 1. 监控主从延迟(info replication中的lag字段)2. 关键业务强制读主节点3. 开启repl-disable-tcp-nodelay减少延迟 |
| 哨兵模式脑裂问题 | 网络分区导致出现两个主节点,数据丢失 | 哨兵集群无法达成共识;旧主节点恢复后继续接收写请求 | 1. 配置min-replicas-to-write 1(至少 1 个从节点确认才允许写)2. 配置min-replicas-max-lag 10(从节点延迟超过 10 秒拒绝写)3. 哨兵节点数量必须为奇数,且至少 3 个 |
| redis cluster 跨槽操作 | 执行mget/mset/ 事务时抛出crossslot异常 | 不同 key 映射到不同哈希槽,集群不支持跨槽操作 | 1. 使用哈希标签将相关 key 路由到同一个槽(推荐)2. 客户端拆分多键操作,分别执行后合并结果3. 使用代理层(如 codis)自动处理跨槽操作 |
| 大集群数据迁移 | 扩容 / 缩容时数据迁移慢,影响业务 | 全量复制 rdb 文件大;迁移过程中阻塞节点 | 1. 采用增量迁移方式,先迁移全量数据,再同步增量命令2. 低峰期执行迁移操作3. 限制迁移速度(cluster-migration-barrier) |
| 主从切换请求丢失 | 主节点故障时,未同步到从节点的写请求丢失 | redis 异步复制机制,主节点写成功后立即返回客户端 | 1. 开启wait命令,等待至少 n 个从节点确认后再返回2. 业务层实现幂等性,允许重复请求3. 核心业务使用强一致性方案(如 redis 7.0 的 waitaof) |
| 缓存雪崩 | 大量缓存同时过期,数据库压力骤增 | 缓存过期时间设置相同;redis 集群整体宕机 | 1. 给缓存过期时间添加随机值(±5 分钟)2. 搭建 redis 集群保证高可用3. 服务降级和熔断机制 |
面试加分总结 ✨
以上就是我对 redis 高可用方案的完整理解。在实际项目中,我不仅掌握了这四种核心方案的原理和部署,还解决了很多生产环境中的实际问题,比如脑裂问题、跨槽操作问题和主从切换数据丢失问题。
我认为 redis 高可用的核心不是简单地搭建集群,而是根据业务特点选择合适的方案,并做好监控和应急预案。比如对于金融支付业务,我会优先保证数据一致性,开启wait命令和强一致复制;对于电商秒杀业务,我会优先保证性能,使用 redis cluster 分片集群,并做好缓存降级。
🎤 面试现场实录
🙋♂️ 面试官:你好,今天我们聊一道场景设计题:介绍一下你对 redis 高可用方案的理解,以及你们项目中是怎么用的? 不用紧张,想到哪说到哪,我来顺着问。
🧱 主从复制 —— 地基
👨💻 候选人:
好的,我从最基础的开始讲。如果只部署单个 redis,它一旦挂了业务就全停,所以第一步我们一定会做主从复制。
架构很简单:一个 master 负责处理写请求,挂一或多个 slave,slave 主要负责读请求,同时异步从 master 同步数据。这样至少数据有了多副本,不至于单点丢失。
🙋♂️ 面试官:
嗯,那这算高可用吗?
👨💻 候选人:
严格来说不算,它只是数据冗余。因为 master 挂了之后,slave 没法自动接管,需要手动敲 slaveof no one 命令把一台从库提成主库。这个过程运维介入慢,业务中断时间长。所以主从复制只是地基,高可用得在这个基础上再加东西。

🙋♂️ 面试官:
明白,那你们怎么解决自动切换的问题?
🛡️ 哨兵 sentinel —— 自动容灾
👨💻 候选人:
我们在主从之上部署哨兵集群。哨兵本质上也是一个 redis 进程,只是它不存数据,专门盯着主节点和从节点的健康状态。
整个机制我分几步说:
- 监控:每个哨兵定期 ping 主从节点。
- 主观下线:如果一个哨兵发现主节点 ping 不通了,会认为它“主观下线”。
- 客观下线:为了避免网络抖动误判,必须达到配置的
quorum数量(比如3个哨兵里至少2个)都认为它挂了,才会真正判定“客观下线”,触发故障转移。 - 选举 leader:哨兵集群内部用类似 raft 的机制选出一个哨兵领导者来执行切换。
- 切换:leader 从健康的从库中选一个提升为新主,改配置,然后通知其他从库去复制新主。最关键的是,它还会通过 pub/sub 机制通知客户端新主地址。
这样,整个切换过程几秒到十几秒,运维完全不用干预。我们很多中小型项目,用哨兵方案就足够了。😊

🙋♂️ 面试官:
不错,那你遇到过脑裂的问题吗?怎么解决的?
👨💻 候选人:
遇到过,这是个经典坑。比如网络分区,旧主其实没死,只是和哨兵失联了,哨兵选出了新主,这时就存在两个 master 同时接收写入。等网络恢复,旧主的数据会被覆盖丢掉。
我们的解决办法是在 master 上配置两个参数:
min-replicas-to-write 1:至少要有1个从库连接。min-replicas-max-lag 10:从库复制延迟不能超过10秒。
如果达不到这个条件,旧主就拒绝写入,这样它自己就发现“我可能被孤立了”,主动放弃写入,避免脑裂数据冲突。虽然会牺牲一部分可用性,但保证了数据一致。🛡️
🙋♂️ 面试官:
那对于异步复制导致的数据丢失,你们怎么看?
👨💻 候选人:
确实,主挂时还没来得及传给从库的数据就丢了。我们一般这样取舍:如果对一致性要求极高(比如库存扣减),就用 redis 的 wait 命令强制同步复制一定数量的从库再返回,但这会增加延迟。大部分缓存场景我们接受少量丢失,靠持久化兜底,业务上做好最终一致性的补偿逻辑。
🌐 redis cluster —— 海量数据与流量
🙋♂️ 面试官:
哨兵方案听起来很成熟了,那为什么后面还要用 redis cluster?
👨💻 候选人:因为哨兵只能解决高可用,但解决不了数据量大****和写流量高的问题。所有写请求都还压在一个 master 上,存储也受单机内存限制。当数据量上了百 g、tps 上万,哨兵方案就吃力了,这时就需要 redis cluster,它既高可用,又能水平扩展。
核心设计我讲三点:
- 分片:把整个数据空间划分成 16384 个哈希槽(slot),每个主节点负责一部分槽。key 通过
crc16(key) % 16384确定属于哪个槽,然后去对应节点处理。 - 去中心化:所有节点之间用 gossip 协议互相交换状态,没有中心代理,每个节点都知道整个集群的拓扑。
- 内建故障转移:每个主节点可以挂至少一个从节点。当某个主挂了,它的从节点会发起选举(由集群中其他主节点投票),晋升为新主,这个过程不依赖任何外部哨兵,集群自己搞定。

🙋♂️ 面试官:
那客户端怎么知道去哪个节点找数据?
👨💻 候选人:
这就要用智能客户端,像 java 里的 lettuce 或 jediscluster。它们会缓存槽与节点的映射关系,计算好槽后直接连目标节点。如果因为扩缩容槽迁移了,节点会返回 moved 错误码和新节点地址,客户端会自动更新映射并重试,对业务几乎透明。👍
🙋♂️ 面试官:
cluster 有什么限制?
👨💻 候选人:
最主要的是多 key 操作限制,比如 mget、事务,要求所有 key 必须在同一个槽。我们可以用 {} 强制让部分 key 落到同一槽,但不能滥用。另外跨节点的事务不支持,所以我们会在设计 key 时尽量规避这种需求。
📊 对比与选型
🙋♂️ 面试官:
最后你帮我总结一下,什么时候选什么方案?
👨💻 候选人:
我画个表吧,一目了然:
| 方案 | 自动故障转移 | 写扩展 | 运维复杂度 | 适合场景 |
|---|---|---|---|---|
| 主从 | ❌ 手动 | ❌ | ⭐ | 测试、对可用性无要求 |
| 哨兵 sentinel | ✅ 自动 | ❌ (只有读扩展) | ⭐⭐ | 中小型项目首选,数据量不大但必须自动容灾 |
| cluster | ✅ 自动 | ✅ (读写都可扩展) | ⭐⭐⭐ | 大流量/海量数据,互联网核心链路 |
我们一般的路径是:项目初期用哨兵,等数据量或写入压力上来了,再平滑迁移到 cluster。迁移前会在备集群先建好 cluster,用双写或同步工具切流。
☕ java 研发配合点
🙋♂️ 面试官:
很好,最后说下你们 java 客户端怎么配合这些方案?
👨💻 候选人:
- 哨兵模式:我们用 lettuce 的
redissentinelclient或 jedissentinelpool,只需配置哨兵地址,框架自动发现并连接主库,主从切换时客户端能收到通知并重连。 - cluster 模式:直接用 spring boot 默认的 lettuce,开启
spring.redis.cluster.nodes配置,它会自动处理moved、ask重定向,底层长连接会跟 gossip 拓扑变化动态刷新。 - 另外,不管哪种模式,我们都会开启 rdb + aof 混合持久化,保证节点重启后能快速恢复数据,避免空节点加入集群导致数据迁移的灾难。🔥
💻 核心代码 & 技术亮点
🙋♂️ 面试官:
刚才你提到用 lettuce 连接哨兵和 cluster,能挑几个关键代码段展示一下吗?主要看看你们的连接配置和故障转移时的处理。
👨💻 候选人:
没问题,我先贴一段生产环境简化版,用 spring boot + lettuce 连接 哨兵模式 的配置和自愈处理。
1️⃣ 哨兵模式:自动发现主库、切换重连
@configuration
public class redissentinelconfig {
@bean
public lettuceconnectionfactory lettuceconnectionfactory() {
redissentinelconfiguration sentinelconfig =
new redissentinelconfiguration()
.master("mymaster") // 哨兵监控的主库名
.sentinel("192.168.1.10", 26379)
.sentinel("192.168.1.11", 26379)
.sentinel("192.168.1.12", 26379);
sentinelconfig.setpassword(redispassword.of("sentinel_pass"));
lettuceclientconfiguration clientconfig =
lettuceclientconfiguration.builder()
.readfrom(readfrom.replica_preferred) // 优先从副本读,分担压力
.commandtimeout(duration.ofseconds(2))
.build();
return new lettuceconnectionfactory(sentinelconfig, clientconfig);
}
@bean
public redistemplate<string, object> redistemplate(
lettuceconnectionfactory factory) {
redistemplate<string, object> template = new redistemplate<>();
template.setconnectionfactory(factory);
template.setkeyserializer(new stringredisserializer());
template.setvalueserializer(new genericjackson2jsonredisserializer());
return template;
}
}🔍 技术亮点:
readfrom.replica_preferred让读请求优先落到从库,仅当从库不可用时才读主库,实现读写分离且不丢可用性。- 只需配置哨兵节点,客户端在背后会自动订阅哨兵频道,主从切换后 1~3 秒内就能刷新拓扑,完全无感。
commandtimeout设得短一点,防止在故障切换时请求长时间卡死。
2️⃣ cluster 模式:智能重定向 & 管道优化
@configuration
public class redisclusterconfig {
@bean
public lettuceconnectionfactory clusterconnectionfactory() {
redisclusterconfiguration clusterconfig =
new redisclusterconfiguration(arrays.aslist(
"192.168.2.10:6379",
"192.168.2.11:6379",
"192.168.2.12:6379"
));
clusterconfig.setpassword("cluster_pass");
// 开启自适应刷新,集群拓扑变化时自动感知
clustertopologyrefreshoptions refreshoptions =
clustertopologyrefreshoptions.builder()
.enableperiodicrefresh(duration.ofseconds(30)) // 每30秒检查一次
.enablealladaptiverefreshtriggers() // 检测到moved/ask等自动立即刷新
.build();
lettuceclientconfiguration clientconfig =
lettuceclientconfiguration.builder()
.clientoptions(clusterclientoptions.builder()
.topologyrefreshoptions(refreshoptions)
.build())
.build();
return new lettuceconnectionfactory(clusterconfig, clientconfig);
}
}🔍 技术亮点:
clustertopologyrefreshoptions是生产必备,避免槽迁移时客户端长时间拿着过期映射,导致大量 moved 重定向增加延迟。enablealladaptiverefreshtriggers()会在收到重定向错误或节点角色变更时立即刷新拓扑,配合 30 秒定期刷新,双保险。- 连接池天然支持每个分片内部的主从自动切换,代码零改动。
3️⃣ 业务层防御性编码:故障时降级
@service
public class cacheservice {
@autowired
private redistemplate<string, object> redistemplate;
public optional<user> getuserbyid(string id) {
try {
user user = (user) redistemplate.opsforvalue().get("user:" + id);
return optional.ofnullable(user);
} catch (redisconnectionfailureexception e) {
log.warn("redis 不可用,降级查 db", e);
// 降级到数据库查询
return optional.ofnullable(userdao.findbyid(id));
} catch (exception e) {
log.error("redis 异常", e);
return optional.empty();
}
}
}🔍 技术亮点:
- 捕获
redisconnectionfailureexception,这是 lettuce 在连接断开或集群不可达时抛出的,防止缓存雪崩。 - 降级查 db 并打印监控日志,保证核心链路可用。
- 结合 hystrix/sentinel 熔断,能在 redis 大面积故障时快速失败,保护整体系统。😌
🧨 技术难点与解决方案
🙋♂️ 面试官:
代码挺扎实,那你觉得实现 redis 高可用最大的技术难点有哪些?你们是怎么一个一个啃下来的?
👨💻 候选人:
我梳理了四个生产环境下最头疼的点,以及对应的解法。
| 难点 | 详细描述 | 我们的解决方案 |
|---|---|---|
| 🧠 脑裂(split-brain) | 哨兵模式网络分区,旧主被孤立却继续接写入,恢复后数据被新主覆盖 | ① 主节点设置 min-replicas-to-write 和 min-replicas-max-lag,当没有足够从库同步时,旧主直接拒绝写入。② 客户端收到异常后触发告警并降级,人工确认修复。 |
| 📉 异步复制数据丢失 | 主宕机前瞬间写入的数据,还没来得及复制到从库就丢失了 | ① 核心业务(如金融订单)使用 wait 命令,强制同步到指定数量的从库后才返回成功,牺牲部分延迟换取一致性。② 结合 aof 持久化 appendfsync everysec,重启后能从磁盘恢复绝大部分数据。 |
| 🔄 故障切换期间的“短暂不可用” | 哨兵选举、提升新主期间(2~10秒),所有写请求都会失败 | ① 客户端侧开启重试机制,lettuce 默认会重试失效节点,配合指数退避。② 业务层加本地缓存(caffeine) 兜底,读请求可容忍几秒旧数据。③ 监控切换耗时,及时优化哨兵参数(sentinel down-after-milliseconds 不宜过大)。 |
| ⚡ 数据倾斜与热点 key | cluster 中某些槽的数据量或访问量远超其他节点,导致单分片压力过高 | ① 对热点 key 做 多副本打散,比如 hot:key:{hash} 分散到多个 key,本地随机取一个。② 业务层先通过监控发现后,主动调整 key 设计,使用 {} 将互相访问频繁的 key 规范到同一槽,但避免大 key 聚集。③ 必要时升级分片规格或垂直扩容该分片。 |
| 🌀 集群扩容槽迁移影响延迟 | 迁移过程中,客户端会遇到 ask 重定向,频繁的重定向导致毛刺 | ① 打开客户端自适应拓扑刷新,减少重复的 ask 请求。② 分批次、低峰期迁移,控制 migrate 的 pipeline 速度。③ 对延迟敏感业务,迁移时手动临时切换读取从节点,避免主节点阻塞。 |
🙋♂️ 面试官:
最后一个问题,你觉得这些难点里,哪一个是最容易被开发者忽略,但又最致命的?
👨💻 候选人:
绝对是脑裂。因为很多团队配置哨兵或者 cluster 后,看到能自动切换就以为万事大吉了。脑裂一旦发生,在没有 min-replicas-to-write 保护的情况下,丢失的是切换期间所有写入数据,而且是静默丢失,业务侧完全感知不到,直到对账才发现。所以我们规定,所有线上 redis 主节点必须配上这些反脑裂参数,否则上线审批不通过。🚫
🙋♂️ 面试官:
思路很严谨,这些坑都是生产里实打实的,看得出来你是真用过。这一块我没其他问题了。
到此这篇关于深入浅析redis的高可用方案的文章就介绍到这了,更多相关redis高可用内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论