首先，检查网络连接是否正常，用ping命令测试节点间连通性；然后查看Redis日志文件，找错误信息如连接超时或槽位迁移失败；用redis-cli --cluster check命令检查集群状态，确认所有节点在线且槽位分布均衡；性能优化上，调整maxmemory参数控制内存使用，避免频繁淘汰键；启用pipeline批量操作减少网络往返；设置合理的集群超时时间，如cluster-node-timeout，根据实际延迟调整；最后，重启故障节点并重新加入集群，观察数据是否同步。

排查Redis集群故障的步骤

在实际生产环境中遇到Redis集群数据获取慢或失败时，第一步是登录主节点执行redis-cli命令，输入cluster nodes查看所有节点状态，注意role字段是否为master或slave，flags是否有fail标记。如果有fail节点，用cluster forget命令强制移除它。然后检查info replication输出，确认slave节点offset是否追上master，避免数据不一致。网络问题常见，用netstat -an检查端口6379连接受阻情况，防火墙有时会挡住集群总线端口16379。日志是关键，tail -f redis.log观察crash或fork失败错误，通常是内存不足导致，重启前先dump内存快照。

优化Redis集群性能的实战经验

我们公司Redis集群数据量上亿时，数据获取卡顿严重，后来通过几个调整解决了：一是热点键拆分，用hash或list代替大string，减少单个键大小到1MB内；二是客户端连接池优化，设置最大连接数和空闲超时，避免频繁建连；三是读写分离，主节点只写，从节点读，大流量场景下从节点负载均衡到多台；四是监控告警，用prometheus抓取latency指标，超过100ms就报警；五是定期compact碎片，内存碎片率高时用memory purge命令清理。结果QPS从5万提到20万，延迟降到10ms。

常见故障场景及快速修复

一次集群扩容后数据丢失，原因是槽位导入失败，排查发现migration_buffer不够大，调整cluster-migration-barrier为1000后重试成功。另一个问题是get命令返回MOVED或ASK重定向，客户端没处理好，用--cluster模式启动redis-cli测试；优化时发现大key阻塞，用scan渐进扫描替换keys *，pipeline打包scan提升效率。性能瓶颈多在磁盘IO，AOF持久化改成no-appendfsync-on-rewrite减轻压力。

数据不一致排查方法

Redis集群异步复制易导致短暂不一致，故障时对比主从wait命令，执行wait 0 100检查从节点追上主节点进度。优化性能用cluster-require-full-coverage no容忍部分故障继续服务，避免全集群宕机。实际案例中，节点下线后数据获取空，用cluster slots查槽位位置，手动重定向客户端到正确节点。

FAQ

Q: Redis集群为什么会出现MOVED错误？
A: 这是槽位重定向，客户端请求错节点时发生，确保客户端支持集群模式，或用HASH槽计算key所属节点。

Q: 如何监控集群健康？
A: 用redis-cli cluster info看cluster_state是否ok，结合Grafana dashboard显示CPU、内存、QPS指标。

Q: 性能慢时先查什么？
A: 检查慢查询日志slowlog get 10，找出耗时命令，然后优化数据结构或加从节点分流。

Q: 集群节点挂了怎么救？
A: 先隔离故障节点，cluster forget移除，从备份slave提升为master，slot rebalance均衡槽位。