redis主从同步于对象模型

一、redis持久化

        redis 的数据全部在内存中，如果突然宕机，数据就会全部丢失，因此需要持久化来保证 Redis 的 数据不会因为故障而丢失，redis 重启的时候可以重新加载持久化文件来恢复数据；

###### aof ######
# redis.cnf
appendonly no
appendfilename "appendonly.aof"
# aof read write invert
# appendfsync always
appendfsync everysec
# appendfsync no
# auto-aof-rewrite-percentage 为 0 则关闭 aof 复写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# yes 如果 aof 数据不完整，尽量读取最多的格式正确的数据；
# no 如果 aof 数据不完整 报错，可以通过 redis-check-aof 来修复 aof 文件；
aof-load-truncated yes
# 开启混合持久化
aof-use-rdb-preamble yes
###### rdb ######
# save ""
# save 3600 1
# save 300 100
# save 60 10000

Redis 中的 AOF（Append Only File，仅追加文件）是一种持久化机制，通过记录每一个写操作命令到磁盘文件，在 Redis 重启时重放命令以恢复数据。相比 RDB（快照持久化），AOF 数据丢失风险更低，但磁盘写入负载更高。以下是其详细讲解及配置使用方法：

一、AOF 核心配置项

1. 启用 AOF：
   在 redis.conf 中设置 appendonly yes，开启 AOF 持久化。
2. 同步策略（appendfsync）：
   • appendfsync always：每次写操作都同步到 AOF 文件，数据最安全但性能最差。
   • appendfsync everysec：每秒同步一次，在性能和安全性间平衡，是常用配置。
   • appendfsync no：由操作系统决定同步时机，性能最佳但数据丢失风险最大。
3. AOF 重写配置：
   • auto-aof-rewrite-percentage：默认 100，当 AOF 文件大小比最后一次重写后增加 100%（翻倍）时，触发自动重写。
   • auto-aof-rewrite-min-size：默认 64mb，设置触发自动重写的 AOF 文件最小大小。
4. 其他配置：
   • appendfilename "appendonly.aof"：指定 AOF 文件名称（默认 appendonly.aof）。
   • no-appendfsync-on-rewrite：默认 yes，表示 AOF 重写期间不进行同步，避免磁盘 IO 影响重写。

二、配置与使用步骤

1. 修改配置文件：
   编辑 redis.conf，示例配置：

   appendonly yes  
   appendfsync everysec  
   auto-aof-rewrite-percentage 100  
   auto-aof-rewrite-min-size 64mb  
   

   
   保存并关闭文件。
2. 重启 Redis：
   执行 redis-server 重启 Redis（或通过系统服务命令如 systemctl restart redis）。
3. 执行写操作：
   打开 redis-cli 客户端，执行写命令：

   $ redis-cli  
   > SET key1 value1  
   > HSET key2 field1 value1  
   > LPUSH key3 value1  
   

4. 查看 AOF 文件：
   通过 cat appendonly.aof（需确认文件路径，可查 redis.conf 中 dir 配置项）查看记录的写操作：

   plaintext

   *2  
   $6  
   SELECT  
   $1  
   0  
   *3  
   $3  
   SET  
   $4  
   key1  
   $6  
   value1  
   *4  
   $4  
   HSET  
   $4  
   key2  
   $6  
   field1  
   $6  
   value1  
   *3  
   $5  
   LPUSH  
   $4  
   key3  
   $6  
   value1  
   

5. 测试数据恢复：
   重启 Redis 后，验证数据是否恢复：

   $ redis-server  
   $ redis-cli  
   > GET key1  
   "value1"  
   > HGET key2 field1  
   "value1"  
   > LRANGE key3 0 -1  
   1) "value1"  
   

三、AOF 重写

        随着写操作增加，AOF 文件会变大，影响恢复速度和磁盘空间。AOF 重写会生成包含最少恢复命令的新文件。可通过 BGREWRITEAOF 手动触发，或依赖自动重写配置（auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size）。例如，多次修改同一键，重写后仅保留最后一次有效命令。

三、aof-rewrite

一、AOF Rewrite 的原理

AOF Rewrite 是 Redis 优化 AOF 文件的核心机制，通过 遍历当前数据库状态，用最少的命令重新记录数据，替代冗余的历史操作日志，从而缩小文件体积并提升恢复效率。

 

• 不依赖原 AOF 文件：直接读取内存中的键值对，按最终状态生成最简命令（如对 hash 多次 HSET 后仅保留最终字段，对 list 多次 RPUSH/LPOP 后仅保留最终元素）。
• 时间换空间：遍历和重组命令需消耗 CPU 时间，但生成的新 AOF 文件更紧凑，节省磁盘空间，同时加快后续重放速度。

二、AOF Rewrite 的实现过程

1. 触发重写

   • 自动触发：通过 redis.conf 配置两个核心参数控制：
     • auto-aof-rewrite-percentage 100（默认）：AOF 文件大小较上次重写后增长 100%（翻倍）时触发。
     • auto-aof-rewrite-min-size 64mb（默认）：AOF 文件至少达到 64MB 才触发自动重写（避免小文件频繁重写）。
   • 手动触发：执行 BGREWRITEAOF 命令（适用于业务低峰期主动优化）。

2. 子进程处理

   • 主进程通过 fork 生成子进程，子进程负责遍历数据库并构建新的 AOF 文件。
   • 主进程继续处理客户端请求，新写操作会暂存到 内存缓冲区（aof_rewrite_buf_blocks），确保子进程重写期间数据不丢失。

3. 合并缓冲区与替换文件

   • 子进程完成重写后，主进程将缓冲区中的写操作追加到新 AOF 文件，最终用新文件替换旧文件，完成重写。

三、AOF Rewrite 配置与使用步骤

1. 配置自动触发条件（修改 redis.conf）

• 参数说明：
  • auto-aof-rewrite-percentage：可根据业务写入频率调整（如写入频繁场景设为 200，即增长 200% 触发）。
  • auto-aof-rewrite-min-size：避免小文件频繁重写，建议生产环境设为 100MB 以上。

2. 重启 Redis 使配置生效

# 系统服务方式（以 Redis 服务名为例）  
systemctl restart redis  # 或指定配置文件启动（测试场景）  
redis-server /path/to/redis.conf  

3. 手动触发重写（推荐低峰期执行）

redis-cli BGREWRITEAOF  
# 输出 "OK" 表示已在后台启动重写  

4. 验证配置与重写状态

• 查看当前配置：

  redis-cli CONFIG GET auto-aof-rewrite-*  
  # 输出示例：  
  # 1) "auto-aof-rewrite-percentage"  2) "100"  
  # 3) "auto-aof-rewrite-min-size"    4) "64" （单位为 KB，实际 64MB 对应 65536 KB）  
  

• 查看重写进度：

  redis-cli INFO persistence  
  # 重点关注：  
  # aof_rewrite_in_progress: 0（未重写）/ 1（正在重写）  
  # aof_last_rewrite_time_sec: 上次重写耗时（秒）  
  

• 查看日志（路径由 redis.conf 中 logfile 配置，默认 /var/log/redis/redis-server.log）：

  7533:M 15 May 2024 10:00:00.000 * Starting automatic AOF rewrite for aof size 200 MB (threshold 100 MB)  
  7534:C 15 May 2024 10:00:15.000 * AOF rewrite completed successfully, new file size 50 MB  
  

四、触发条件与典型场景

触发方式	配置 / 命令	适用场景
自动触发	auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size	日常运维，自动控制文件膨胀
手动触发	BGREWRITEAOF	业务低峰期主动优化，避免自动触发卡顿

五、优势与注意事项

优势：

1. 节省磁盘空间：剔除冗余命令，文件体积显著缩小（如原 1GB 文件重写后可能仅 100MB）。
2. 提升恢复效率：更小的文件意味着 Redis 重启时重放命令耗时更短。
3. 避免内存碎片化：紧凑的命令减少对连续内存的需求，提升后续写入效率。

注意事项：

1. 内存峰值风险：子进程 fork 时会复制主进程内存，需确保服务器有足够空闲内存（建议预留 20% 以上）。
2. 性能影响：
   • fork 操作可能阻塞主进程（耗时与内存大小正相关），建议控制单次重写的数据量。
   • 重写期间若写入量极高，内存缓冲区可能增大，需合理设置 no-appendfsync-on-rewrite（默认 yes，牺牲少许安全性换取性能）。
3. 监控与调优：定期通过 redis-cli --stat 监控内存和磁盘 IO，避免重写与业务高峰重叠。

六、示例：重写前后的命令对比

        假设对键 mylist 执行以下操作，原始 AOF 记录 5 条命令：

 

RPUSH mylist "a" "b"  
RPUSH mylist "c"  
LPOP mylist  
LPOP mylist  
RPUSH mylist "d" "e"  

 

        重写后，仅记录最终状态的 1 条命令：

        

RPUSH mylist "c" "d" "e"  

 

        文件体积从 200 字节缩减至 50 字节，重放效率提升 4 倍。

四、rdb

         基于 aof 或 aof 复写文件大的缺点，rdb 是一种快照持久化；它通过 fork 主进程，在子进程中将内 存当中的数据键值对按照存储方式持久化到 rdb 文件中；rdb 存储的是经过压缩的二进制数据；

Redis 的 RDB（Redis Database）是一种数据持久化机制，它通过将 Redis 在内存中的数据以快照的形式保存到磁盘上，以便在 Redis 重启时能够快速恢复数据。以下是关于 RDB 的详细讲解：

一、RDB 的工作原理

1. 快照生成：
   • Redis 主进程会定期（或根据配置的条件）执行 fork 操作，创建一个子进程。
   • 子进程负责将当前内存中的数据以特定的二进制格式写入到一个临时文件中。这个过程中，主进程继续处理客户端请求，新的写操作会被记录到一个缓冲区（rdb_child_pipe）中，以确保子进程生成快照期间的数据一致性。
   • 子进程完成数据写入后，会将临时文件重命名为最终的 RDB 文件（通常命名为 dump.rdb）。
2. 数据恢复：
   • 当 Redis 重启时，它会读取 RDB 文件，并将其中的数据加载到内存中，从而恢复到上次保存快照时的状态。

二、RDB 的触发条件

1. 自动触发：
   • Redis 可以根据配置的 save 规则自动触发 RDB 快照的生成。例如，默认配置中可能有 save 900 1，表示在 900 秒内如果至少有 1 个键被修改，就会触发一次 RDB 快照。
   • 还可以通过配置多个 save 规则来满足不同的持久化需求，例如 save 300 10 表示在 300 秒内如果至少有 10 个键被修改，也会触发快照。
2. 手动触发：
   • 可以使用 SAVE 命令手动触发 RDB 快照的生成。执行 SAVE 命令时，Redis 主进程会阻塞，直到快照生成完成。
   • 也可以使用 BGSAVE 命令，该命令会在后台启动一个子进程来执行快照生成操作，主进程不会被阻塞。

三、RDB 的配置参数

1. save 规则：
   • 如上述示例，save <seconds> <changes> 用于定义触发 RDB 快照的条件。
   • 可以配置多个 save 规则，Redis 会根据这些规则来判断是否需要进行快照操作。
2. rdbcompression：
   • 该参数用于控制是否对 RDB 文件进行压缩。默认值为 yes，表示启用压缩。
   • 压缩可以减少 RDB 文件的大小，但会增加一些 CPU 开销。如果服务器的 CPU 资源比较紧张，可以考虑将该参数设置为 no 来禁用压缩。
3. rdbchecksum：
   • 用于控制是否在 RDB 文件中添加校验和。默认值为 yes，表示启用校验和。
   • 校验和可以用于在加载 RDB 文件时验证数据的完整性，但会增加一些文件大小。如果对数据完整性要求较高，可以保持该参数为 yes；如果希望减少文件大小，可以考虑将其设置为 no。
4. dbfilename：
   • 用于指定 RDB 文件的名称。默认值为 dump.rdb。
   • 可以根据需要修改该参数，例如将其设置为 redis.rdb 等。
5. dir：
   • 用于指定 RDB 文件的保存目录。默认值为 Redis 的工作目录。
   • 可以将 RDB 文件保存到其他目录，例如 /data/redis/rdb/ 等。

四、RDB 的优势与劣势

1. 优势：
   • 数据恢复快：RDB 文件是一个紧凑的二进制文件，在恢复数据时，Redis 可以快速地将其加载到内存中，因此恢复速度比 AOF 更快。
   • 适合大规模数据恢复：由于 RDB 文件的体积相对较小，因此在恢复大规模数据时，RDB 比 AOF 更具优势。
   • 对性能影响小：RDB 快照的生成是通过子进程完成的，主进程在快照生成期间仍然可以正常处理客户端请求，因此对性能的影响相对较小。
2. 劣势：
   • 数据丢失风险：由于 RDB 是定期生成快照的，因此在两次快照之间的数据可能会丢失。例如，如果在 900 秒内有大量数据被修改，但还没有触发快照，那么这些数据在 Redis 重启时将会丢失。
   • 不适合实时持久化：由于 RDB 是定期生成快照的，因此不适合需要实时持久化的应用场景。例如，对于一些金融应用，可能需要每秒钟都进行一次数据持久化，此时 RDB 就不太适合了。
   • 文件体积较大：虽然 RDB 文件可以通过压缩来减小体积，但在某些情况下，RDB 文件的体积仍然可能比较大。例如，对于一些包含大量小键值对的数据库，RDB 文件的体积可能会比较大。

五、RDB 与 AOF 的比较

1. 数据安全性：
   • AOF 比 RDB 更安全，因为 AOF 是通过追加写操作日志的方式来进行数据持久化的，因此可以保证数据的完整性。而 RDB 是定期生成快照的，因此在两次快照之间的数据可能会丢失。
2. 数据恢复速度：
   • RDB 比 AOF 更快，因为 RDB 文件是一个紧凑的二进制文件，在恢复数据时，Redis 可以快速地将其加载到内存中。而 AOF 文件是一个文本文件，在恢复数据时，Redis 需要逐行解析文件中的命令，因此恢复速度相对较慢。
3. 文件体积：
   • RDB 文件的体积相对较小，因为 RDB 文件是通过压缩来减小体积的。而 AOF 文件的体积相对较大，因为 AOF 文件是通过追加写操作日志的方式来进行数据持久化的，因此文件中可能会包含大量的冗余信息。
4. 性能影响：
   • RDB 对性能的影响相对较小，因为 RDB 快照的生成是通过子进程完成的，主进程在快照生成期间仍然可以正常处理客户端请求。而 AOF 对性能的影响相对较大，因为 AOF 需要不断地追加写操作日志，这会增加磁盘 IO 的负担。

六、配置RDB完整步骤

步骤 1：修改 redis.conf 文件

根据业务需求调整 RDB 配置，示例如下（关键参数已标注）：

 

# 自动触发快照的条件（可自定义多个规则）  
save 900 1       # 15 分钟内至少 1 次修改  
save 300 10      # 5 分钟内至少 10 次修改  
save 60 10000    # 1 分钟内至少 10000 次修改  # RDB 文件名称与存储路径  
dbfilename redis_snapshot.rdb   # 自定义文件名  
dir /data/redis/rdb             # 存储目录（需提前创建）  # 压缩与校验和  
rdbcompression yes              # 启用压缩  
rdbchecksum yes                 # 启用校验和  # 快照失败时停止写操作（推荐）  
stop-writes-on-bgsave-error yes  

步骤 2：重启 Redis 使配置生效

修改配置后，需重启 Redis 服务：

 

# 系统服务方式（适用于 systemd）  
systemctl restart redis  # 或指定配置文件启动（测试场景）  
redis-server /path/to/redis.conf  

步骤 3：验证配置是否生效

通过 redis-cli 查看当前 RDB 配置：

 

redis-cli  
127.0.0.1:6379> CONFIG GET save  
1) "save"  
2) "900 1 300 10 60 10000"   # 显示配置的 save 规则  127.0.0.1:6379> CONFIG GET dbfilename  
1) "dbfilename"  
2) "redis_snapshot.rdb"       # 显示自定义文件名  127.0.0.1:6379> CONFIG GET dir  
1) "dir"  
2) "/data/redis/rdb"          # 显示存储目录  

五、混合持久化    

六、redis主从复制

        主要用来实现 redis 数据的可靠性；防止主 redis 所在磁盘损坏，造成数据永久丢失； 主从之间采用异步复制的方式；

一、主从复制的概念与作用

        Redis 主从复制是将一台 Redis 服务器（主节点，Master）的数据，单向复制到其他 Redis 服务器（从节点，Slave）的机制。其核心特点与作用如下：

 

• 特点：数据单向流动（仅主节点向从节点复制），主节点负责写操作，从节点负责读操作，一个主节点可拥有多个从节点，一个从节点仅对应一个主节点。
• 作用：
  • 读写分离：主节点处理写请求，从节点处理读请求，提升服务器读写负载能力。
  • 数据冗余：实现数据热备份，作为持久化之外的冗余方式。
  • 故障恢复：主节点故障时，从节点可提供服务，实现快速恢复。
  • 负载均衡：通过多个从节点分担读请求，提高并发量。
  • 高可用基础：是哨兵模式和集群实现的基石。

二、主从复制工作流程

1. 建立连接阶段

   • 从节点保存主节点 IP 和端口信息。
   • 建立 Socket 连接，从节点向主节点发送ping命令检测连接状态。
   • 若主节点设置密码，从节点通过auth命令进行身份验证。
   • 从节点向主节点发送自身监听端口号（无实际功能，仅在info Replication中显示）。

2. 数据同步阶段

   • 从节点发送psync命令（Redis 2.8 前为sync）请求同步。
   • 全量复制：初次复制或无法部分复制时，主节点生成 RDB 文件发送给从节点，从节点加载 RDB 恢复数据。
   • 部分复制：网络中断后重连，若主节点复制积压缓冲区（repl - backlog - size）保留了中断期间的写命令，仅同步这些增量命令，更高效。

3. 命令传播阶段
   主节点将后续写命令发送给从节点，从节点执行命令以保持数据一致。此过程是异步的，主从节点可能存在短暂数据不一致。

三、主从复制的配置与使用方法

假设主节点 IP 为192.168.1.100，端口6379，从节点需进行以下配置：

 

1. 方式一：修改配置文件

   • 编辑从节点的redis.conf：

     # 配置主节点IP和端口  
     slaveof 192.168.1.100 6379  
     # 若主节点有密码，需配置以下行  
     masterauth <主节点密码>  
     # 可选：修改从节点端口、日志文件、RDB文件名等避免冲突  
     port 6380  
     pidfile /var/run/redis_6380.pid  
     logfile "redis_6380.log"  
     dbfilename "dump_6380.rdb"  
     

   • 保存配置后重启从节点 Redis 服务。

2. 方式二：启动从节点命令指定

   redis-server --port 6380 --slaveof 192.168.186.138 6379 --masterauth 123456  #m如果主节点没有设置密码，此处就不需要密码

3. 方式三：客户端命令动态配置

   • 连接从节点 Redis 客户端：

     redis-cli - p 6380  
     

   • 执行命令（临时生效，重启后失效）：

     127.0.0.1:6380> slaveof 192.168.1.100 6379  
     OK  
     127.0.0.1:6380> config set masterauth <主节点密码>  # 若主节点有密码  
     OK  
     

4. 验证主从关系

   • 在主节点执行info Replication，查看connected_slaves确认从节点连接。
   • 在从节点执行info Replication，检查master_host和master_port是否正确，role是否为slave。

5. 断开主从复制
   从节点执行slaveof no one，可断开与主节点的连接，变为独立主节点（数据保留）：

127.0.0.1:6380> slaveof no one  
OK  

 

        通过以上配置，即可实现 Redis 主从复制，利用从节点分担读压力，提升系统的可用性与性能。实际应用中，还可结合哨兵模式实现主从自动切换，进一步增强高可用性。

---

        在完成主从复制配置后，Redis 主从架构的核心使用方式是读写分离：主节点处理写请求，从节点处理读请求。以下是具体的使用场景、操作方法及注意事项：

一、基础使用：读写分离操作

1. 主节点写入数据（写操作）

主节点是唯一支持写操作的节点（从节点默认只读），所有写命令（如set、hset、lpush等）需在主节点执行。

 

示例

# 连接主节点（IP:192.168.1.100，端口:6379）  
redis-cli -h 192.168.1.100 -p 6379  # 写入数据（主节点）  
192.168.1.100:6379> set username "doubao"  
OK  
192.168.1.100:6379> hset user_info id 1001 age 25  
(integer) 2  

2. 从节点读取数据（读操作）

从节点仅支持读命令（如get、hget、lrange等），用于分担主节点的读压力。

 

示例

 

# 连接从节点（假设从节点端口为6380）  
redis-cli -p 6380  # 读取主节点写入的数据（从节点）  
127.0.0.1:6380> get username  
"doubao"  
127.0.0.1:6380> hget user_info age  
"25"  

二、关键验证：确认数据同步

主从复制的核心是数据一致性，需验证主从节点数据是否同步。

1. 查看主从复制状态

• 主节点：执行info replication，查看connected_slaves（已连接的从节点数量）和master_repl_offset（主节点复制偏移量）。

  redis

  192.168.1.100:6379> info replication  
  # Replication  
  role:master  
  connected_slaves:1  
  slaves:192.168.1.101:6380,slave0,online,222,1627811200,1  
  master_repl_offset:1000  # 主节点当前数据偏移量  
  ...  
  

• 从节点：执行info replication，检查master_host（主节点 IP）、master_port（主节点端口）、master_link_status（连接状态）和slave_repl_offset（从节点复制偏移量）。

  127.0.0.1:6380> info replication  
  # Replication  
  role:slave  
  master_host:192.168.1.100  
  master_port:6379  
  master_link_status:up  # 必须为"up"，表示连接正常  
  slave_repl_offset:1000  # 应与主节点的master_repl_offset一致（或接近，因异步复制可能短暂延迟）  
  ...  
  

2. 验证数据一致性

在主节点写入一条新数据，然后在从节点读取，确认是否一致。

 

示例：

 

# 主节点写入  
192.168.1.100:6379> set test_key "hello"  
OK  # 从节点读取（等待1-2秒，因异步复制可能有延迟）  
127.0.0.1:6380> get test_key  
"hello"  # 数据一致，同步成功  

三、从节点只读特性（默认）

从节点默认配置为只读（slave-read-only yes），禁止执行写命令（如set、del等），避免数据冲突。

 

示例（从节点尝试写操作）：

 

127.0.0.1:6380> set forbidden_key "test"  
(error) READONLY You can't write against a read only replica.  # 报错，禁止写操作  

四、主节点故障后的应急处理

若主节点宕机，从节点仍可提供读服务，但无法写入。需手动（或通过哨兵自动）将从节点提升为主节点。

手动提升从节点为主节点步骤：

1. 断开从节点与原主节点的连接（使其成为独立主节点）：

   127.0.0.1:6380> slaveof no one  
   OK  
   

2. 验证角色变更：

   127.0.0.1:6380> info replication  
   # Replication  
   role:master  # 角色变更为master  
   connected_slaves:0  # 原主节点已宕机，无连接的从节点  
   ...  
   

3. 其他从节点重新指向新主节点（可选）：
   若有其他从节点，需修改其slaveof配置，指向新主节点（如192.168.1.101:6380）。

七、Redis 哨兵模式

# sentinel.cnf
# sentinel 只需指定检测主节点就行了，通过主节点自动发现从节点
sentinel monitor mymaster 127.0.0.1 6379 2
# 判断主观下线时长
sentinel down-after-milliseconds mymaster 30000
# 指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资
源要求越高
sentinel parallel-syncs mymaster 1
# 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟
sentinel failover-timeout mymaster 180000

八、Redis cluster集群        

 数据迁移

        redis cluster 提供了工具 redis-trib 可以让运维人员手动调整槽位的分配情况，它采用 ruby 语言开 发，通过组合原生的 redis cluster 指令来实现。图中：A 为待迁移的源节点，B 为待迁移的目标节点；

一、环境准备

1. 安装依赖（hiredis-cluster）

git clone https://github.com/Nordix/hiredis-cluster.git
cd hiredis-cluster
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_SSL=ON ..
make && sudo make install && sudo ldconfig

二、集群配置文件准备

1. 创建节点目录与基础配置

# 创建 6 个节点目录（3主3从）
mkdir -p 7001 7002 7003 7004 7005 7006# 编辑 7001 节点配置（其他节点通过复制修改）
vi 7001/7001.conf

2. 7001.conf 核心配置

pidfile "/home/mark/redis-data/7001/7001.pid"    # 进程文件
logfile "/home/mark/redis-data/7001/7001.log"    # 日志文件
dir "/home/mark/redis-data/7001/"                # 数据存储目录
port 7001                                        # 节点端口
daemonize yes                                    # 后台运行
cluster-enabled yes                              # 启用集群模式
cluster-config-file nodes-7001.conf              # 集群配置文件（自动生成）
cluster-node-timeout 15000                       # 节点超时时间（ms）

3. 快速生成其他节点配置

# 复制并修改端口及文件名（以 7002 为例，其他节点类似）
cp 7001/7001.conf 7002/7002.conf
sed -i 's/7001/7002/g' 7002/7002.conf
# 重复操作生成 7003~7006 配置

三、启动集群节点

1. 节点启动脚本（start_nodes.sh）

#!/bin/bash
redis-server 7001/7001.conf
redis-server 7002/7002.conf
redis-server 7003/7003.conf
redis-server 7004/7004.conf
redis-server 7005/7005.conf
redis-server 7006/7006.conf

2. 执行启动

chmod +x start_nodes.sh
./start_nodes.sh

四、初始化集群（3 主 3 从）

1. 自动创建集群（推荐）

redis-cli --cluster create \127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \--cluster-replicas 1  # 每个主节点分配 1 个从节点

2. 手动创建集群（分步操作）

# 节点会面（主节点间建立连接）
redis-cli --cluster meet 127.0.0.1:7002 127.0.0.1:7001
redis-cli --cluster meet 127.0.0.1:7003 127.0.0.1:7001# 分配槽位（16384 个槽位分配给 3 个主节点）
redis-cli --cluster addslots {0-5460} --cluster-node-id <主节点ID-7001>
redis-cli --cluster addslots {5461-10922} --cluster-node-id <主节点ID-7002>
redis-cli --cluster addslots {10923-16383} --cluster-node-id <主节点ID-7003># 分配从节点（例如 7004 作为 7001 的从节点）
redis-cli --cluster replicate <7001主节点ID> --cluster-node-id <7004节点ID>

五、集群测试与基本操作

1. 连接集群（-c 启用集群模式）

redis-cli -c -p 7001  # 连接 7001 节点
127.0.0.1:7001> set name mark  # 自动路由到对应主节点
-> Redirected to slot [5798] located at 127.0.0.1:7002
OK

2. 查看集群状态

redis-cli -p 7001 cluster info        # 集群概览
redis-cli -p 7001 cluster nodes       # 节点详细信息

3. 模拟主节点宕机

redis-cli -p 7001 shutdown  # 关闭主节点 7001
# 从节点 7004 自动提升为主节点（需等待故障转移）
redis-cli -p 7004 cluster nodes  # 验证角色变更

六、集群扩容（添加 2 个节点：7007 主节点、7008 从节点）

1. 创建新节点配置

# 复制并修改 7007/7008 配置
cp -R 7001 7007 && cd 7007
mv 7001.conf 7007.conf && sed -i "s/7001/7007/g" 7007.conf
cp -R 7007 7008 && cd 7008
mv 7007.conf 7008.conf && sed -i "s/7007/7008/g" 7008.conf

2. 启动新节点并加入集群

redis-server 7007/7007.conf
redis-server 7008/7008.conf# 添加主节点 7007（通过任意现有节点引导）
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001# 添加从节点 7008 并指定主节点（如 7007）
redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7001 \--cluster-slave --cluster-master-id <7007主节点ID>

3. 重新分配槽位（迁移 1000 个槽位到 7007）

redis-cli --cluster reshard 127.0.0.1:7001 <<EOF
1000            # 迁移槽位数
<7007节点ID>    # 目标节点ID
all             # 从所有节点迁移（或指定源节点ID）
EOF

七、集群缩容（删除节点 7007 及其从节点 7008）

1. 迁移槽位回原节点

redis-cli --cluster reshard 127.0.0.1:7001 \--cluster-from <7007节点ID> \--cluster-to <原主节点ID> \--cluster-slots 1000  # 迁移之前分配的槽位

2. 删除空节点

# 删除从节点 7008
redis-cli --cluster del-node 127.0.0.1:7001 <7008节点ID># 删除主节点 7007（需先确保槽位清空）
redis-cli --cluster del-node 127.0.0.1:7001 <7007节点ID>

0voice · GitHub