Redis集群和HA集群怎么搭建，保证业务不停摆不掉线

Redis集群的搭建与高可用保障

根据Redis官方文档（来源：Redis官方文档 - Redis Cluster Tutorial），Redis集群的设计目标之一就是在部分节点失败或无法通信时继续保持运行，这主要通过数据分片（sharding）和主从复制（replication）来实现。

搭建一个能够保证业务不停摆的Redis集群,主要步骤如下：

1. 节点准备：至少需要6个Redis服务器实例才能保证高可用的最基本配置，这6个实例可以运行在3台或更多的物理机或虚拟机上，其核心原理是形成3个主节点（master）和3个从节点（slave）的格局,每个主节点都拥有一个或多个从节点。

2. 启用集群模式：在每个Redis实例的配置文件（redis.conf）中，必须设置 cluster-enabled yes，这个配置项会告诉Redis实例以集群模式启动,而不是单机模式。

3. 节点握手：启动所有6个实例后，它们此时还是相互独立的，需要使用Redis自带的命令行工具 redis-cli，通过执行类似 CLUSTER MEET <ip> <port> 的命令，让所有节点彼此发现并连接起来，形成一个集群网络，更常用的方式是使用 redis-cli --cluster create 命令一次性完成节点添加和槽位（slot）分配。

   

4. 数据分片：Redis集群将整个数据库空间划分为16384个哈希槽（hash slot），这是数据分片的关键（来源：Redis官方文档 - Redis Cluster Specification），在上一步的创建命令中，工具会自动将这16384个槽位平均分配给3个主节点，主节点A可能负责0-5500号槽，主节点B负责5501-11000号槽，主节点C负责11001-16383号槽，当客户端存储一个键值对时，Redis会计算键名的CRC16校验和，然后对16384取模,根据结果将数据存放到对应的槽位所在的主节点上。

5. 主从复制与故障转移：这是实现高可用的核心，为每个主节点配置至少一个从节点，从节点会异步复制其主节点的所有数据，Redis集群会持续监控所有节点的心跳，如果某个主节点在预设时间内被大多数主节点判定为失效（fail），那么它的从节点会发起选举，获得多数票的一个从节点会升级为新的主节点，并接管原来主节点负责的所有哈希槽，这个过程是自动的，业务方应用程序如果使用了支持集群模式的客户端（Smart Client），客户端能够自动感知到集群拓扑的变化，并将请求重定向到新的主节点上，从而实现对业务无感知的故障切换,保证业务不停摆。

高可用（HA）集群的搭建思路（以Keepalived + Nginx为例）

这里的HA集群指的是在应用层或代理层解决单点故障，通常用于为无状态服务（如Web服务器、负载均衡器）提供高可用性，一个经典的例子是使用Keepalived为Nginx负载均衡器搭建主备切换机制（来源：Keepalived官方文档及常见Linux高可用方案）。

1. 基础架构：需要两台或多台服务器，都安装Nginx作为负载均衡器（LB）或反向代理，一台被设置为主节点（Master），另一台设置为备用节点（Backup），它们配置有相同的虚拟IP（Virtual IP，简称VIP），192.168.1.100，这个VIP是对外提供服务的地址,终端用户只访问这个VIP。

2. 安装配置Keepalived：在两台服务器上都安装Keepalived软件，Keepalived的核心功能是管理VIP和进行健康检查，在其配置文件中,需要定义：

   • 虚拟路由器：主备节点属于同一个虚拟路由器组,并有一个唯一的ID。
   • 优先级：主节点的优先级（priority）设置得比备用节点高，比如主节点100,备用节点90。
   • 认证：主备节点之间通过密码进行通信认证,防止非法节点加入。
   • 虚拟IP地址：指定要管理的VIP。

3. 工作过程与故障转移：

   • 正常情况：主节点的Keepalived会宣告自己对VIP的所有权（通过发送VRRP组播报文），因此VIP会绑定在主节点的网卡上，所有外部请求都通过VIP发送到主Nginx,再由主Nginx分发到后端的应用服务器。
   • 健康检查：Keepalived可以配置脚本定期检查本机Nginx进程是否存活，用一个简单的脚本每秒检查一次nginx.pid文件是否存在，或者直接调用nginx -t测试配置。
   • 故障发生：如果主节点上的Nginx意外崩溃，健康检查脚本会检测到失败，并通知本机的Keepalived进程，Keepalived会主动降低自己的优先级（比如减去一个较大的值）,使其低于备用节点。
   • 自动切换：备用节点一直在监听VRRP组播报文，当它发现主节点的优先级变得比自己低时，它会立即宣告自己为新的主节点，并将VIP绑定到自己的网卡上，由于网络中的ARP表会更新，后续的请求就会自动发送到新的主节点（原备用节点）上。
   • 业务恢复：新的主节点上的Nginx是健康的，于是服务得以恢复，整个切换过程非常快，通常在几秒钟内完成，对于短连接Web业务而言，用户可能只会感觉到一次短暂的卡顿或需要刷新页面，但不会出现长时间的服务不可用,从而最大限度地保证了业务不掉线。

保证业务不停摆需要从架构层面消除单点故障，Redis集群通过内置的分片和主从自动故障转移机制，解决了数据存储层的高可用问题，而在应用接入层，则可以通过类似Keepalived+Nginx这样的方案，构建主动-备用式的故障转移集群，确保即使一台负载均衡器宕机，服务入口依然畅通，将这两种策略结合,可以构建一个从网关到数据存储都具有韧性的系统架构。