读写分离常见架构？ProxySQL / MyCat / 应用层路由 各自的优劣？

考察要点

这道题旨在考察你对数据库高可用架构的理解深度，特别是读写分离这一核心场景。面试官想看你是否懂：

1. 不同架构方案的实现原理和本质区别：即应用层、代理层两种模式的根本差异。
2. 技术选型中的权衡（Trade-off）能力：能否清晰阐述 ProxySQL、MyCat 和应用层路由在透明度、性能、运维成本、功能丰富度等维度的优劣。
3. 生产实践中的问题洞察力：是否意识到主从延迟、事务一致性、中间件高可用等关键问题，并知道如何应对。

核心概念

读写分离（Read-Write Splitting）是利用 MySQL 主从复制（Replication）能力，将写请求（INSERT, UPDATE, DELETE）路由到主库（Master），将读请求（SELECT）路由到从库（Slave），从而分摊主库的读压力，提升整个数据库集群的吞吐能力。

实现读写分离主要有三种主流架构：

1. 应用层路由（Application-Level Routing）

在应用程序代码内部实现数据库连接的管理和请求路由。

• 架构图示:

 1graph TD
 2    App[应用程序] -- 写请求 --> DBM(MySQL Master)
 3    App -- 读请求 --> DBS1(MySQL Slave 1)
 4    App -- 读请求 --> DBS2(MySQL Slave 2)
 5    DBM -- 复制 --> DBS1
 6    DBM -- 复制 --> DBS2

• 核心逻辑: 应用代码（或框架，如 Spring 的 AbstractRoutingDataSource）根据 SQL 类型动态选择数据源。
  java

  ⧉⛶

   1// 伪代码示例
   2if (isWriteOperation(sql)) {
   3    connection = getMasterConnection();
   4} else {
   5    connection = getSlaveConnection(); // 可能包含负载均衡逻辑
   6}

2. 中间件代理（Middleware Proxy）

在应用和数据库之间部署一个独立的代理服务，由代理服务负责解析 SQL 并将其路由到正确的数据库实例。

• 架构图示:

 1graph TD
 2    subgraph "对应用透明"
 3        Proxy(数据库中间件)
 4    end
 5    App[应用程序] -- 所有请求 --> Proxy
 6    Proxy -- 写请求 --> DBM(MySQL Master)
 7    Proxy -- 读请求 --> DBS1(MySQL Slave 1)
 8    Proxy -- 读请求 --> DBS2(MySQL Slave 2)
 9    DBM -- 复制 --> DBS1
10    DBM -- 复制 --> DBS2

• 代表产品: ProxySQL, MyCat。

ProxySQL

一个轻量级、高性能的数据库代理，专注于路由、缓存和性能监控。

• 特点:
  • 协议层解析: 性能极高，对应用无侵入。
  • 高级路由规则: 可基于用户、Schema、甚至 SQL 模式（正则匹配）进行灵活路由。
  • 连接复用: 高效的连接池，极大降低后端数据库的连接压力。
  • 运行时配置: 无需重启即可动态加载配置（如增删节点、修改规则）。
  • 不支持分库分表: 专注于读写分离和连接管理，不处理数据分片逻辑。

MyCat

一个功能全面的数据库中间件，不仅支持读写分离，还提供强大的分库分表能力。

• 特点:
  • 逻辑库与逻辑表: 对应用屏蔽了后端物理库和表的细节，应用只需连接 MyCat 创建的逻辑库。
  • 分库分表: 核心功能，支持多种分片规则（如范围、哈希、枚举）。
  • 功能全面: 集成了读写分离、分库分表、全局序列号等多种功能，相对“重”。
  • 社区驱动: 发展活跃，但相比 ProxySQL，在纯粹的读写分离场景下可能性能开销稍大。

架构对比

常见低分回答

1. 混淆 ProxySQL 和 MyCat：回答“用 ProxySQL 做分库分表”，或“MyCat 是一个轻量级代理”。这是对产品定位不清的典型错误。ProxySQL 核心是路由和池化，MyCat 核心是分片。
2. 忽略应用层方案：只谈代理方案，认为应用层直连是过时的。在一些简单或对延迟极度敏感的场景，应用层方案因其简单直接、性能损耗最低，仍有一席之地。
3. 对代理的缺点避而不谈：只说代理的好处（透明、解耦），却不提其引入的SPOF（单点故障风险）、额外的网络延迟、运维复杂性等问题。一个高分回答必须包含 Trade-off 的思考。
4. 完全不提主从延迟问题：这是读写分离架构的“阿喀琉斯之踵”。如果候选人完全没意识到“刚写入的数据可能读不到”这一核心问题，说明其实践经验严重不足。
5. 认为代理是银弹：声称引入代理后，应用层就完全不用关心数据一致性了。实际上，对于“读自己写”这类场景，仍需应用或代理进行特殊处理（如强制主库读）。

工程实践与优化

1. 代理层高可用（HA）：代理本身会成为单点故障。生产环境必须部署代理集群，前端通过 LVS、HAProxy 或 DNS 负载均衡，并使用 Keepalived 等工具实现 VIP（虚拟IP）漂移，保证代理服务的高可用。
2. 处理主从延迟（Replication Lag）：
   • 监控与熔断：ProxySQL/MyCat 都能监控从库的 Seconds_Behind_Master。当延迟超过阈值时，代理会自动将该从库从读节点池中摘除（熔断），延迟恢复后再加入。
   • 强制主库读：对于数据一致性要求极高的读请求（如支付成功后查询订单状态），可以通过特定方式强制路由到主库。
     • SQL 注释法：SELECT /*master*/ * FROM orders WHERE id = ?。代理识别注释后，将请求发往主库。
     • 特定端口/用户法：配置代理，让来自特定端口或用户的连接全部走主库。
   • 半同步复制（Semi-Synchronous Replication）：在 MySQL 5.7+ 中，可以开启半同步复制，确保至少有一个从库已接收到 binlog event 后，主库才向客户端返回事务提交成功。这以牺牲一定的写性能为代价，换取更高的数据一致性保证。
3. 事务一致性：
   • 一个完整的事务（BEGIN...COMMIT）内的所有读写请求必须路由到同一个节点，通常是主库。现代代理（如 ProxySQL）能自动识别事务边界，并将整个事务绑定到主库连接上，避免事务内的读请求被错误地路由到从库。
4. 连接池优化：代理层的连接池是核心价值之一。它将应用侧大量的短连接，复用为与后端数据库的少量长连接，极大减轻了 MySQL 服务器频繁创建和销毁线程的开销，提升了整体性能。

常见追问与延伸题目

1. 追问：如果主库发生故障，读写分离架构如何应对？切换过程对应用是什么影响？

   • 回答要点：这考察的是数据库整体高可用方案。
     • 故障探测与切换：需要一个自动化的主从切换（Failover）机制，如 MHA、Orchestrator 或 MySQL Group Replication (MGR)。这些工具能自动探测主库宕机，选举新主库，并处理其他从库指向新主库的逻辑。
     • 代理层联动：主从切换后，必须立刻通知代理层新的主库地址。MHA/Orchestrator 在完成切换后可以执行一个回调脚本，该脚本调用代理的管理接口，动态更新后端服务器列表，将旧主库标记为下线，新主库标记为写节点。
     • 对应用的影响：如果整套切换是自动化的，对应用的影响是短暂的连接中断和错误。应用代码需要有重试机制。从故障发生到切换完成，整个服务会有秒级到分钟级（取决于配置和方案）的写不可用窗口。读请求如果代理配置得当，仍可部分由从库提供服务。

2. 追问：如何保证用户刚注册完，马上登录时能读到自己的信息？（即“读己之写”一致性）

   • 回答要点：这是主从延迟问题的典型场景。
     • 会话级主库绑定：在用户完成写操作（如注册）后，在同一个会话（Session）或一段时间内，将该用户的所有读请求都强制路由到主库。可以通过在应用层设置 Cookie/Session 标记，或代理层基于用户 ID 等信息制定路由规则实现。
     • 等待同步：写操作完成后，后端服务可以查询主库当前的 binlog position (GTID)，然后轮询从库，直到从库应用到该 position，再将读请求放行。这种方式实现复杂，且会增加读延迟，不常用。
     • 业务设计规避：在某些场景下，写操作完成后，直接将写入的数据返回给前端，前端用这些数据进行下一步操作（如登录后的用户信息展示），从而避免立即发起一次读请求。

3. 追问：如果业务发展，数据量暴增，单库写压力也到了瓶颈，下一步架构该如何演进？

   • 回答要点：这是从读写分离到分库分表的演进问题。
     • 演进方向：当写请求成为瓶颈时，读写分离无法解决问题，需要引入水平分片（Sharding），即分库分表。
     • 方案选择：此时 MyCat 的优势就体现出来了，因为它原生支持分库分表。可以将架构从 ProxySQL 切换到 MyCat，或者使用其他分库分表中间件（如 ShardingSphere）。
     • 演进路径：这是一个复杂的工程。需要选择分片键（Sharding Key），制定分片规则，进行数据迁移（通常需要双写和数据校验），并改造应用。这是一个从垂直扩展（读写分离）到水平扩展（分库分表）的质变，对架构和运维能力提出了更高的要求。