redis主从架构中只读从库需服务端配置（如replica-read-only yes）、客户端连接隔离（如lettuce的readfrom.slave）、应用层路由管控（主写从读严格分离）三重协同，缺一不可。
Redis 主从架构中，配置只读从库不是单靠一个开关就能完成的事，而是需要服务端配置、客户端连接方式、应用层逻辑三方面协同落实。光在 redis.conf 里设 slave-read-only yes 是基础，但容易被绕过——比如客户端发 READWRITE 命令，或用低层驱动直连后误调写操作。
服务端：强制从库只读并防止绕过
这是第一道防线，必须显式配置且持续验证：
- 在从库的
redis.conf中明确设置：slave-read-only yes（Redis 5.0+ 推荐用replica-read-only yes，语义更清晰） - 重启从库使配置生效，并用命令确认：
redis-cli -h {slave-ip} -p 6379 CONFIG GET replica-read-only→ 应返回["replica-read-only","yes"] - 执行
INFO replication，检查role:slave和connected_slaves是否正常 - 若使用 Redis 6+ ACL，确保连接用户没有
+set、+del等写权限；ACL 权限优先级高于replica-read-only，可兜底拦截
客户端：按只读意图建立连接，不混入写逻辑
服务端只拦命令，不拦连接行为。客户端必须主动“选对路”，且避免写调用：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
Lettuce（Java）：不用
RedisClient.create()直连从库 IP，而要用MasterSlave.connect()+ReadFrom.SLAVE_PREFERRED或ReadFrom.SLAVE。它会自动发现从节点并路由读请求，故障时按策略降级 -
redis-py（Python）：不能简单
redis.Redis(host="slave-ip", port=6379)就完事。应为读操作单独创建连接实例，并在业务代码中严格隔离——写操作走主库连接，读操作走从库连接，禁止复用同一 client 对象发写命令 - 无论哪种客户端，都不要在读连接上调用
SET、INCR、DEL等命令。Lettuce 不会提前拦截，错误会在执行时由 Redis 返回READONLY You can't write against a read only replica.
应用层：路由隔离与监控兜底
配置和客户端只是手段，真正落地靠架构设计：
- 在服务发现或配置中心层面，把主库地址和从库地址分开管理。例如 Spring Cloud Config 中定义
redis.master.url和redis.slave.urls，让不同数据源天然隔离 - 在 DAO 层或 Repository 层封装读写逻辑：写方法固定用主库模板，读方法固定用从库模板，禁止跨模板调用
- 部署监控脚本，定时检查所有从库的
replica-read-only配置值和master_link_status，异常时触发告警甚至自动修复
只读从库不是“配完就安全”，而是要让服务端拒绝、客户端不发、应用层不混——三层叠加，缺一不可。
