Redis集群架构怎么搭，性能优化和实战经验分享

关于Redis集群的搭建、性能优化和实战经验，我结合自己的实践和一些网络上的分享，比如一些技术博客和社区讨论,来直接说一下。

Redis集群怎么搭

为什么要搭集群？很简单，当你的数据量一台Redis服务器放不下了，或者读写请求多到一台机器扛不住了，就需要用多台机器一起干活，这就是集群，Redis官方提供了Redis Cluster的方案,也是最常用的。

搭建过程,大致分几步：

1. 准备机器：至少需要6个节点，3个主节点（master），3个从节点（slave），这是最低要求，为了保证高可用，一个主节点至少配一个从节点，你可以用6台独立的服务器，也可以在一台机器上开6个不同的端口,后者适合测试。
2. 修改配置文件：每个节点都有一个redis.conf配置文件，需要改几个关键地方：
   • port 6379：每个节点用不同的端口。
   • cluster-enabled yes：这是最重要的,开启集群模式。
   • cluster-config-file nodes-6379.conf：集群自己生成的配置文件,每个节点不同。
   • cluster-node-timeout 15000：节点失联的超时时间,超过这个时间认为它挂了。
   • 如果需要密码，还得设置masterauth和requirepass,并且要一样。
3. 启动所有节点：用redis-server /path/to/redis.conf命令把6个Redis实例都启动起来，这时候它们还是独立的,不认识对方。
4. 组建集群：这是最关键的一步，让6个节点互相认识，并分配好谁当主、谁当从，官方提供了工具redis-cli --cluster create，一条命令搞定， redis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:6379 192.168.1.105:6379 192.168.1.106:6379 --cluster-replicas 1 这里的--cluster-replicas 1表示每个主节点配1个从节点，工具会自动帮你把主从分配好（前三个是主，后三个是从），并且把数据分成16384个槽（slot）平均分配给三个主节点。
5. 验证集群：用redis-cli -c -p 任何一个端口 cluster nodes命令查看集群状态，如果能看到所有节点，并且主从关系正确，槽分配也均匀,就差不多了。

搭建过程其实不复杂，官方工具已经帮我们做了很多事,难点和坑往往在后面。

性能优化

集群搭起来能用了，但可能慢吞吞的,怎么办？

1. 别让持久化拖后腿：Redis的数据持久化方式有RDB（快照）和AOF（日志），在集群里，尤其是主节点，如果做RDB快照时数据量太大，会阻塞服务，可能导致集群认为它挂了而触发故障转移，建议：
   • 在从节点上做持久化，主节点专心应付读写,持久化的活交给从节点干。
   • 合理配置持久化策略，比如RDB的保存频率不要太高，AOF的刷盘策略可以用everysec（每秒一次）,平衡性能和数据安全。
2. 注意客户端的使用姿势：连接集群要用支持集群协议的客户端（比如JedisCluster、Lettuce），最大的一个坑是“跨槽位访问”，一个命令如果操作的key不在同一个槽位，就会报错，要保证一批同时操作的key（比如MSET、MGET），通过“哈希标签”让它们落到同一个槽位，把user:10001:profile和user:10001:order都加上，写成{user:10001}:profile和{user:10001}:order，这样Redis只会用user:10001来计算槽位,它们就能在一起了。
3. 网络和系统调优：集群节点之间通信很频繁，要保证网络带宽和低延迟，操作系统层面，可以调整TCP连接数、内核参数等,这些网上有很多现成的优化方案可以参考。
4. 监控慢查询：用slowlog get命令看看有没有执行很慢的命令，可能是你的Key太大，或者用了KEYS *这种危险命令，找到慢查询,优化它。

实战经验分享

这部分是踩过坑才知道的。

1. 内存规划很重要：不要等内存快满了才加机器，Redis集群扩容虽然支持，但比较麻烦（需要resharding，即重新分片），最好提前规划，让每个节点的内存使用率维持在70%以下,留出缓冲空间。
2. 故障转移是常态：要习惯节点挂掉，你的应用代码必须有重试机制，因为正在读写的节点可能突然就不是主节点了（发生了故障转移），好的客户端库能帮你自动处理,但你的代码逻辑不能假设一次连接就永远成功。
3. 批量操作要小心：就像前面说的，在集群里做批量操作（Pipeline、Lua脚本）时，必须确保所有Key在同一个节点上，否则会失败,这是和单机Redis最大的不同之一。
4. 监控和报警不能少：必须有一套监控系统盯着集群，看几个关键指标：节点是否健康、内存使用率、网络流量、每秒操作数（QPS）、延迟（Latency），一旦有异常，马上报警，等用户反馈说网站卡了,就太晚了。
5. 升级和重启要谨慎：重启集群节点要有计划，最好一个一个来，先重启从节点，再重启主节点，避免同时中断服务，版本升级前,一定要在测试环境充分验证。

Redis集群解决了单机瓶颈的问题，但引入了分布式系统的复杂性，搭建只是第一步，后期的维护、监控、优化才是真正的挑战，关键是理解它的工作原理，这样才能在出问题时快速定位和解决，网上很多技术博主的经验贴，比如关于某个特定客户端库的深坑，或者一次线上故障的排查记录，都非常有参考价值,多看看能少踩很多坑。