点一下关注吧！！！非常感谢！！持续更新！！！

🚀 AI 篇持续更新中！（长期更新）

AI 炼丹日志-30-新发布【1T 万亿】参数量大模型！Kimi‑K2 开源大模型解读与实践，持续打造实用 AI 工具指南！📐🤖

💻 Java 篇正式开启！（300 篇）

目前 2025 年 07 月 21 日更新到：

Java-77 深入浅出 RPC Dubbo 负载均衡全解析：策略、配置与自定义实现实战 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解

章节内容

上节我们完成了：

• Redis 分布式锁

• Redis SETNX

• Redis Redisson

• 分布式锁对比

• Java 的部分实现

高可用介绍

概念定义

高可用（High Availability，简称 HA）是指系统或服务经过专门设计后，能够长时间保持正常运行，将非计划性停机时间降至最低的技术特性。高可用性通常用"几个 9"来衡量，例如 99.9%（每年停机时间 8.76 小时）或 99.99%（每年停机时间 52.6 分钟）。

实现原理

高可用系统通常通过以下机制实现：

1. 冗余设计：部署多个相同功能的组件，当主组件失效时可以自动切换到备用组件

2. 故障检测：实时监控系统健康状态，快速发现故障

3. 自动恢复：在检测到故障后自动启动恢复流程

4. 负载均衡：将请求合理分配到多个节点，避免单点过载

CAP 理论与 AP 模型

在分布式系统的 CAP 理论（一致性 Consistency、可用性 Availability、分区容错性 Partition tolerance）中，高可用系统通常采用 AP 模型：

• AP 模型：优先保证可用性和分区容错性，在出现网络分区时仍能提供服务，但可能牺牲强一致性

• 典型应用场景：电商网站、社交网络等对服务连续性要求高的系统

典型应用场景

1. 金融交易系统：需要 7×24 小时不间断运行

2. 在线服务：如云存储、视频流媒体等

3. 关键基础设施：电力系统、通信网络等

实现技术示例

• 负载均衡：Nginx、HAProxy

• 服务发现：Consul、Zookeeper

• 容器编排：Kubernetes

• 数据库集群：MySQL 主从复制、Redis 哨兵模式

挑战与权衡

实现高可用需要考虑：

• 成本：冗余组件增加硬件投入

• 复杂性：系统架构设计难度增加

• 性能影响：如数据同步带来的延迟

现代云计算平台（如 AWS、Azure）都提供了完善的高可用服务，大大降低了企业实现高可用的技术门槛。

Redis 主从复制详解

基本概念

Redis 主从复制(Master-Slave Replication)是一种数据同步机制，允许将一台 Redis 服务器(主节点)的数据复制到其他 Redis 服务器(从节点)上，实现数据冗余备份和读写分离。

配置方式

1. 命令行配置

• 在 Redis 5.0 及以后版本，使用REPLICAOF命令：

  REPLICAOF master_host master_port

• 在 Redis 5.0 之前的版本，使用SLAVEOF命令：

  SLAVEOF master_host master_port

2. 配置文件设置

在 redis.conf 配置文件中可以永久设置主从关系：

replicaof 192.168.1.100 6379# 或旧版本中使用：# slaveof 192.168.1.100 6379

工作原理

1. 初始化同步：

2. 从节点连接主节点并发送 SYNC 命令

3. 主节点执行 BGSAVE 生成 RDB 文件，同时缓冲新写入的命令

4. 主节点将 RDB 文件发送给从节点

5. 从节点清空自身数据并加载 RDB 文件

6. 主节点将缓冲区的写命令发送给从节点执行

7. 增量同步：

8. 主节点将每个写命令发送到从节点

9. 从节点接收并执行这些命令，保持与主节点数据一致

应用场景

1. 数据冗余：实现数据备份，提高数据安全性

2. 读写分离：主节点负责写操作，从节点处理读请求

3. 故障恢复：当主节点故障时，可以提升从节点为主节点

4. 负载均衡：多个从节点分担读取压力

注意事项

1. Redis 主从复制默认是异步的，存在数据不一致的短暂窗口期

2. 从节点默认是只读的，可以通过配置replica-read-only修改

3. 复制过程中网络断开会自动重连并尝试部分重同步

4. 主节点不需要任何配置即可接受从节点连接

一主一从

一主多从

传递复制

主从配置

主 Redis

无需特殊的配置

从 Redis

我们需要修改 redis.conf 文件，来实现。比如我的主 Redis 是 h121 机器，当前我当前在 h122 上，计划变为 h121 的从服务器，那你需要如下的配置：

replicaof h121.wzk.icu 6379

主从作用

• 读写分离：一主多从，主从同步，主写从读。

• 数据容灾：从是主的备份。

同步模式

全量同步

全量同步是主从复制过程中最基础的同步方式，主要用于 Slave 节点初次连接 Master 或需要完全重建数据时。整个过程分为三个关键阶段：

1. 同步快照阶段

2. Master 节点执行 BGSAVE 命令，在后台生成当前数据的 RDB 快照文件

3. 快照生成期间，Master 继续处理客户端请求，所有新的写命令会被记录到专用的复制缓冲区(replication buffer)

4. 当 RDB 文件生成完成后，Master 将其传输给 Slave 节点

5. Slave 接收到 RDB 文件后，会清空自身原有数据，然后完整加载这个快照

6. 示例：当新部署一个 Slave 节点时，首次连接 Master 就会触发此阶段

7. 同步写缓冲阶段

8. Master 将快照生成期间积压在复制缓冲区中的所有写命令发送给 Slave

9. 这个阶段确保在生成 RDB 快照期间发生的数据变更不会丢失

10. Slave 按顺序执行这些缓冲的命令，使其数据状态与 Master 保持一致

11. 应用场景：在高写入负载的系统，这个阶段可能包含大量命令，需要足够的网络带宽支持

12. 同步增量阶段

13. 完成前两个阶段后，Master 进入常规复制模式

14. Master 将每个收到的写命令实时转发给 Slave 执行

15. Slave 持续接收并执行这些命令，保持与 Master 的数据同步

16. 该阶段会一直持续，直到连接断开或发生新的全量同步

17. 步骤说明：Master 为每个 Slave 维护一个复制偏移量(replication offset)，用于跟踪同步进度

注意：全量同步是一个资源密集型操作，在网络带宽有限或数据量大的情况下，可能导致较长时间的同步延迟。生产环境中应合理配置自动故障转移和部分重同步机制来优化这个过程。

增量同步

• Redis 增量同步主要是 Slave 完成初始化正常工作后，Master 的写操作同步到 Slave

• 通常情况下， Master 每次执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 执行。

心跳监测

在命令阶段，从服务器默认会以每秒一次的频率向主服务器发送命令：

replconf ack <replication_offset>

主要有如下的作用：

• 检测主从的连接状态

• 辅助实现 min-slaves

• 检测命令丢失

哨兵模式

哨兵介绍

哨兵（Sentinel）是 Redis 官方提供的高可用性解决方案，由一个或多个 Sentinel 实例组成的分布式系统，用于监控 Redis 主从服务器的运行状态。当主服务器出现故障时，Sentinel 能够自动执行故障检测和故障转移操作，确保 Redis 服务的持续可用性。

核心功能

1. 监控：

2. 持续检查主服务器和从服务器的运行状态

3. 定期向 Redis 实例发送 PING 命令检测响应情况

4. 记录实例的配置信息和复制关系

5. 通知：

6. 当监控的 Redis 实例出现问题时，可以通过 API 通知系统管理员或其他应用程序

7. 支持通过脚本、邮件等方式发送告警信息

8. 自动故障转移：

9. 当主服务器不可达时，自动启动故障转移流程

10. 从从服务器中选举出新的主服务器

11. 修改相关配置，使其他从服务器复制新的主服务器

12. 当旧的主服务器重新上线时，将其配置为新的主服务器的从服务器

工作原理

1. 主观下线（SDOWN）：

2. 单个 Sentinel 实例检测到主服务器无响应超过指定时间（可配置）

3. 该 Sentinel 会认为主服务器处于主观下线状态

4. 客观下线（ODOWN）：

5. 多个 Sentinel 实例（需达到 quorum 数量）都检测到主服务器无响应

6. Sentinel 集群会通过 Gossip 协议交换信息并达成共识

7. 确认主服务器处于客观下线状态

8. 选举领导者：

9. Sentinel 集群通过 Raft 算法选举出一个领导者 Sentinel

10. 领导者负责执行故障转移操作

11. 故障转移：

12. 从可用的从服务器中选出最优候选作为新的主服务器

13. 向其他从服务器发送 SLAVEOF 命令，使其复制新的主服务器

14. 更新客户端配置，使其连接到新的主服务器

配置示例

# sentinel.conf 示例配置sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 180000sentinel parallel-syncs mymaster 1

应用场景

1. 电商系统：确保购物车、秒杀等高并发场景下的 Redis 服务高可用

2. 社交平台：保障用户关系、消息队列等核心数据的持久可靠

3. 金融系统：需要 7×24 小时不间断服务的支付、交易系统

4. 物联网平台：处理大量设备实时数据的存储和查询

最佳实践

1. 部署至少 3 个 Sentinel 实例，分布在不同的物理机器上

2. 合理配置down-after-milliseconds参数，平衡敏感性和误报率

3. 定期测试故障转移功能，确保系统可靠性

4. 监控 Sentinel 的运行状态和日志信息

部署方案

配置过程

由于需要启动很多，所以直接使用容器的方式部署。

version: '3'
services:  redis-master:    image: redis:6.2    container_name: redis-master    command: redis-server --appendonly yes    ports:      - 6379:6379    volumes:      - ./data/redis-master:/data
  redis-slave1:    image: redis:6.2    container_name: redis-slave1    command: redis-server --slaveof redis-master 6379    ports:      - 6380:6379    volumes:      - ./data/redis-slave1:/data    depends_on:      - redis-master
  redis-slave2:    image: redis:6.2    container_name: redis-slave2    command: redis-server --slaveof redis-master 6379    ports:      - 6381:6379    volumes:      - ./data/redis-slave2:/data    depends_on:      - redis-master
  sentinel1:    image: redis:6.2    container_name: sentinel1    command: >      sh -c "echo 'port 26379' > /data/sentinel.conf &&             echo 'sentinel monitor mymaster redis-master 6379 2' >> /data/sentinel.conf &&             echo 'sentinel down-after-milliseconds mymaster 5000' >> /data/sentinel.conf &&             echo 'sentinel failover-timeout mymaster 10000' >> /data/sentinel.conf &&             echo 'sentinel parallel-syncs mymaster 1' >> /data/sentinel.conf &&             redis-sentinel /data/sentinel.conf"    ports:      - 26379:26379    depends_on:      - redis-master      - redis-slave1      - redis-slave2
  sentinel2:    image: redis:6.2    container_name: sentinel2    command: >      sh -c "echo 'port 26380' > /data/sentinel.conf &&             echo 'sentinel monitor mymaster redis-master 6379 2' >> /data/sentinel.conf &&             echo 'sentinel down-after-milliseconds mymaster 5000' >> /data/sentinel.conf &&             echo 'sentinel failover-timeout mymaster 10000' >> /data/sentinel.conf &&             echo 'sentinel parallel-syncs mymaster 1' >> /data/sentinel.conf &&             redis-sentinel /data/sentinel.conf"    ports:      - 26380:26380    depends_on:      - redis-master      - redis-slave1      - redis-slave2
  sentinel3:    image: redis:6.2    container_name: sentinel3    command: >      sh -c "echo 'port 26381' > /data/sentinel.conf &&             echo 'sentinel monitor mymaster redis-master 6379 2' >> /data/sentinel.conf &&             echo 'sentinel down-after-milliseconds mymaster 5000' >> /data/sentinel.conf &&             echo 'sentinel failover-timeout mymaster 10000' >> /data/sentinel.conf &&             echo 'sentinel parallel-syncs mymaster 1' >> /data/sentinel.conf &&             redis-sentinel /data/sentinel.conf"    ports:      - 26381:26381    depends_on:      - redis-master      - redis-slave1      - redis-slave2