微服务间PostgreSQL表部分列近实时单向同步方案咨询

你的调研方向完全正确，PostgreSQL逻辑复制就是这个场景下的最优解，完全没必要自己开发业务层的消息同步逻辑。

方案选型对比 #

首选：PostgreSQL 原生逻辑复制（PG10+ 版本支持） #

完全匹配你所有核心需求：

• 原生支持部分列复制：创建发布时可以直接指定需要同步的字段，不需要同步整表，刚好满足你只同步id、deletedAt字段的要求
• 天然适配单向同步：复制进程仅负责从源端拉取变更写入目标表，你只要给服务B的业务账号分配目标表的只读权限，就能完全避免业务误写
• 可靠性足够：基于复制槽持久化消费位点，就算服务B对应的目标库停机数周，只要源端WAL日志未被清理，服务恢复后会自动从断点续传，不会丢失数据
• AWS RDS 完美支持：RDS for PostgreSQL 10及以上版本默认预置逻辑复制能力，仅需确认参数组中wal_level设为logical即可，不需要安装额外扩展
• 时延稳定在亚秒级，完全满足近实时要求，不存在定时批量同步的延迟问题

这个方案的配置成本极低，你只需要在源端建发布指定同步列，目标端提前建表结构、建订阅即可，初始全量同步和后续增量同步都会自动完成，不需要额外开发。

备选1：pglogical 扩展 #

如果你的RDS PostgreSQL版本低于10，或者后续需要更灵活的同步规则（比如行级过滤、多下游同步拓扑），可以选pglogical：

• 功能比原生逻辑复制更丰富，同样支持列过滤、持久化位点、亚秒级时延
• AWS RDS 官方支持该扩展，有成熟的配置流程
• 缺点是需要在源端和目标端都手动创建扩展，配置步骤比原生方案多，PG10+版本没有特殊需求没必要选。

备选2：AWS DMS 托管同步服务 #

如果你不想手动维护数据库层面的复制配置，可以选AWS托管的DMS服务：

• 全托管免运维，可视化配置源端、目标端、同步列规则即可
• 自带断点续传、异常重试能力，可靠性满足生产要求
• 时延通常在1秒以内，符合近实时要求
• 缺点是会产生额外的服务成本，适合没有DBA运维能力的团队选择。

不推荐SNS/SQS业务层同步方案的原因 #

这个方案本质是把数据一致性的保障逻辑全部下沉到业务代码，你需要额外处理：事务与消息发送的原子性问题、消息重复消费幂等、消息顺序保障、死信队列运维、消费端重试逻辑等一系列问题，开发和运维成本是逻辑复制方案的数倍，除非你需要在同步过程中加入复杂的业务字段加工逻辑，否则完全不建议选。

原生逻辑复制配置要点（RDS环境） #

• 确认源端RDS参数组中wal_level = logical，如果参数不对修改后重启实例生效
• 在源端（服务A所属数据库）创建发布，指定仅同步需要的列：

CREATE PUBLICATION account_sync_pub FOR TABLE SchemaA.account (id, deletedAt);

• 在目标端（服务B所属数据库）提前建表，主键必须和源端一致：

CREATE TABLE SchemaB.account (
  id bigint PRIMARY KEY,
  deletedAt timestamp with time zone
);

• 在目标端创建订阅，连接源端地址绑定发布即可，系统会自动完成全量初始化和后续增量同步：

CREATE SUBSCRIPTION account_sync_sub
CONNECTION 'host=源端RDS内网地址 port=5432 dbname=服务A数据库名 user=具备复制权限的账号 password=对应密码'
PUBLICATION account_sync_pub;

• 给服务B的业务账号仅分配SchemaB.account的SELECT权限，避免业务误写。
• 日常运维只需要监控源端复制槽的WAL堆积指标，配置阈值告警避免目标端长期停机导致源端WAL占满磁盘即可，RDS自带对应监控项，不需要额外开发。

内容的提问来源于stack exchange，提问作者bln_dev