背景

随着业务的发展，对于实时报表、数据实时搜索、集群同步的需求越来越旺盛，例如多业务的订单搜索、实时统计等。从PostgreSQL实时同步的开源方案主要有bottledwater-pg、Postgres_fdw等，开源的方案中基本处于缺乏维护状态，支持的功能也比较弱，为此哈啰实现了一套基于PostgreSQL逻辑复制槽的实时同步平台Tunnel。

架构设计

PG数据同步的实现原理

replication slots 是从PostgreSQL 9.4开始引入的，引入后我们可以基于复制槽实现更多的迁移同步需求。replication slots保存了逻辑或物理流复制的基础信息。类似MySQL的位点信息。一个逻辑slot创建后，它的相关信息可以通过pg_replication_slots系统视图获取。如果slot为active状态，则可以通过系统视图pg_stat_replication看到slot的实时的状态信息。PostgreSQL的逻辑日志来源于解析WAL日志。

解析WAL成为逻辑数据的过程叫Logical Decoding。Logical Decoding是把WAL日志解析成逻辑日志的过程。这个过程输出的数据格式可以描述为：

1、事务开始任何的变化总是在一个事务中，所以订阅的数据变化的开始是一个事务被启动的消息，他包括了事务ID、LSN、开始时间等信息。

2、数据的变化包括当前事务中修改的数据。即对某些表的insert/update/delete操作来带的数据变化。

  • 一个事务内可以包含任意个表和任意行数据的变化。
  • 输出的数据的格式和对应表的定义和REPLICA IDENTITY相关。

3、事务的提交包括事务提交的 LSN、时间等相关信息。

逻辑流复制利用索引的方式优化传输数据的效率，它们可以按表为单位定制。大致分为三种情况:

A）如果修改的表有primary key, 则表的变化的逻辑数据只会包括该表变化的列和pk列数据，如果pk列被修改，则还会输出老的pk列数据

B）如果修改的表没有primary key，则可以使用alter table指定一个REPLICA index，同时需要这个索引列为非空，其产生的效果和1相同。

C）如果修改的表不满足上面的两个条件，而又要做同步，可以使用alter table设置这个表的REPLICA IDENTITY为FULL。于是系统在表修改时会记录修改行的所有列，不会做任何的优化。

同步任务的自动下发

同步任务进行申请配置后，任务下发到同步节点整体依赖zookeeper来实现，基于zookeeper的通知机制实现配置的变化监听，从管理节点获取到同步任务信息，执行相应的同步。为了平衡同步节点，通过监控计算同步节点最近有效的同步tps，然后按照贪心算法选择tps最小的任务节点进行下发。

同步数据的一致性

保证同步数据不丢失主要依赖以下两个方案：

  • 通过复制槽的confirmed_flush_lsn进行消费数据成功的确认，confirmed_flush_lsn是逻辑插槽的consumer已确认接收数据的地址(LSN)，超过此时间的数据将不再可用。

  • 数据发送至kafka，发送成功后flush lsn，通过自动创建消费kafka的任务同步至其他数据源，如ES、Hbase、Hive等，保证同步服务的性能与可靠性。

同步配置规则

  1. 利用正则表达式对表名进行匹配，满足分库分表或一定规则的通用配置
  2. 只匹配需要的字段，对于敏感字段进行过滤
  3. 指定并匹配主键

开源版本地址

https://github.com/hellobike/tunnel

总结与展望

做为数据实时同步的基础，同步平台Tunnel已覆盖使用各业务线同步数据的使用场景，实现数据的实时、准确、高效的同步。在后面的计划中将实现数据的更加可靠的有序性，跨机房数据的同步等功能，从而更加稳定的支持业务的发展。