单体架构下数据库读写分离的最简实现随着系统业务量的稳步增长当单机数据库的 CPU 使用率逐渐逼近 70% 时绝大部分压力往往来自于海量的只读查询如用户浏览、报表统计、列表检索而真实的写操作写入、更新、删除可能只占全部请求的 10%~20%。很多团队一遇到读性能瓶颈立刻开始规划复杂的分库分表Sharding或者引入昂贵的分布式数据库集群。其实在单体架构中配置一主一从数据库并实现应用层“读写分离Read/Write Splitting”以极低的改造成本就能将系统的读吞吐量瞬间翻倍轻松扛起千万级每日查询。读写分离的核心拓扑架构┌── [ 主数据库 (Master) ] (处理 INSERT / UPDATE / DELETE 事务) [ 应用层请求路由 ] ──┤ │ (数据库原生异步流复制) │ ▼ └── [ 只读从库 (Replica) ] (处理纯只读 SELECT 查询)主库Master负责所有的写入与涉及事务的核心操作从库Replica通过 PostgreSQL / MySQL 原生流复制实时同步主库数据专供报表和只读查询。40 行 TypeScript 极简双数据源路由实现在数据访问层维护两个独立的数据库连接池并根据操作类型自动分发import { Pool } from pg; export class SplitDatabaseRouter { private masterPool: Pool; private replicaPool: Pool; constructor(masterUrl: string, replicaUrl: string) { this.masterPool new Pool({ connectionString: masterUrl, max: 20 }); this.replicaPool new Pool({ connectionString: replicaUrl, max: 50 }); } // 1. 写操作与显式事务强制路由至主库 public async writeQuery(sql: string, params: any[] []): Promiseany { return this.masterPool.query(sql, params); } // 2. 普通只读查询路由至从库 public async readQuery(sql: string, params: any[] []): Promiseany { return this.replicaPool.query(sql, params); } // 3. 事务操作在主库获取物理连接并开启事务 public async transactionT(callback: (client: any) PromiseT): PromiseT { const client await this.masterPool.connect(); try { await client.query(BEGIN); const result await callback(client); await client.query(COMMIT); return result; } catch (err) { await client.query(ROLLBACK); throw err; } finally { client.release(); } } }避坑关键点主从复制延迟Replication Lag主从异步复制存在毫秒级的微小延迟。如果在用户刚下单后立刻跳转详情页查询若直接查从库可能会偶尔查出空数据。优雅解决方案在写入操作成功后的 1 秒内将该用户的后续单次查询强制路由至主库Master Pinning或者在强一致性要求的结算页面显式调用writeQuery读取主库。总结解决性能瓶颈的最好方式不是重构整个架构而是用最精巧的杠杆撬动最大的性能提升。用几十行双数据源路由代码实现读写分离让单体系统在极简中释放出强悍的吞吐潜能。