1. 前期回顾

前面的几章实现了一个高性能的点赞系统，除了性能外，系统的可用性 弹性和可扩展性也很重要

核心问题：现有系统存在单点故障风险（Redis/Pulsar/TiDB），缺乏有效降级机制

优化方向：在保证性能的基础上，增强可用性、弹性和容灾能力

实现特点：侧重架构设计思路，非具体实现（企业级运维管理）

2. 可优化方案

2.1. 数据库高可用

1. 多中心部署

• 跨区域容灾架构（两地三中心：主中心+同城/异地灾备）

2. 读写分离与故障转移
3. 降级策略

• 数据库不可用时依赖Redis缓存展示现有数据

2.2. 缓存高可用

三种高可用模式：

1. 主从复制(读写分离)
2. 哨兵模式(自动故障转移)
3. Redis 集群(数据分片)

2.3. 消息队列高可用

1. 原生容灾能力

2. 实现 pulsar 集群架构，pulsar 天生支持地理复制

3. 降级策略

4. 当不可用时，将异步点赞转换为同步处理

2.4. 容错设计

可以引入更多技术组件，常用策略是限流、降级和熔断

比如

1. 开源的高可用流控组件Sentinel实现熔断保护和限流
2. 重试 spring Retry 可以在失败时自动重试

▼
java
复制代码
@Retryable(value = {Exception.class}, maxAttempts = 3, backoff = @Backoff(delay = 1000))
public boolean doThumb(Long blogId, Long userId) {
    // 点赞业务逻辑
}

2.5. 高可用监控

• 监控维度

  • 硬件指标（CPU/内存/磁盘/网络）
  • 中间件状态（Redis命中率/Pulsar堆积量/TiDB响应）
  • 应用指标（QPS/错误率/JVM状态）

• 告警系统

  • Prometheus采集数据
  • 钉钉/企微/邮件多通道告警

• 智能调度

  • 高峰预热资源，低峰释放资源

3. 灾备演练

• 混沌工程

  • 模拟故障场景（随机宕机/网络延迟）
  • 测量RTO（恢复时间）和RPO（数据丢失量）

• 容灾切换流程

  • 多指标自动触发切换脚本
  • 保留手动切换能力与操作手册