Redis
主从复制
Redis 主从复制（Master-Slave Replication） 是 Redis 实现高可用、读写分离和数据冗余的核心机制之一。
目的：数据冗余 和 读写分离。
原理：主从复制是 Redis 高可用性的基础。它允许一个 Redis 服务器（主节点，Master）将其数 据复制到一个或多个 Redis 服务器（从节点，Slave/Replica）。
主从复制特点：
- 一个master可以有多个slave
- 一个slave只能有一个master
- 数据流向是从master到slave单向的
- master可读可写
- slave只读
主从复制实现：
当master出现故障后，可以自动提升一个slave节点变成新的master，因此redis slave需要设置和 master相同的连接密码
此外当一个slave提升为新的master时需要通过持久化实现数据的恢复
实验环境
1主2从
准备三台配置一样的虚拟机，将三台虚拟机的防火墙都关闭
redis的主从同步工作原理简单概括为：
1、salve向master发送sync命令
2、master启动后台存盘进程，并收集所有修改数据命令
3、master完成存盘后，传送整个数据文件到slave
4、slave接受数据文件，加载到内存中完成首次完全同步
5、后续有新数据产生时，master继续将新的数据命令传递给slave完成同步
配置所有数据库
bash
# 所有节点
[root@localhost ~]# cd /usr/local/redis-6.2.14/
[root@localhost redis-6.2.14]# vim redis.conf
75 bind 0.0.0.0 -::1配置从redis
bash
#slave01,slave02指向master的ip和端口
[root@localhost redis-6.2.14]# vim redis.conf
480 replicaof 192.168.108.10 6379
# 不修改配置文件，通过配置命令也可以
127.0.0.1:6379> REPLICAOF MASTER_IP PORT #新版推荐使用
127.0.0.1:6379> SLAVEOF MASTER_IP PORT #旧版使用，将被淘汰重启所有redis
bash
[root@localhost redis-6.2.14]# redis-cli shutdown
[root@localhost redis-6.2.14]# redis-server redis.conf &验证
bash
[root@master ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.108.12,port=6379,state=online,offset=280,lag=0
slave1:ip=192.168.108.11,port=6379,state=online,offset=280,lag=0
master_failover_state:no-failover
master_replid:9abdc709c2e13658f9fe30908d53b7fd2ddd8e29
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:280
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:280
[root@slave01 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.108.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_read_repl_offset:280
slave_repl_offset:280
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:9abdc709c2e13658f9fe30908d53b7fd2ddd8e29
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:280
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:280
[root@slave02 ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.108.10
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_read_repl_offset:350
slave_repl_offset:350
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:9abdc709c2e13658f9fe30908d53b7fd2ddd8e29
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:350
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:350从主节点写入数据，数据会被同步到从节点
bash
# master节点配置
127.0.0.1:6379> set name laogao
OK
# salve01,slave02查看同步过来了
127.0.0.1:6379> get name
"laogao"删除主从同步：
在从节点执行REPLICAOF NO ONE 或 SLAVEOF NO ONE指令可以取消主从复制
取消复制会断开和master的连接而不再有组从复制关联，但不会清除slave上已有的数据
bash
# 新版
127.0.0.1:6379> REPLICAOF NO ONE
# 旧版
127.0.0.1:6379> SLAVEOF NO ONEredis集群的哨兵服务
Redis 哨兵模式（Sentinel） 是 Redis 官方提供的 **高可用性（High Availability, HA）**解决方案，用于 在主从架构中实现 自动故障检测与故障转移。
目的：在主从复制的基础上，实现自动故障转移（High Availability）。
原理：哨兵是一个独立的分布式系统，由多个 Sentinel 实例（进程）组成，用于监控 Redis 主从 节点的健康状态。
概念
-
Redis Sentinel（哨兵） 是一个分布式监控系统，由一个或多个独立的sentinel 进程组成。
-
主要功能：
监控（Monitoring）：持续检查主节点（Master）和从节点（Replica）是否正常运行。 通知（Notification）：当被监控的 Redis 实例异常时，可通过 API 通知管理员或其他系统。 自动故障转移（Automatic Failover）：当主节点宕机，Sentinel 会自动将一个从节点提升 为新主节点，并更新其他从节点的复制源。 配置提供者（Configuration Provider）：客户端可通过 Sentinel 获取当前主节点地址，实 现动态服务发现。
哨兵本身 不存储数据，只负责监控和协调。
核心原理
-
架构组成
Master：主节点，处理写请求。
Replica（Slave）：从节点，复制主节点数据，可处理读请求。
Sentinel 节点：独立进程，通常部署 奇数个（如 3 个） 以避免脑裂。
-
故障转移流程
- 主观下线（SDOWN）：
某个 Sentinel 发现主节点无响应（超过 down-after-milliseconds），标记为主观下线。 - 客观下线（ODOWN）：
多个 Sentinel（≥ quorum 配置值）达成共识，确认主节点已宕机。 - 选举 Leader：
Sentinel 之间通过 Raft 算法选举出一个 Leader 负责执行故障转移。 - 提升新主：
Leader 选择一个"最优"从节点（优先级高、复制偏移量大、运行稳定）执行 REPLICAOF NO ONE，
将其转为主节点。 - 重配从节点：
其他从节点重新指向新主节点。 - 通知客户端：
通过发布/订阅机制通知客户端主节点变更。
- 主观下线（SDOWN）：
使用场景
注意：Sentinel 不解决数据分片问题，仅解决单主节点的高可用。
操作步骤
延续上面的实验，此时三台redis处于一主二从的状态
三台Redis都要做
bash
[root@master redis-6.2.14]# cp sentinel.conf sentinel.conf.bak
[root@master redis-6.2.14]# vim sentinel.conf
#主节点ip，端口以及哨兵投票数量2，当有2个及以上的哨兵认为主节点不可用时那么就是客观下线，就需要进
行主从故障转移
84 sentinel monitor mymaster 192.168.108.10 6379 2
#超过该时间主节点没有响应哨兵，则哨兵会对主节点主观下线，单位是毫秒
125 sentinel down-after-milliseconds mymaster 30000启动哨兵
三台Redis都要做
bash
[root@localhost redis-6.2.14]# redis-sentinel sentinel.conf &
[2] 9203查看哨兵状态
bash
[root@master redis-6.2.14]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.108.10:6379,slaves=2,sentinels=3验证
模拟故障将master关机，发现剩下两台slave主机开始选举新master主机
将master恢复试试
bash
#启动并放在后台运行
[root@master ~]# cd /usr/local/redis-6.2.14/
[root@master redis-6.2.14]# redis-server redis.conf &
[root@master redis-6.2.14]# redis-sentinel sentinel.conf &master成为slave
总结：哨兵模式是 Redis 实现 自动高可用 的标准方案，适用于对可用性要求高、但无需数据分片的业务场景。对于超大规模集群，应考虑 Redis Cluster。
redis集群（3主3从）
Redis 集群（Cluster） 是 Redis 3.0+ 官方推出的分布式解决方案，核心是数据分片（Sharding）+ 主从复制 + 去中心化故障转移，解决单机 Redis 的容量、性能、单点故障瓶颈，实现水平扩展、高可用、高并发。
一、核心概念
-
基本定义
Redis 集群是无中心架构的分布式系统，数据自动分散到多个节点，每个节点只存部分数据；节点间通过 Gossip 协议通信，自带故障转移，无需 Sentinel。
-
关键角色
主节点（Master）：处理读写、管理哈希槽、参与故障投票，是核心节点。
从节点（Replica/Slave）：异步复制主节点数据，默认只读；主节点宕机时自动选举晋升为主。
哈希槽（Hash Slot）：集群固定 16384 个槽（0~16383），是数据分片的最小单位。
节点 ID：每个节点唯一标识，用于集群内识别与通信。
-
核心特性
数据分片：突破单机内存限制，总容量 = 所有主节点内存之和。
高可用：部分节点故障不影响整体，自动故障转移。
线性扩展：加节点即可提升容量与并发。
去中心化：无中心节点，避免单点瓶颈。
从节点（Replica/Slave）：异步复制主节点数据，默认只读；主节点宕机时自动选举晋升为主。
哈希槽（Hash Slot）：集群固定 16384 个槽（0~16383），是数据分片的最小单位。
节点 ID：每个节点唯一标识，用于集群内识别与通信。
-
核心特性
数据分片：突破单机内存限制，总容量 = 所有主节点内存之和。
高可用：部分节点故障不影响整体，自动故障转移。
线性扩展：加节点即可提升容量与并发。
去中心化：无中心节点，避免单点瓶颈。
自动路由：客户端连接任意节点，自动重定向到目标节点。