手动一步步搭建Redis集群，保证数据不丢失还能高可用，自己动手试试看

基于Redis官方文档及常见高可用实践

我们不用“Redis集群”那个特别复杂的概念，我们用更简单易懂的主从复制（Replication）加哨兵（Sentinel）的方式来搭建，这样既能保证数据有备份（不丢失），又能在一台机器挂掉时自动切换（高可用），我们假设要在三台机器上操作，它们的IP地址分别是192.168.1.10、192.168.1.11、192.168.1.12。

第一步：安装Redis

在三台机器上，都执行同样的安装操作,假设我们用的是CentOS系统。

1. 打开三台机器的终端,用SSH连上去。
2. 安装必要的工具和编译环境：yum install -y gcc tcl
3. 下载Redis源码并解压（这里以6.2.6版本为例，你可以去官网找最新稳定版）：

   wget https://download.redis.io/releases/redis-6.2.6.tar.gz
   tar -xzf redis-6.2.6.tar.gz
   cd redis-6.2.6

4. 编译并安装：

   make
   make install

   这样，Redis的服务端程序redis-server和客户端程序redis-cli就安装到系统里了。

   

第二步：配置主从复制

我们要选一台机器作为“主库”（Master），另外两台作为“从库”（Slave），数据会从主库自动同步到从库，我们选择192.168.1.10作为主库。

1. 在主库（192.168.1.10）上配置：

   • 创建一个配置文件，比如叫redis-master.conf。
   • 用文本编辑器打开这个文件，写入最基本的内容：

     port 6379  # Redis默认端口，就用这个
     daemonize yes  # 让Redis在后台运行
     pidfile /var/run/redis_6379.pid  # 进程ID文件位置
     logfile "/home/redis/redis.log"  # 日志文件位置，你自己定一个路径
     dir /home/redis/data  # 数据文件保存目录，先创建好这个目录
     requirepass your_strong_password  # 给Redis设置一个强密码，三台机器要一样
     masterauth your_strong_password  # 从库连接主库时用的密码，和上面一样
     appendonly yes  # 开启AOF持久化，保证数据不丢失的关键！每次写操作都记录日志

   • 保存文件。
   • 创建好配置文件中指定的目录/home/redis/data。
   • 启动主库：redis-server /path/to/your/redis-master.conf

2. 在从库1（192.168.1.11）和从库2（192.168.1.12）上配置：

   

   • 每台从库也创建一个配置文件，比如叫redis-slave.conf。
   • 几乎和主库一样，但需要多加两行，指向主库：

     port 6379
     daemonize yes
     pidfile /var/run/redis_6379.pid
     logfile "/home/redis/redis.log"
     dir /home/redis/data
     requirepass your_strong_password
     masterauth your_strong_password
     appendonly yes
     # 下面这两行是关键的从库配置
     replicaof 192.168.1.10 6379  # 指定主库的IP和端口
     # 如果Redis版本低于5.0，这个指令可能叫 slaveof，用法一样

   • 保存文件。
   • 创建好数据目录。
   • 分别启动两台从库：redis-server /path/to/your/redis-slave.conf

3. 检查主从状态：

   • 连接到主库：redis-cli -h 192.168.1.10 -p 6379 -a your_strong_password
   • 执行命令：info replication
   • 在输出信息里，你应该能看到role:master，并且connected_slaves的数量为2，下面还会列出两个从库的地址,这说明主从复制已经成功建立了。
   • 你可以在主库上写一个数据（set mykey hello），然后在任意一个从库上读（get mykey），如果能读到hello,就证明数据同步正常。

第三步：配置哨兵（Sentinel）实现高可用

光有主从复制还不够，如果主库挂了，我们需要系统能自动从两个从库里选出一个新的主库，让应用连到新主库上去,这就是哨兵的工作。

1. 在三台机器上分别配置哨兵：

   

   • 哨兵本身也是一个特殊的Redis进程，每台机器上都需要一个哨兵配置文件，比如叫sentinel.conf。
   • 配置文件内容如下（三台机器配置一样）：

     port 26379  # 哨兵默认端口
     daemonize yes
     pidfile /var/run/redis-sentinel.pid
     logfile "/home/redis/sentinel.log"
     dir "/home/redis/sentinel-data"  # 哨兵自己的数据目录
     # 核心配置：监控名叫mymaster的主库，地址是192.168.1.10:6379
     # 2表示至少需要2个哨兵同意才认为主库客观下线（由于我们有3个哨兵，2是多数）
     sentinel monitor mymaster 192.168.1.10 6379 2
     # 主库密码
     sentinel auth-pass mymaster your_strong_password
     # 主库失活后，多少毫秒内没响应就认为它“主观下线”，默认30秒
     sentinel down-after-milliseconds mymaster 30000
     # 故障转移时，最多有多少个从库同时从新主库同步数据
     sentinel parallel-syncs mymaster 1
     # 故障转移超时时间
     sentinel failover-timeout mymaster 180000

   • 保存文件。
   • 创建好哨兵的数据目录/home/redis/sentinel-data。

2. 启动三台机器上的哨兵：

   • 在三台机器上分别执行：redis-sentinel /path/to/your/sentinel.conf

3. 检查哨兵状态：

   • 连接到任意一个哨兵：redis-cli -h 192.168.1.10 -p 26379（哨兵不需要密码）。
   • 执行命令：sentinel master mymaster
   • 你会看到关于主库的详细信息，包括IP、端口、状态等。
   • 执行命令：sentinel slaves mymaster,会列出两个从库的信息。
   • 执行命令：sentinel sentinels mymaster，会列出其他哨兵的信息,证明三个哨兵已经互相发现了对方。

第四步：测试高可用

现在我们来模拟主库宕机,看看哨兵是否能正常工作。

1. 模拟故障： 登录到主库机器（192.168.1.10），粗暴地使用kill -9命令杀掉主Redis进程。
2. 观察哨兵日志： 稍等一会儿（大概30秒后，就是我们设置的down-after-milliseconds），去查看任意一个哨兵的日志文件（/home/redis/sentinel.log），你会看到类似+sdown（主观下线）、+odown（客观下线）、+vote-for-leader（选举领头哨兵）、+switch-master（切换主库）这样的日志,这表明哨兵正在执行故障转移。
3. 检查新主库： 大约一分钟左右，故障转移应该完成，你再次用redis-cli连接任意一个哨兵，执行sentinel master mymaster命令，你会发现ip和port字段已经变成了其中一个从库的地址（比如192.168.1.11），而role:slave的从库只剩下一个（就是192.168.1.12）。
4. 验证应用连接： 你的应用程序在连接Redis时，不应该直接连接192.168.1.10:6379，而应该连接哨兵（比如连接三个哨兵地址192.168.1.10:26379， 192.168.1.11:26379， 192.168.1.12:26379），应用程序的Redis客户端需要支持哨兵模式，它可以通过询问哨兵来获取当前真正的主库地址，这样，即使主库变了，应用程序也能自动连接到新的主库,业务几乎不受影响。
5. 恢复旧主库： 现在你可以重新启动192.168.1.10上的Redis进程（还是用最初的redis-master.conf），启动后，哨兵会发现它恢复了，并会把它作为新的从库，挂到当前的主库（192.168.1.11）下面。

通过以上这些步骤，你就手动搭建了一个具有数据备份（通过主从复制和AOF持久化）和高可用性（通过哨兵自动故障转移）的Redis服务，整个过程虽然步骤多，但一步步做下来,就能深刻理解每个组件的作用。