Redis多实例怎么搞，性能和高可用都想兼顾，实操经验分享

为啥要搞多实例？单实例不香吗？

单实例Redis当然香,简单省事，但等你业务量上来，就会遇到几个头疼的问题。性能瓶颈，Redis是单线程的，虽然它处理速度极快，但单个CPU核心的能力是有上限的，当你的并发高到一定程度，或者数据量大到内存快撑爆时，单实例就扛不住了，响应会变慢。高可用问题，如果这个唯一的Redis实例宕机了，整个依赖它的服务就全挂了，这是灾难性的。

搞多实例的核心目的就两个：把数据和压力分散开，提升整体性能和容量（这叫扩展性），2. 做备份，一个实例挂了，另一个能立刻顶上去，保证服务不中断（这叫高可用）。

第二部分：兼顾性能与高可用的核心方案：Redis Cluster

在实操中,要想同时较好地兼顾性能和可用性，首推官方的 Redis Cluster（Redis集群） 方案，你不用把它想得太复杂，可以理解为“分片+主从”的结合体。

分片（Sharding）解决性能问题 想象一下，你有一个超大的字典（数据），一个人查（单实例）很慢，现在你把它拆成A到M、N到Z两本小字典（分片），让两个人（两个Redis实例）同时查，速度就快了，Redis Cluster就是这么干的，它会把所有的数据分成16384个槽位（slots），然后把这些槽位大致平均地分配给集群里的多个主节点（Master），比如你有一个3主节点的集群，每个主节点可能负责5000多个槽位，当你存一个数据时，Redis会根据key计算它属于哪个槽位，然后自动把它存到对应的那个主节点上，这样，读写压力就自然分散到了不同的机器上，实现了横向扩展。

实操经验点：分片的关键是数据分布的均匀性，如果某个key特别热（比如明星八卦），所有请求都打到某一个分片上，就会形成“热点”，这个分片可能还是扛不住，这时候就需要在设计key的时候下功夫，比如用业务前缀+ID哈希的方式，让key分布得更散列一些。

主从（Replication）解决高可用问题 光有分片还不够，如果某个主节点宕机了，它负责的那部分数据就访问不了了，Redis Cluster为每个主节点都配置了至少一个从节点（Slave），从节点就像是主节点的“影子”，实时同步主节点的数据。

• 故障自动切换（Failover）：当某个主节点宕机后，集群会自动检测到，然后在这个主节点对应的从节点中，选举出一个新的主节点来顶替它，这个过程是自动的，对业务方来说，可能只会感受到一瞬间的卡顿，但服务不会彻底中断。
• 读写分离：虽然Redis Cluster默认是读写都走主节点，但你也可以让一些读请求去从节点，进一步分担主节点的压力，但这要注意数据一致性的问题，因为主从同步有毫秒级的延迟，可能会读到旧数据。

实操经验点：从节点的数量和质量很重要，至少配一个从节点是底线，但重要的业务，可以考虑配两个从节点，甚至放在不同的物理机上，防止“一锅端”，主从节点之间的网络一定要稳定且高速，如果网络延迟高，同步就会慢，故障切换时数据丢失的风险会增大。

第三部分：搭建Redis Cluster的实操关键步骤（非详细命令，而是要点）

1. 准备机器：至少需要3个主节点和3个从节点，总共6个实例，这是保证集群能正常进行故障选举的最小配置，最好把它们部署在不同的物理服务器或虚拟机上，避免硬件故障导致多个实例同时宕机。
2. 配置每个实例：修改每个Redis实例的配置文件，关键配置包括：
   • cluster-enabled yes：这是开启集群模式的开关，必须打开。
   • cluster-config-file nodes-6379.conf：集群自动生成的配置文件，别动它，让它自己管理。
   • port 和 dir：确保每个实例的端口和数据目录不冲突。
3. 启动所有实例：把6个Redis服务都启动起来。
4. 组建集群：这是最关键的一步，使用Redis自带的redis-cli --cluster create命令，把6个实例的地址和端口信息告诉它，它会自动完成槽位的分配和主从关系的绑定，命令执行后，它会给你一个分配方案，你确认无误后输入yes，集群就开始建立了。
5. 验证集群：用redis-cli -c（-c代表以集群模式连接）随便连上一个节点，set几个key，get一下，看看是否能正常跳转到正确的节点，再用cluster info和cluster nodes命令查看集群状态和节点信息，确保所有节点都是connected，槽位分配也是完整的（16384个slots都分配了）。

第四部分：除了Redis Cluster，还有其他办法吗？

有,但通常更推荐Redis Cluster。

• 客户端分片：早些年常用的办法，就是在业务代码里，由开发者自己写算法，决定一个key该存到哪个Redis实例，这种方式非常灵活，但缺点是运维复杂，扩容缩容极其麻烦，需要手动迁移数据并修改所有客户端的配置，高可用也需要自己实现哨兵之类的机制，不推荐新手和大多数场景使用。
• 代理分片：比如Codis这类中间件，它在你的一堆Redis实例前面加一个代理层，客户端直连代理，由代理来负责计算数据该去哪，以及处理故障切换，这对业务代码是透明的，但引入了新的组件，增加了部署和维护的复杂度，而且性能会有轻微损耗。

总结一下我的实操经验：

• 首选Redis Cluster：对于绝大多数追求性能和可用性的场景，它是官方、成熟、且相对简单的方案。
• 规划好资源：别把主从节点放在同一台机器上，网络要好。
• 监控不能少：集群搭建好不是结束，要用监控工具（如Prometheus+Grafana）盯着各个节点的内存、CPU、连接数和同步状态，提前发现潜在问题。
• 容量要预留：别等内存用满了再扩容，提前规划，在内存使用率达到70%-80%时就要考虑扩容集群了。
• 测试！测试！测试！：在上生产环境前，一定要模拟故障（比如手动kill掉一个主节点），看看集群是否能正常切换，你的应用是否能正常处理。

多实例的核心思想就是“不要把鸡蛋放在一个篮子里”，Redis Cluster提供了一个既能把鸡蛋分开放（分片），又能给每个篮子配个备用篮子（主从）的现成、好用的篮子架。