Redis `replica-serve-stale-data`：主从断开时是否提供过期数据

各位Redis探险家们，欢迎来到“Redis主从断线求生记”特别讲座！今天我们要聊的是一个相当刺激的话题：当Redis主从服务器突然闹脾气，断线了，你的从库该怎么办？是抱着“宁为玉碎，不为瓦全”的原则啥也不提供，还是“死马当活马医”，把过期的旧数据拿出来顶一下？

这个问题的答案，就藏在replica-serve-stale-data这个配置项里。

replica-serve-stale-data：生死攸关的开关

简单来说，replica-serve-stale-data 就是个开关，决定了当Redis从库检测到和主库的连接断开时，是否继续提供数据服务。它有两个选项：

yes (默认值)：从库会继续响应客户端请求，即使它提供的数据可能是过期的。
no：从库会拒绝所有客户端请求，返回一个错误信息。

场景模拟：断线危机！

想象一下，你正在运营一个电商网站，用户正在疯狂地抢购商品。Redis主库突然宕机了！这个时候，从库就成了你的救命稻草。

如果replica-serve-stale-data设置为yes：

从库会继续提供商品信息，让用户可以继续下单。虽然这些信息可能是过期的，比如库存数量可能不准确，但至少用户还能正常浏览和下单，避免网站完全瘫痪。
如果replica-serve-stale-data设置为no：

从库会拒绝所有请求，用户访问网站会看到一片错误页面，或者报错信息。这绝对是灾难性的！

replica-serve-stale-data=yes的优点与缺点

让我们先来盘点一下，当replica-serve-stale-data设置为yes时，我们能得到什么好处，又需要承担什么风险？

优点	缺点
提高可用性：即使主库宕机，从库依然可以提供服务。	数据不一致：从库提供的数据可能是过期的。
减少错误：避免了客户端看到错误信息。	业务逻辑错误：基于过期数据可能会导致业务逻辑错误。
用户体验：用户可以继续使用部分功能，体验更好。

风险分析：数据不一致引发的惨案

数据不一致是最大的风险。想象一下以下场景：

库存错误： 从库显示的库存比实际库存多，导致超卖。
价格错误： 从库显示的价格比实际价格低，导致用户以错误的价格下单。
用户信息错误： 从库显示的用户信息是旧的，导致用户无法正常登录或修改信息。

这些错误都可能导致严重的业务损失和用户投诉。

代码演示：replica-serve-stale-data=yes下的数据读取

为了更直观地理解，我们用Python代码模拟一下replica-serve-stale-data=yes情况下，从库如何处理请求：

import redis
import time

# 连接到主库
master = redis.Redis(host='localhost', port=6379, db=0)

# 连接到从库
slave = redis.Redis(host='localhost', port=6380, db=0)

# 模拟主库设置一个键值对
master.set('product:123:stock', 10)
master.set('product:123:price', 99.99)

# 等待数据同步到从库
time.sleep(1)

# 模拟主库宕机 (这里只是模拟，实际情况下你需要真正关闭主库)
print("模拟主库宕机...")
# master.shutdown()  # 取消注释会真正关闭主库

# 模拟从库继续提供服务
try:
    stock = slave.get('product:123:stock')
    price = slave.get('product:123:price')
    print(f"从库读取到的库存：{stock.decode()}")
    print(f"从库读取到的价格：{price.decode()}")
except redis.exceptions.ConnectionError as e:
    print(f"从库连接错误：{e}")

# 模拟主库恢复后，库存减少
master.set('product:123:stock', 5)
time.sleep(1)  # 等待数据同步（实际中，同步需要时间，这里简化了）

# 再次从从库读取数据 (如果主从同步快，可能读取到新的数据，否则还是旧的)
try:
    stock = slave.get('product:123:stock')
    price = slave.get('product:123:price')
    print(f"从库再次读取到的库存：{stock.decode()}")
    print(f"从库再次读取到的价格：{price.decode()}")
except redis.exceptions.ConnectionError as e:
    print(f"从库连接错误：{e}")

这段代码模拟了以下场景：

主库设置了商品库存和价格。
主库宕机（模拟）。
从库继续提供服务，读取旧的库存和价格。
主库恢复，库存被更新。
从库再次读取数据，可能会读取到新的数据，也可能还是旧的，取决于主从同步的速度。

replica-serve-stale-data=no的优点与缺点

如果replica-serve-stale-data设置为no，情况又会如何呢？

优点	缺点
数据一致性：保证不会返回过期数据。	可用性降低：主库宕机时，从库无法提供服务。
避免业务逻辑错误：不会基于过期数据进行操作。	用户体验差：客户端会看到错误信息。

代码演示：replica-serve-stale-data=no下的数据读取

import redis
import time

# 连接到主库
master = redis.Redis(host='localhost', port=6379, db=0)

# 连接到从库
slave = redis.Redis(host='localhost', port=6380, db=0)

# 模拟主库设置一个键值对
master.set('product:123:stock', 10)

# 等待数据同步到从库
time.sleep(1)

# 模拟主库宕机 (这里只是模拟，实际情况下你需要真正关闭主库)
print("模拟主库宕机...")
# master.shutdown()  # 取消注释会真正关闭主库

# 模拟从库拒绝服务
try:
    stock = slave.get('product:123:stock')
    print(f"从库读取到的库存：{stock.decode()}")
except redis.exceptions.ConnectionError as e:
    print(f"从库连接错误：{e}")  # 关键区别：这里会抛出连接错误，因为主库宕机，从库拒绝服务
except redis.exceptions.ResponseError as e:
    print(f"从库响应错误：{e}")  # 根据Redis版本和配置，可能会抛出其他类型的错误

这段代码的主要区别在于，当主库宕机时，从库由于replica-serve-stale-data=no，会拒绝连接，从而抛出redis.exceptions.ConnectionError或者其他类型的错误。客户端需要捕获这个错误并进行处理。

如何选择：一场权衡的艺术

那么，到底应该选择yes还是no呢？这没有绝对的答案，需要根据你的具体业务场景进行权衡。

以下是一些建议：

对数据一致性要求极高的场景： 例如银行转账，支付系统等，必须选择no，宁可牺牲可用性，也要保证数据准确。
对可用性要求极高的场景： 例如新闻网站，论坛等，可以选择yes，保证用户可以持续访问，即使看到的是旧数据。
可以容忍短暂数据不一致的场景： 例如电商网站的商品浏览，可以选择yes，但需要采取一些措施来降低风险，例如：
- 设置合理的过期时间： 尽量让数据在短时间内保持一致。
- 使用客户端缓存： 客户端缓存可以减少对Redis的依赖，降低数据不一致的影响。
- 监控主从复制延迟： 及时发现并处理主从复制延迟问题。
- 使用补偿机制： 例如，如果用户下单后发现库存不足，可以进行退款或补偿。

更高级的策略：熔断与降级

除了replica-serve-stale-data，还可以结合熔断和降级策略来提高系统的健壮性。

熔断： 当从库发现主库宕机后，可以自动进入熔断状态，拒绝所有写操作，防止数据进一步不一致。
降级： 当从库发现主库宕机后，可以自动切换到只读模式，只提供读取服务，避免影响核心业务。

这些策略需要在客户端或中间件层面实现，Redis本身不提供直接支持。

配置replica-serve-stale-data

配置replica-serve-stale-data非常简单，只需要修改Redis的配置文件 redis.conf：

replica-serve-stale-data yes  # 或者 no

修改后，需要重启Redis服务才能生效。

你也可以通过CONFIG SET命令动态修改配置：

redis-cli config set replica-serve-stale-data yes  # 或者 no

但是，这种方式修改的配置只在当前Redis实例有效，重启后会失效。建议还是修改配置文件。注意，Redis 5.0 之前的版本使用的是 slave-serve-stale-data，效果相同。

监控与告警：及时发现问题

无论你选择哪种策略，都需要对Redis主从复制进行监控，及时发现并处理问题。以下是一些需要监控的指标：

主从连接状态： 确保主从连接正常。
复制延迟： 监控主从复制延迟，如果延迟过高，需要及时处理。
从库的只读状态： 确保从库的只读状态符合预期。
Redis的错误日志： 检查Redis的错误日志，及时发现异常情况。

可以使用各种监控工具，例如Prometheus + Grafana，Zabbix等，对Redis进行监控和告警。

总结：选择适合你的求生之路

replica-serve-stale-data 是一个强大的工具，可以帮助你在Redis主从断线时保持服务的可用性。但是，它也带来了数据不一致的风险。你需要根据你的具体业务场景，权衡利弊，选择最合适的策略。

记住，没有银弹！只有适合你的解决方案。祝你在Redis的探险之旅中一路顺风！永远保持一颗求知的心，不断学习，才能在技术的世界里立于不败之地！

最后，送大家一个小彩蛋：

想象一下，如果Redis也有朋友圈，主库宕机的时候，从库的朋友圈会是什么样的？

replica-serve-stale-data=yes的从库： “哎，老大又挂了，没办法，我只能继续硬撑着，给大家提供点过期信息，能用就用吧！”
replica-serve-stale-data=no的从库： “老大挂了！我也要罢工！谁也别想从我这里拿到数据！”

希望这个小彩蛋能让你对replica-serve-stale-data有更深刻的理解。感谢大家的收听，下次再见！

发表回复 取消回复

发表回复取消回复