slave-read-only yes（Redis 5.0+为replica-read-only yes）是默认启用的关键安全配置，作用是禁止从节点接受任何写命令，确保主从数据流向严格单向，防止因误写导致数据不一致、复制中断或脑裂脏数据。
主节点必须开启写权限，从节点必须禁用写操作
Redis默认不强制只读，slave-read-only yes 是关键开关。如果漏配，从节点仍可能接受 SET、DEL 等写命令，导致数据错乱或同步中断。
常见错误现象：从节点能执行 SET 成功，但主节点查不到该 key；或主从 INFO replication 显示 master_link_status:up，但 slave_repl_offset 长期不更新。
- 务必在从节点的
redis.conf中显式设置slave-read-only yes（Redis 5+ 推荐用replica-read-only yes） - 若主节点启用了密码认证（
requirepass），从节点必须配置masterauth <password>，否则复制连接会失败，master_link_status为down - 防火墙常被忽略：主节点的
6379端口需对从节点 IP 开放，否则telnet master_ip 6379直接不通
客户端必须显式区分读/写路由，Redis本身不自动分流
Redis 协议层没有“读写分离”概念，redis-cli 或任意客户端连接哪个节点，就向那个节点发请求。所谓读写分离，完全依赖客户端或中间件控制连接目标。
典型误用：所有请求都打到同一个 redis://127.0.0.1:6379，却以为“配置了主从就自动分离”。结果写压力全在主节点，从节点闲置。
- 应用代码中需维护两个连接池：
masterClient（只用于SET、DEL、INCR等）和slaveClient（只用于GET、HGET、LRANGE等） - 简单轮询不够可靠——需监控
INFO replication中的slave_repl_offset与主节点master_repl_offset差值，差值 > 10000 时应临时剔除该从节点 - 不建议手写负载均衡逻辑；生产环境优先用
redis-py的ReadOnlyConnectionPool，或接入Twemproxy/Redis Cluster Proxy
复制延迟不可忽视，强一致性场景必须读主
异步复制下，从节点数据必然滞后。即使网络良好，master_repl_offset - slave_repl_offset 也常在几十到几百字节之间。对秒级订单状态、库存扣减等场景，直接读从节点可能返回过期结果。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
常见踩坑：电商下单后立即查订单状态，因读了延迟 200ms 的从节点，返回“未创建”，引发用户投诉。
- 业务上可接受“最终一致性”的读操作（如商品详情页、用户资料页），才适合走从节点
- 关键路径（支付回调、库存校验、登录态刷新）必须走主节点，哪怕只读也要用
masterClient.get(...) -
repl-backlog-size建议设为至少 100MB（默认 1MB），避免网络抖动触发全量同步，加剧延迟
单主多从不是无限扩展，主节点带宽和 CPU 是瓶颈
每个从节点建立连接后，主节点都要单独发送复制流。10 个从节点意味着主节点出口带宽 ×10、CPU 复制线程压力 ×10。实测中，当从节点数 > 5，主节点 CPU 使用率常突破 70%，写入吞吐开始下降。
链式复制（A → B → C → D）能缓解，但末端节点延迟显著升高，且中间节点宕机会导致下游全部断连。
- 优先采用星型结构，但严格限制从节点数量（建议 ≤ 5）
- 若需更多读节点，考虑分片（Redis Cluster）而非堆从库
- 监控项必加：
used_cpu_sys、instantaneous_output_kbps、connected_slaves
主从架构本身不解决高可用——主节点宕机，整个写链就断了。读写分离只是性能优化手段，不是容灾方案。真正落地时，得把 sentinel 或 Redis Cluster 作为下一步刚性要求，而不是“后续再考虑”。
