面试题：PostgreSQL逻辑复制在复杂业务场景下的架构设计

Question

给定一个复杂业务场景，其中涉及多个数据源、不同类型数据（如结构化、半结构化数据）以及高并发读写操作，需要使用PostgreSQL逻辑复制构建数据同步架构。请描述你的整体设计思路，包括发布与订阅策略、数据一致性保证机制以及如何应对可能出现的故障。

Answer 1

整体设计思路

1. 数据源整合：
   • 针对不同数据源，使用ETL工具（如Kettle、DataX等）将数据抽取并转化为适合PostgreSQL存储的格式。对于半结构化数据，例如JSON格式数据，先进行预处理，将关键信息提取出来。
   • 将处理后的数据加载到PostgreSQL数据库中相应的表结构。
2. PostgreSQL逻辑复制配置：
   • 发布端：
     • 在发布端的PostgreSQL数据库中，创建发布（Publication）。确定需要发布的表，这些表应涵盖业务场景中涉及的关键数据。例如，如果业务涉及订单、用户等数据，就将订单表和用户表等相关表加入发布。
     • 配置发布参数，如发布模式（如ROW模式，更适合数据同步场景，能精确记录数据行的变化）。
   • 订阅端：
     • 在订阅端的PostgreSQL数据库中，创建订阅（Subscription），并关联到发布端的发布。
     • 配置订阅连接参数，确保订阅端能够与发布端建立稳定连接。

发布与订阅策略

1. 发布策略：
   • 表选择：选择与业务紧密相关的核心表进行发布，避免发布不必要的表导致数据冗余和同步性能下降。
   • 过滤条件：如果某些数据行不需要同步（例如测试数据或特定状态的数据），可以在发布时设置行级过滤条件。例如，只发布状态为“已完成”的订单数据。
2. 订阅策略：
   • 实时订阅：对于高并发读写操作场景，采用实时订阅策略，确保订阅端能够尽快获取发布端的数据变化。
   • 重试机制：当订阅过程中出现短暂连接中断或数据同步失败时，设置自动重试机制，避免因单次失败而导致数据同步长时间中断。

数据一致性保证机制

1. 事务一致性：
   • PostgreSQL逻辑复制基于事务进行，发布端的事务在提交后才会被复制到订阅端。这保证了数据在事务层面的一致性，即要么整个事务的所有更改都被同步，要么都不被同步。
2. 同步验证：
   • 在订阅端定期对同步的数据进行校验，例如计算数据的哈希值或校验和，并与发布端对应数据的哈希值进行比对。如果发现不一致，及时触发数据修复流程。
   • 对于关键业务数据，可以在发布端和订阅端分别维护版本号字段，每次数据更新时版本号递增。订阅端在同步数据时，验证版本号的连续性，确保没有数据丢失或重复同步。

应对可能出现的故障

1. 网络故障：
   • 检测与重连：订阅端持续监测与发布端的网络连接状态，一旦发现连接中断，立即尝试重新连接。可以设置一定的重连间隔时间和最大重连次数。
   • 数据缓存：在订阅端设置本地缓存，当网络故障导致数据同步暂停时，将接收到但未处理完的数据暂存于缓存中。待网络恢复后，从缓存中继续处理数据，确保数据不丢失。
2. 数据库故障：
   • 备份与恢复：发布端和订阅端都定期进行数据库备份，采用全量备份和增量备份相结合的方式。当数据库出现故障时，能够快速恢复到故障前的某个时间点。
   • 故障转移：对于关键的PostgreSQL数据库节点，可以采用主从复制或多节点集群（如Patroni + etcd等方案）实现故障转移。当主节点出现故障时，从节点能够迅速接管工作，确保数据同步服务不中断。