TDSQL 读写分离

读写分离架构设计

基本架构

• 主库：处理所有写操作和部分读操作
• 从库：处理读操作，通过主从复制与主库保持数据同步
• 中间层：负责SQL路由和负载均衡

典型部署模式

1. 应用层读写分离

• 应用程序直接连接主从库
• 根据SQL类型（SELECT/UPDATE/INSERT/DELETE）路由到不同实例
• 适合小型应用，部署简单

2. 代理层读写分离

• 引入中间代理（如TDSQL Proxy）
• 代理自动识别SQL类型并路由
• 支持连接池、负载均衡和故障转移

3. 混合模式

• 核心业务使用代理层，边缘业务使用应用层
• 平衡性能和复杂度

配置步骤

1. 准备主从环境

确保主从复制已正常配置并运行：

-- 检查主从状态
SHOW SLAVE STATUS\G

2. 配置TDSQL Proxy

代理节点部署

• 安装TDSQL Proxy组件
• 配置代理节点网络和权限

路由规则配置

# 读写分离配置示例
[proxy]
rw_split_enabled = true
master_read_weight = 20  # 主库承担20%读请求
slave_read_weight = 80   # 从库承担80%读请求

# 从库负载均衡策略
balance_policy = roundrobin  # 轮询模式
# balance_policy = least_conn  # 最小连接数
# balance_policy = weight      # 权重模式

# 故障转移配置
failover_enabled = true
failover_timeout = 30      # 故障检测超时时间（秒）

3. 应用连接配置

连接字符串格式

jdbc:mysql://proxy_ip:proxy_port/database?useUnicode=true&characterEncoding=utf8

连接池优化

• 调整最大连接数
• 配置连接超时和存活检查
• 启用连接复用

监控与管理

1. 运行状态监控

代理层监控指标

• 读写请求分布比例
• 各节点连接数
• SQL响应时间
• 故障转移次数

从库延迟监控

-- 检查从库延迟
SELECT TIMESTAMPDIFF(SECOND, master_timestamp, CURRENT_TIMESTAMP) AS delay_seconds
FROM replication_status;

2. 常见问题排查

数据不一致问题

• 检查主从复制状态
• 验证SQL路由规则
• 确认从库延迟情况

性能瓶颈

• 分析慢查询日志
• 检查从库负载
• 调整读写权重分配

最佳实践

1. 读写分离策略选择

场景	推荐模式	优势
小型应用	应用层	部署简单，成本低
大型应用	代理层	管理集中，扩展性好
混合场景	混合模式	灵活适配不同业务需求

2. 从库数量规划

• 根据读请求量确定从库数量
• 考虑主从复制延迟影响
• 预留10-20%的冗余容量

3. 异常处理机制

• 实现从库延迟自动剔除
• 配置故障转移策略
• 建立监控告警体系

4. 性能优化

• 从库使用只读模式
• 优化从库索引
• 配置合适的复制策略（如半同步复制）

常见问题（FAQ）

Q1: 读写分离后如何处理事务中的读操作？

A1: 事务中的读操作应路由到同一节点，避免脏读。TDSQL Proxy会自动识别事务上下文，将事务内的所有操作路由到主库或同一从库。

Q2: 从库延迟过高怎么办？

A2: 可以采取以下措施：

• 优化主库写入性能，减少binlog生成量
• 升级从库硬件配置
• 增加从库数量，分担读压力
• 配置从库延迟阈值，超过阈值自动剔除

Q3: 如何处理跨库事务？

A3: 跨库事务建议使用分布式事务框架，或调整业务逻辑避免跨库事务。TDSQL支持XA事务和TCC事务模式。

Q4: 读写分离对应用代码有什么影响？

A4: 使用代理层读写分离时，应用代码无需修改，直接连接代理节点即可。使用应用层读写分离时，需要修改代码实现SQL路由逻辑。

Q5: 如何评估读写分离的效果？

A5: 可以通过以下指标评估：

• 主库负载降低比例
• 读请求分布均匀度
• 系统整体吞吐量提升
• 响应时间改善情况

Q6: 读写分离架构下如何进行数据备份？

A6: 建议在从库上执行备份操作，避免影响主库性能。可以配置定时备份任务，或使用TDSQL提供的自动备份功能。