架构演进实战：从单机到分布式，Redis 的核心价值

[ 应用服务器 ] <--- 网络 ---> [ 数据库服务器 ]
(Tomcat/SpringBoot)           (MySQL/Oracle)

收益：

• 资源隔离： 应用与数据库拥有各自独立的资源池，互不影响。
• 独立优化： 应用侧重高主频 CPU，数据库侧重大内存和高速 SSD。
• 初步解耦： 明确了应用层与数据层的物理边界，为后续扩展铺平道路。

新的局限： 数据库单点故障风险依然存在，读写压力集中，网络通信开销增加。

2. 负载均衡

当用户量激增，单台应用服务器面临 CPU/内存耗尽、响应延迟飙升甚至服务不可用的风险。

解决方案： 引入负载均衡器（Nginx, HAProxy, F5, 云 ALB/SLB）。

路由算法对比：

Nginx 配置示例（加权轮询）：

upstream app_cluster {
    server 192.168.1.101:8080 weight=3; # 高配服务器
    server 192.168.1.102:8080 weight=2;
    server 192.168.1.103:8080 weight=1;
    keepalive 32; # 连接复用优化
}

server {
    location / {
        proxy_pass http://app_cluster;
        proxy_set_header X-Real-IP $remote_addr; # 传递真实 IP
    }
}

优势与新瓶颈： 并发能力线性提升，高可用保障，无缝水平扩展。但读写比例失衡（读:写 ≈ 8:2）、锁竞争加剧、连接数瓶颈等问题依然存在。

3. 读写分离

读写分离的核心思想是将数据库的读操作和写操作分离到不同的数据库实例上处理。

核心组件与流程：

• 主数据库 (Master)： 唯一负责处理所有写操作，是数据的权威来源。
• 从数据库 (Slave)： 主要负责处理读操作，通过复制机制从主库同步数据。

复制机制（以 MySQL 为例）： 主库将写操作变更记录到二进制日志 (binlog)，从库的 I/O 线程读取 binlog 写入中继日志 (Relay Log)，SQL 线程重放事件以保持数据一致。通常是异步复制。

应用层修改： 框架集成（如 Spring AbstractRoutingDataSource）、中间件代理（MyCAT, ShardingSphere）或客户端 SDK。

局限： 主库写瓶颈未解决，存在数据延迟，主库单点故障风险，应用复杂度增加。

更重要的是，无论读写分离做得多好，直接访问数据库始终是一个相对'慢'的操作，受限于磁盘 I/O、SQL 解析及锁竞争。

4. 引入缓存

为了跨越磁盘 I/O 这道鸿沟，我们引入一个高速的内存数据存储层，位于应用服务器和数据库之间。常用的成熟组件包括 Redis 和 Memcached。它们将数据存储在内存中，提供微秒级的读写访问。

核心策略：Cache-Aside Pattern (旁路缓存)

读流程：

1. 应用发起读请求。
2. 先查缓存，命中则直接返回。
3. 未命中则查数据库，并将结果写入缓存（设置 TTL）。

写流程：

1. 应用发起写请求。
2. 更新数据库。
3. 失效或删除缓存中的对应 Key（主流策略），下次读请求触发回填。

核心优点： 性能质的飞跃，显著降低数据库压力，提升吞吐量。

新挑战：

• 数据一致性： 如何确保缓存与数据库同步。
• 缓存穿透： 查询不存在的数据，直接击穿缓存打挂数据库。
• 缓存击穿： 热点 Key 过期瞬间，大量请求涌入数据库。
• 缓存雪崩： 大量 Key 同时失效或集群宕机。

毫无疑问，缓存是解决数据库读性能瓶颈的利器。但当数据量和写压力依然巨大，单库难以支撑时，我们需要下一步方案。

5. 数据库分库分表

通过将单一庞大的数据库按照特定规则水平拆分到多个独立的物理数据库中，从而突破单库在存储容量、连接数、I/O 吞吐量和 CPU 计算能力上的限制。

垂直分库： 按业务领域划分（如用户、订单、商品）。核心价值是业务解耦和资源隔离，但会导致跨库 Join 失效和分布式事务问题。

水平分库/分表：

分片键选择原则： 高频查询条件、数据分布均匀性、业务连续性。

6. 初识微服务

当单体应用发展到一定规模，即使进行了数据库层面的优化，仍面临臃肿复杂、耦合度高、技术栈单一、扩展性粒度粗等问题。

微服务架构： 将庞大的单体应用拆分为一组小型化、独立部署、松耦合、自治的服务。服务间通过轻量级通信机制（HTTP/RPC）交互。

优势： 解耦与独立，提升可维护性，增强容错性。

代价： 将单体内部的复杂性转移到了服务之间的分布式交互上，引入了分布式系统固有的复杂性问题。在这种架构下，对跨服务的状态管理、高速访问、协调与通信的需求变得空前强烈。

小结

从单机的局限出发，我们一步步构建分布式系统：数据库分离、负载均衡、读写分离、分库分表，直至微服务解耦。每一步演进，核心目标都是突破性能、可用性和扩展性的瓶颈。

然而，关系型数据库的磁盘 I/O 特性，使其在高并发、低延迟的海量请求前始终面临挑战。此时，引入缓存成为关键转折。Redis 这类高性能内存存储，不仅极大缓解了数据库压力、提升了响应速度，更在微服务架构中，从单纯缓存演变为分布式锁、会话共享、消息队列等核心组件的基石，成为维系分布式系统高效稳定的'瑞士军刀'。

理解这个演进历程，才能真正领悟 Redis 的价值——它并非凭空出现，而是为解决分布式架构核心痛点而生的利器。