巧用 TiCDC Syncpiont 构建银行及时交易和准及时计算一体化架构
本文阐述了某商业银行如何利用 TiCDC Syncpoint 功能，在 TiDB 平台上构建一个既能处置惩罚及时交易又能举行准及时计算的一体化架构，用以优化其零售资格业务体系的实践。通过迁徙到 TiDB 并奇妙应用 Syncpoint，该银行乐成办理了原有多个 MySQL 集群所面临的数据分布复杂性和跨库关联查询的挑战，实现了数据处置惩罚效率和应用性能的显著提升，确保了及时交易的快速相应和数据分析处置惩罚的计算资源需求。场景概述
某商业银行的零售资格业务体系专门设计用于计算和管理客户的消费积分及优惠。每当用户完成一笔交易，体系内的关键模块便会主动整合用户的历史消费数据，敏捷举行积分计算，并将当前可用的优惠信息及时推送给用户，例如通知当前能够兑换的优惠或赠品，提示额外消费达到一定额度后能够获得的特定嘉奖等。该体系旨在通过提供及时的优惠信息和激励措施，增强客户的消费体验。
用户的消费信息按照用户 ID 举行分组，存储在 30 多个 MySQL 集群。随着业务的增长，以及必要开放第三方应用利用数据，完成资格的计算。分库分表的 MySQL 就不满足业务需求了。一方面，分库分表后数据分布复杂；别的，分库分表难以实现跨 MySQL 库的关联查询。 如果把这些 MySQL 库的数据汇聚到 HBase 等大数据平台，即不能保障用户交易以事务的粒度同步到大数据平台，也很难保证数据的时效性（大数据通常都只做 T+1 的计算）。
为了优化应用性能和数据处置惩罚效率，行方决定将应用迁徙到 TiDB 平台，并采取策略将及时交易和准及时计算分配到两个差别的 TiDB 数据库集群中。资格落地模块用来完成准及时资格的计算。因为落地数据计算量大，而且有准及时性的要求，为了不影响及时业务，落地计算是通过 TiDB 备集群 2 举行计算，该集群的数据来自 TiCDC 从及时集群同步过来的准及时数据。
如许的架构设计旨在均衡交易的即时性和数据处置惩罚的计算需求，确保及时交易的快速相应，同时为数据分析和处置惩罚提供充足的计算资源。
TiCDC 和 Syncpoint 特性简介
本文以商业银行零售资格业务体系为例，向大家介绍怎样通过 TiCDC 的 Syncpiont 功能，来确定目标端的同步进度，而且以此为依据，计算每笔业务对用户资格数据的贡献。
https://i-blog.csdnimg.cn/blog_migrate/aa4b4fa9c89676b56a110aa6e2f6ec07.png
图 1：及时交易和准及时计算一体化架构
“TiDB 主集群”为及时集群；“TiDB 备集群 2”是专门为资格落地准备的准及时集群；“TiDB 备集群 1”是容灾集群
众所周知，在业界，几乎所有的变动数据捕获（CDC）产品都通过异步方式举行数据同步，这导致主集群与备集群之间不可避免地会出现数据延迟。TiCDC 采用分布式架构设计，也会受到主备之间延迟的影响，不能保证目标端的事务提交序次和源端的事务提交序次完全一致，无法动态地获取主备集群的一致性关系。
行方原先考虑在源端提交以后，等待一分钟左右时间，再去备集群计算，但是，如果碰到大的事务，大概集群因为某些缘故原由提交缓慢，即使等待 N 分钟，也不能保证备集群能完成同步。
https://i-blog.csdnimg.cn/blog_migrate/c4ffac53757770df98edc473d9e35332.png
图 2：TiCDC 分布式同步架构
在利用 TiCDC 构建 TiDB 主从集群的过程中，有时必要在不绝止数据同步的情况下，举行数据的一致性快照读取或验证。由于 TiCDC 采用的是分布式架构，其尺度同步模式仅确保数据的最终一致性，而不能保证在同步过程中的数据一致性。这就使得对及时变化的数据举行一致性读取变得具有挑战性。为了办理这个问题，TiCDC 引入了 Syncpoint 功能，它答应用户在特定时间点获取数据的一致性视图，从而举行一致性读取和数据验证，满足了对数据一致性有严酷要求的业务场景。
Syncpoint 通过利用 TiDB 提供的 snapshot 特性，让 TiCDC 在同步过程中维护了一个上下游具有一致性 snapshot 的 ts-map。把校验动态数据的一致性问题转化为了校验静态 snapshot 数据的一致性问题，达到了接近数据一致性及时校验的效果。当启用 Syncpoint 功能后，就可以利用一致性快照读和数据一致性校验。
巧用 Syncpoint
要开启 Syncpoint 功能，只需在创建同步任务时把 TiCDC 的配置项 enable-sync-point 设置为 true。开启 Syncpoint 功能后，TiCDC 会向下游 TiDB 集群写入如下信息：
在数据的同步过程中，TiCDC 会定期（利用 sync-point-interval 参数配置）对齐上下游的快照，并将上下游的 TSO 的对应关系保存在下游的 tidb_cdc.syncpoint_v1 表中。
同步过程中，TiCDC 还会定期（利用 sync-point-interval 参数配置）通过执行 SET GLOBAL tidb_external_ts = @@tidb_current_ts ，在备用集群中设置已复制完成的一致性快照点。
Syncpoint 表结构如下：
select * from tidb_cdc.syncpoint_v1;
+------------------+-------------+--------------------+--------------------+--------------------+
| ticdc_cluster_id |changefeed | primary_ts | secondary_ts | created_at |
+------------------+-------------+--------------------+--------------------+--------------------+
|default | test-2 | 435953225454059520 | 435953235516456963 | 2022-09-1308:40:15 |
+------------------+-------------+--------------------+--------------------+--------------------+ ticdc_cluster_id：插入该条记录的 TiCDC 集群的 ID。
changefeed：插入该条记录的 Changefeed 的 ID。通过 ticdc_cluster_id 和 Changefeed 的 ID 来确 认一个 Changefeed 所插入的 ts-map。
primary_ts：上游数据库 snapshot 的时间戳。
secondary_ts：下游数据库 snapshot 的时间戳。
created_at：插入该条记录的时间。
通过查询 ts-map 的方式选取之前的时间点举行快照读。syncpoint_v1 中的 primary_ts，就代表备集群，当前已经完成的事务，对应到主集群的时间戳。
资格应用在及时集群完成一笔业务后，只必要记下业务完成时的时间戳，然后在备集群中去查询 tidb_cdc.syncpoint_v1 中 max(primary_ts)，如果获取到的 primary_ts 大于其时业务记录的完成时间戳，就代表该业务已经在备集群完成，应用就可以针对该笔业务，计算用户当前的资格。
因为资格下游集成了许多子体系，而且 syncpoint_v1 是按照一定的时间间隔更新的，所以没有必要每笔交易、下游子体系都查询一次 tidb_cdc.syncpoint_v1，如许会对数据库造成性能影响，所以根据业务需求，资格体系将以一定时间间隔读取 tidb_cdc.syncpoint_v1，缓存 primary_ts，通过缓存提供给下游业务利用。详细流程如下图所示：
https://i-blog.csdnimg.cn/blog_migrate/f104d625580894f4f694a94c011b670b.png
图 3：启用 Syncpoint 后的资格落地计算流程
通过以上的流程 ，资格下游的应用就可以准确的得到每笔业务产生的资格更新。Syncpoint 的启用步骤如下：
[*]编辑 changefeed.toml，增加如下内容
# 开启 SyncPoint
enable-sync-point = true
# 每隔 30s对齐一次上下游的 snapshot
sync-point-interval = "30s"
# 每隔 1 小时清理一次下游 tidb_cdc.syncpoint_v1 表中的 ts-map 数据
sync-point-retention = "1h"
[*]动态启用配置文件
TiCDC 支持非动态修改同步任务配置，修改 changefeed 配置必要按照 ：暂停任务 -> 修改配置 -> 规复任务的流程
cdc cli changefeed pause -c test-cf --server=http://10.0.10.25:8300
cdc cli changefeed update -c test-cf --server=http://10.0.10.25:8300 --sink-uri="mysql://127.0.0.1:3306/?max-txn-row=20&worker-number=8" --config=changefeed.toml
cdc cli changefeed resume -c test-cf --server=http://10.0.10.25:8300
[*]获取 ts-map
在下游 TiDB 中执行以下 SQL 语句，从结果中可以获取上游 TSO (primary_ts) 和下游 TSO (secondary_ts) 信息。
select*from tidb_cdc.syncpoint_v1limit 1;
+------------------+------------+--------------------+--------------------+--------------------+
| ticdc_cluster_id | changefeed | primary_ts | secondary_ts | created_at |
+------------------+------------+--------------------+--------------------+--------------------+
| default | test-2 | 435953225454059520 | 435953235516456963 | 2022-09-1308:40:15 |
+------------------+------------+--------------------+--------------------+--------------------+ 获取当前最后一个一致性的时间戳。
select max(primary_ts) fromtidb_cdc.syncpoint_v1 注意事项
同个数据库的多张表，可以通过差别的 changefeed 来举行同步，如许可以分摊一些 workload，但是由于 syncpoint 一致性是以 changefeed 为最小粒度的，所以要求，有事务关联性的所 有表， 必须在同一个 changefeed 里面同步 。如果涉及多个 changefeed 的情况下 ，取 primary_ts 要带上 changefeed 字段，如果 TiCDC 还涉及多个 TiDB Cluster 同步数据，那还应该带上 ticdc_cluster_id，如：
select max(primary_ts ) from tidb_cdc.syncpoint_v1 where changefeed=’test-2’
select max(primary_ts ) from tidb_cdc.syncpoint_v1 where changefeed=‘test-2’and ticdc_cluster_id=‘default’ 关于 TiCDC 利用的优化点：
[*]起首，应用端应该尽量避免利用大事务，TiCDC 只有在源端事务已经提交后，才会在目标端开始执行事务（源端 pre-write 阶段，数据会缓存在 TiCDC，并不会在目标端也 pre-write，只有等到源端提交后，目标端才开始执行），所以如果源端的事务执行时间比较久，目标端并不一定会比源端执行时间短。
[*]因为是分布式体系，可以通过增加 changefeed 的 worker 的数目，来加快下游同步的速度，详细必要根据业务的现实情况来设定，worker-num 默以为 16。
关于利用 syncpoint 取到的数据，最大延时计算参考：
tidb_cdc.syncpoint_v1 表中的数据，革新间隔是按照 sync-point-interval 设置的时间间隔革新的，所以从该表中获取的最新快照的时间，最大的延时近似于 sync-point-interval+现实延时。
总结
在必要对 TiCDC 上下游动态变动的数据执行一致性读取的应用场景中，启用 Syncpoint 功能是一种有用的办理方案。通过查询下游 tidb_cdc.syncpoint_v1 表中的 primary_ts 字段，用户能够获取到下游事务的确切完成时间点。这一机制显著提升了计算的准及时性，确保了数据读取的时效性，为用户提供了可靠的准及时数据处置惩罚方案。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]