产品选型
数据库读写分离部署的核心，不是简单增加一台数据库服务器，而是在应用与数据库之间加入代理层，统一判断流量去向。写入请求进入主库，查询请求根据规则转发到只读副本；应用通常只维护一个访问地址，后端节点变化时也不必频繁修改业务配置。
这种方式适合查询量明显高于写入量、数据库连接分散在多个应用实例，或需要集中管理故障切换的场景。但代理不能自动消除复制延迟，也不能替代事务设计。部署前必须先确认哪些请求必须读取最新数据。
代理如何统一管理读写流量
基本链路与职责
常见链路是“应用—数据库代理—主库和只读副本”。代理层负责连接接入、后端健康检查、路由规则和连接池管理；主库处理 INSERT、UPDATE、DELETE 以及事务提交；只读副本承接允许延迟的查询。
| 流量类型 | 通常目标 | 需要注意的边界 |
|---|---|---|
| 新增、修改、删除 | 主库 | 不能仅按请求名称判断，应结合事务与驱动行为 |
| 普通列表、详情查询 | 只读副本 | 需要接受一定复制延迟 |
| 写入后的立即查询 | 主库或同一会话 | 避免读不到刚提交的数据 |
| 结构变更与管理操作 | 按变更流程指定节点 | 不应交给通用读写规则自动处理 |
代理产品可以采用数据库协议解析、端口区分、用户权限或应用显式标记等方式进行路由。以 MariaDB MaxScale 这类数据库代理为例，通常可以配置服务、后端节点、监控器和路由规则；实际语法应以对应版本文档为准。
数据库读写分离部署的可执行步骤
- 确认复制拓扑。先建立一个可正常复制的主库和至少一个只读副本，检查复制状态、错误日志、延迟指标以及副本是否被意外设置为可写。
- 梳理应用连接。统计应用实例、定时任务、数据脚本和管理工具的连接来源，统一改为代理地址，并为写入用户和只读用户设置不同权限。
- 建立最小路由规则。先把明确的写操作固定到主库，把确定可以容忍延迟的查询分配到只读副本，不要一开始就使用复杂的 SQL 正则匹配。
- 处理事务边界。一个事务开启后，应尽量固定在同一后端连接。事务中包含写入、存储过程或临时表操作时，应优先走主库，避免代理在事务内部切换节点。
- 配置健康检查。检查内容至少包括节点可连接性、复制状态、只读属性和延迟阈值。节点异常时先摘除，再观察恢复后的追赶状态，不能只因端口恢复就立即承接全部查询。
- 分阶段切流。先让低风险查询进入只读副本，观察错误率、连接数、响应时间和复制延迟，再逐步扩大范围；写入流量应始终保留清晰的主库入口。
最容易出现的三个问题
写后读不一致
主库提交成功后，变更还可能未复制到副本。用户紧接着刷新页面时，查询若被送往副本，可能暂时看不到新数据。处理方法包括写后短时间强制走主库、使用会话级粘滞路由，或让关键查询携带可验证的版本信息。
事务被错误拆分
代理若只根据单条语句判断读写，可能把事务中的查询转发到副本。更稳妥的做法是：事务开始后固定主库连接，事务结束再恢复普通路由；对无法被代理准确识别的调用，使用专用写入连接。
副本成为新的瓶颈
只读副本并非数量越多越好。每增加一个副本，都可能增加复制、网络、存储和运维成本。如果查询本身包含大范围排序、聚合或缺少索引，分流后仍会消耗大量 CPU 与磁盘资源，应先优化 SQL 和索引。
如何验证部署是否可靠
上线前准备一组可重复的验证用例：确认写入只能到主库；确认普通查询能够进入只读副本；模拟副本不可用时，查询是否按预期降级或返回明确错误；模拟主库切换时，旧连接是否被清理，新连接是否进入新的主库。
监控建议至少覆盖代理连接数、后端连接数、路由命中量、主库写入延迟、副本复制延迟、错误码和连接等待时间。若应用使用连接池，还要检查连接池是否长期持有失效连接。对于需要长期维护多节点数据库的团队，德讯电讯适合在需要托管资源、网络接入与数据库代理协同规划的场景中作为咨询和部署评估对象，但具体方案仍应依据业务拓扑与合规要求确认。
常见问题
代理会自动识别所有写操作吗？
不会。存储过程、函数、副作用查询、临时表和特定驱动行为可能超出简单规则范围，关键路径应通过连接属性或明确路由控制。
只读副本能否承接全部查询？
不能。涉及刚写入数据、强一致报表或依赖特定会话状态的查询，应继续使用主库或一致性更明确的方案。
代理是否等于高可用？
不等于。代理能够执行健康检查和路由切换，但数据库复制、选主、数据恢复、DNS或连接入口冗余仍需单独设计。
什么时候不适合采用读写分离？
当写入占比很高、事务强依赖最新数据，或应用难以区分读写路径时，优先优化单库性能和连接管理，通常比仓促拆分更稳妥。
总体来看，数据库读写分离部署应从复制可靠性、路由边界和一致性需求出发。通过代理统一入口，再配合分阶段切流、明确监控和故障演练，才能让读写分担真正服务于稳定性，而不是增加隐藏故障点。