Hyperf 中需手动配置多 Redis 连接池：写操作用 redis.master 池，读操作按区域（如 redis.us-west）分设只读池；跨区域复制须调大 repl-ping-replica-period、repl-timeout 等参数防中断；强一致性场景强制读主库，弱一致性场景可读从库并兜底查主库。
Hyperf 微服务本身不提供跨区域数据同步能力，Redis 跨区域复制也不是 Hyperf 的功能模块——它取决于你如何把 Redis 实例接入、配置和编排。真正起作用的是底层 Redis 的复制机制 + 业务层对读写路由的控制，Hyperf 只是调用方。
Hyperf 中怎么配置跨区域 Redis 客户端？
Hyperf 使用 hyperf/redis 组件，默认只支持单实例或哨兵，不原生识别“主区域”“灾备区域”概念。你需要手动区分连接池：
- 为写操作配置一个指向主区域 Redis 的连接池（如
redis.master），所有set、hSet、incr等命令必须走这个池 - 为读操作配置多个连接池（如
redis.shard1、redis.us-west），分别指向不同区域的只读从节点 - 在
config/autoload/redis.php中显式定义多个 pool，避免复用同一 pool 导致连接混用 - 不要依赖
RedisFactory::get()默认实例，必须用名字显式获取：$this->redis = $this->container->get(RedisFactory::class)->get('redis.us-west');
为什么直接用 replicaof 做跨区域主从会出问题？
因为 Redis 原生命令 replicaof 在高延迟网络下极易触发复制中断、积压、甚至全量重同步（RDB 传输卡住）。真实跨区域场景中常见错误现象包括：
-
INFO replication显示master_link_status:down，但网络连通性正常（其实是 TCP keepalive 或超时参数太激进） - 从节点
slave_repl_offset长期落后，master_last_io_seconds_ago持续大于 60 - 主节点
connected_slaves数量波动，日志频繁出现Connection with slave lost
根本原因不是配置错，而是默认 repl-timeout 60 和 repl-ping-replica-period 10 不适配跨区域 RTT（通常 80~200ms）。必须调大：
repl-ping-replica-period 30 repl-timeout 300 repl-backlog-size 1024mb repl-backlog-ttl 86400
Hyperf 里怎么避免读到过期数据？
最终一致性模型下，“刚写完就立刻读从库”必然读不到最新值。Hyperf 无法绕过这个物理限制，只能收敛读写路径：
- 对强一致性要求的操作（如用户余额扣减、订单锁库存），强制走
redis.master池读写，跳过从库 - 对弱一致性可接受的场景（如商品详情缓存、排行榜），才走区域从库；并在业务逻辑里加兜底：若从库返回空，再查一次主库（注意防穿透）
- 不要在事务中混合使用主库写 + 从库读 ——
multi/exec只作用于当前连接，跨连接事务无意义 - 如果用了
RedisCluster客户端，确认它没自动把GET请求路由到非负责该 slot 的节点（某些旧版客户端有此 bug）
云托管 Redis（如 Azure Cache for Redis Enterprise）能省掉哪些坑？
能省掉网络调优、断点续传、拓扑变更、冲突检测等底层工作，但代价是失去控制权：
- Azure 的活动异地复制（Active Geo-Replication）要求两个缓存实例版本一致、分片数相同（如都是 4 分片），否则创建失败
- 它不支持自定义过滤（比如只同步
user:*key），所有 key 全量同步，带宽和内存开销不可控 - 故障转移后，新主库的连接地址会变，Hyperf 应用需监听 Azure 事件或轮询 API 更新配置，否则持续写入失败
- 延迟监控只能看 Azure Portal 的
ReplicationLagMs指标，无法像自建那样抓master_repl_offset和slave_repl_offset差值做告警
最易被忽略的一点：跨区域复制的“最终一致”不是秒级，而是受网络抖动、从库负载、AOF rewrite 影响，可能长达数秒甚至分钟 —— 这个窗口期必须由业务代码兜底，而不是寄希望于中间件自动修复。
