哨兵连接需禁用就绪检查并自定义重试策略，传入正确sentinels数组，监听reconnecting/close事件清理连接，读写分离不复用实例，故障转移须用sentinel failover触发。
哨兵连接配置必须显式启用 enableReadyCheck 和 retryStrategy
ioredis 默认在连接哨兵集群后会执行 READY 检查，但若哨兵尚未完成故障转移或主节点不可达，它会直接抛出 Redis is loading the dataset in memory 或 Connection is closed 并终止重连流程。必须手动关闭就绪检查，并提供自定义重试逻辑：
-
enableReadyCheck: false—— 否则首次连接失败即退订所有重连尝试 -
retryStrategy: (times) => Math.min(times * 100, 3000)—— 避免指数退避过快耗尽重试次数（ioredis 默认只试 20 次，且第 1 次延迟 200ms，对哨兵切换太激进） - 不要依赖
connectTimeout控制重连节奏，它只影响单次 TCP 建连，不影响哨兵发现主节点的周期
哨兵初始化时必须传入 sentinels 数组而非单个地址
ioredis 的哨兵模式不是“连一个哨兵再让它转发”，而是并行向所有哨兵节点发送 SENTINEL GET-MASTER-ADDR-BY-NAME 请求，靠多数派响应来确认当前主节点。传错格式会导致永远无法发现主库：
- ✅ 正确：
sentinels: [{ host: 'sentinel1', port: 26379 }, { host: 'sentinel2', port: 26379 }] - ❌ 错误：
host: 'sentinel1'+port: 26379（这会被当普通 Redis 实例直连） - ❌ 错误：
sentinels: 'sentinel1:26379'（字符串不被解析，静默降级为单节点模式） - 哨兵列表建议至少 3 个，且与 Redis 实例不在同一物理机——否则网络分区时可能集体失联
主节点变更后，旧连接不会自动关闭，需监听 close 和 reconnecting 事件做清理
ioredis 在检测到主节点变化后，会新建连接并切换内部命令分发目标，但旧连接仍保持 connected 状态（TCP 未断），导致后续写操作发到已下线的节点而报错 READONLY You can't write against a read only replica：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 务必监听
client.on('reconnecting', () => { /* 清空待发队列、拒绝新请求 */ }) - 在
close事件中调用client.quit()（避免连接泄漏） - 读写分离场景下，不要复用同一个
Redis实例做读+写——哨兵模式下readonly: true仅控制命令路由，不保证连接对象本身只读 - 可通过
client.status判断当前是否处于重连中（值为reconnecting），用于熔断业务请求
测试故障转移必须触发 SENTINEL FAILOVER 而非直接 kill 进程
本地模拟哨兵切换时，仅 kill -9 主节点进程会导致哨兵状态不同步：从节点可能未完成复制偏移同步，哨兵投票超时，最终 GET-MASTER-ADDR-BY-NAME 返回空。真实故障转移需走哨兵协议：
- 用
redis-cli -p 26379 SENTINEL FAILOVER mymaster手动触发，确保哨兵完成选举和配置广播 - 观察 ioredis 日志是否出现
Connecting to Redis server at xxx:6379（新主地址），而非反复连旧地址 - 若日志卡在
Connecting to Redis server at <old-master></old-master>，说明哨兵未更新配置或客户端未收到通知——检查sentinel monitor mymaster中的 quorum 设置是否满足（需 ≥ 哨兵数/2+1） - 生产环境建议开启
sentinel down-after-milliseconds≤ 5000，避免检测延迟过长
哨兵自动重连真正难的不是配置参数，而是理解 ioredis 如何把“连接管理”、“节点发现”、“命令路由”三件事拆成不同生命周期；很多问题其实发生在主节点切完之后的那几秒——连接还活着、命令还在发、但没人告诉应用层该停手了。
