TimescaleDB 读写分离性能对比与端口规划一、背景与目标1. 项目背景在 TimescaleDB 基于 PostgreSQL 的复制能力之上，常见落地路径包括：单机部署主从部署（1 主 1 从）三节点以上高可用架构（多节点选主，通常配合 Patroni 等组件与 DCS）同时，业务侧常会引入读写分离，以提升读性能并降低主库压力。2. 设计目标性能目标：比较不同拓扑下写入延迟、读取吞吐与读延迟的变化可用性目标：评估故障切换对整体性能的冲击与恢复时延接入目标：明确读写分离在业务侧是否需要单独 TCP 端口，以及如何规划连接入口二、现状与术语说明1. 单机（单实例）所有写与读都指向同一个 TimescaleDB/PostgreSQL 实例。2. 主从（1 主 1 从）主库负责接收写入从库通过 PostgreSQL 流复制接收 WAL 并尽量保持数据同步业务可以选择将读请求路由到从库（读写分离）3. 三节点及以上高可用（多节点选主）多个 PostgreSQL 节点参与选主任意时刻由唯一 Leader 承担写入（其余为待机/从属）DCS（如 etcd/consul 等）用于协调选主与心跳故障切换通常自动化，RTO 更可控4. 读写分离（应用接入视角）读写分离关注的是：业务层如何把“写连接”与“读连接”指向不同的数据库角色或入口。三、读写分离的业务侧端口是否需要单独配置结论：不一定必须“端口不同”，但必须让业务能够明确区分写入口与读入口，并且正确路由到主库/从库。1. 为什么不强制端口必须不同PostgreSQL/TimescaleDB 监听端口可以相同也可以不同，取决于部署方式（配置端口、容器端口映射、网络拓扑）真正决定读写分离效果的是：应用能否把连接明确路由到“主（写）”和“备（读）”2. 常见实现方式（从易到灵活）写入口与读入口使用不同的 TCP 端口写连主库：主库地址:端口A读连从库：从库地址:端口B端口相同但地址不同（不同 IP/主机名）写连主库：primary_host:5432读连从库：replica_host:5432端口相同但依赖负载均衡或 VIP 路由规则写 VIP：db-write:5432 指向当前主库读 VIP：db-read:5432 指向从库池端口不变，路由由 VIP/LB/代理层决定3. 实务建议在应用配置层面至少准备两个数据源入口：写数据源与读数据源（可以同端口，也可以不同端口）如果使用连接池，建议读写分开维护，避免把连接误用到错误角色关注“写后读一致性”：关键读如果要求尽量读到最新数据，可能需要走主库或等待复制追赶，否则读从库会读到延迟数据四、单机、主从、三节点以上高可用的性能对比性能比较建议按三个维度看：写入延迟与吞吐、读取性能、故障切换期间的波动。1. 写入性能（延迟与吞吐）1.1 单机（单实例）通常是写入延迟最低、吞吐最高的基线方案1.2 主从（1 主 1 从）异步复制时：写入性能通常接近单机额外开销主要来自主库向从库发送 WAL、网络与从库接收处理同步或准同步策略时：写入延迟会明显受影响提交等待从库确认的行为会引入网络往返与确认策略的开销1.3 三节点及以上高可用（多节点选主）无论是否选主，复制层面通常带来更高成本：Leader 需要把 WAL 扇出到更多待机节点（复制扇出效应更明显）如果引入同步或准同步保证更强一致性，则提交延迟还会受“法定确认方数量/超时策略”影响因此常见经验排序是：单机最好主从（异步）通常接近单机主从（同步）与多节点 HA 的写入延迟通常更高，更依赖网络与复制策略影响写入性能的关键因素（不分拓扑）：网络带宽与延迟（主到从、Leader 到各节点）主库与从库资源（CPU/内存/磁盘）WAL 发送/接收压力、复制槽与落后处理策略事务提交是否等待复制确认（同步/准同步）2. 读取性能（吞吐与延迟）2.1 单机读与写竞争同一套资源，读多时可能把读延迟抬高2.2 主从 + 读写分离把读压力分摊到从库后，整体读吞吐通常提升读延迟取决于复制落后情况：从库落后较小：体验接近主库从库落后较大：最新数据读取可能不稳定，需要业务策略兜底（关键读走主库或等待追赶）2.3 三节点及以上高可用如果读侧能把请求分发到多个 standby，读吞吐潜力更大切换与路由调整期间，连接可能发生短暂停顿或重建，读延迟会出现波动3. 故障切换期间的性能冲击（RTO/RPO）主从：切主往往更偏人工或半自动，写不可用时间与重建耗时不确定性更大三节点 HA：选主机制更自动化，通常能更快恢复写入，但仍会出现短时连接重建与性能抖动五、对比总结（用于选型的直观结论）方案写入延迟预期写入吞吐预期读性能预期切换期间体验单机最低最高取决于读写竞争无切换问题主从（异步）接近单机（略高）接近单机读可分摊，从库落后决定体验需要切主，RTO 更不确定多主从/高可用（同步或较强一致性）通常更高，受 RTT 与确认策略影响可能下降可分摊读，但需处理切换路由自动切换更快，但仍有抖动六、压测与验收建议（建议重点验证）1. 建议压测指标写入吞吐（TPS 或 QPS）与写入延迟（P50/P95/P99）复制延迟（从库落后时长、WAL 相关指标）读延迟（读写分离后的 P99）切换时的：故障探测时间新 leader 就绪时间（RTO）连接错误率与恢复时延（应用侧可观测指标）2. 建议压测用例写为主：连续写入 + 正常聚合/连续聚合刷新（避免只测纯写导致误判）读为主：按业务典型时间窗查询（最近 N 分钟 vs 跨天范围），验证从库落后下的体验混合：按业务比例做读写混合压测故障注入：模拟主库/leader 故障，观测切换期间应用错误与恢复延迟七、实施要点（围绕你们的问题落地）业务侧准备两套入口：写入口与读入口（端口是否不同取决于网络与代理策略，但必须可区分）连接池读写分离，避免连接被错误复用明确写后读一致性策略：关键读走主库或做追赶等待监控复制落后与复制健康度，避免读从库越来越旧但业务未感知做切换演练，验证 RTO、应用可用性与恢复过程中的性能波动