CN116383308A - 一种具备全链路反压特性的数据同步方法及系统 - Google Patents
一种具备全链路反压特性的数据同步方法及系统 Download PDFInfo
- Publication number
- CN116383308A CN116383308A CN202310379681.6A CN202310379681A CN116383308A CN 116383308 A CN116383308 A CN 116383308A CN 202310379681 A CN202310379681 A CN 202310379681A CN 116383308 A CN116383308 A CN 116383308A
- Authority
- CN
- China
- Prior art keywords
- data
- synchronization
- actor
- sql
- full
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 230000001360 synchronised effect Effects 0.000 claims abstract description 23
- 238000006243 chemical reaction Methods 0.000 claims abstract description 22
- 230000007246 mechanism Effects 0.000 claims abstract description 20
- 230000004044 response Effects 0.000 claims abstract description 18
- 238000012545 processing Methods 0.000 claims abstract description 17
- 230000002688 persistence Effects 0.000 claims abstract description 8
- 238000004364 calculation method Methods 0.000 claims description 15
- 239000012634 fragment Substances 0.000 claims description 12
- 238000012217 deletion Methods 0.000 claims description 10
- 230000037430 deletion Effects 0.000 claims description 10
- 238000007726 management method Methods 0.000 claims description 7
- 238000012790 confirmation Methods 0.000 claims description 5
- 238000004458 analytical method Methods 0.000 claims description 4
- 230000011218 segmentation Effects 0.000 claims description 4
- 238000007689 inspection Methods 0.000 claims description 3
- 230000002085 persistent effect Effects 0.000 claims description 3
- 230000007704 transition Effects 0.000 claims description 2
- 238000012550 audit Methods 0.000 claims 1
- 238000002161 passivation Methods 0.000 description 5
- 230000002776 aggregation Effects 0.000 description 4
- 238000004220 aggregation Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 3
- 238000013499 data model Methods 0.000 description 3
- 230000008439 repair process Effects 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 238000011144 upstream manufacturing Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/219—Managing data history or versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computational Linguistics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种具备全链路反压特性的数据同步方法及系统，包括：配置同步任务的元数据；启动binlog日志的增量同步，选择性进行全量同步；将产生的增删改查事件路由到分布式的并行Stream管道；并以异步请求响应模式按各表配置的维度字段路由分发到Actor模型分片集群中的Actor实体；进行事件持久化和状态更新，以及基于当前状态的复杂转换逻辑，并将结果返回Stream管道；Stream管道对Response事件进行消息批化和排序去重处理；将结果写入Sink数据源，并进行异步ACK机制，保证可靠同步。本发明通过高度可配置的同步任务，可快速实现异构数据源间的复杂模型同步转换，具有链路短、组件少，同步高效的特点。
Description
技术领域
本发明涉及通信技术领域，具体涉及一种具备全链路反压(Backpressure)特性的数据同步方法及系统。
背景技术
互联网信息时代，业务场景和需求复杂多变，单一数据库已经无法满足业务要求，数据库呈现出了SQL和NoSQL两大阵营百花齐放的现状，而随之而来的是不同存储系统之间数据流转同步的问题，因为数据同步存在以下复杂性：
异构数据源的同步比同构数据源的同步更复杂。同构数据源的同步，由于设计理念和模型都相同，比较简单。但异构数据源之间的最优数据模型存在巨大差异，例如关系型数据库Mysql，遵循范式设计会产生大量业务表；而搜索引擎Elasticsearch或Apache Solr擅长大宽表或嵌套json的全文检索，并不擅长海量数据的多表join。
数据同步一致性的保证。保证绝对不出错是很难的，不可避免地有修数据的需求，如何以非阻塞的方式(不影响增量同步)同步存量数据和细粒度修复业务数据，是比较复杂的。
数据同步系统中，同步任务的同步管道具有突出的单点问题，实现主备同步管道及故障自动切换，复杂度高。如何在高吞吐、低延迟的前提下保证同步系统的稳定运行？
发明内容
本发明提供一种具备全链路反压(Backpressure)特性的数据同步方法及系统，用于解决数据同步过程，异构数据源最优模型差异大、数据一致性难保证、数据同步稳定性差且效率低下的问题，实现了准实时自动同步数据，保证了数据的完整性和准确性。
一种具备全链路反压(Backpressure)特性的数据同步方法，其特征在于，包括以下步骤：
S1.配置同步任务的元数据，元数据包括：Source数据源和Sink数据源的连接配置、日志解析的库表、Actor模型分片集群的计算转换逻辑；
S2.利用步骤S1的元数据启动同步任务，进行基于数据库binlog日志的增量同步，同步后产生增删改事件，进行基于SQL模式的全量同步，同步后产生查事件；
S3.将S2步骤产生的增删改查事件路由到分布式的并行Stream管道；
S4.并行Stream管道将增删改查事件以异步请求响应模式按各表配置的维度字段路由分发到Actor模型分片集群的Actor实体中；
S5.在Actor模型分片集群的Actor实体中，根据增删改查事件的先后顺序进行事件持久化和状态更新，以及基于当前状态的复杂转换逻辑，并将结果返回Stream管道；
S6.Stream管道对Response事件进行消息批化(Batch Message)和排序去重处理；
S7.将S6步骤的结果写入Sink数据源(如Elasticsearch、RabbitMQ、Kafka等)，并进行Source数据源和Sink数据源的端到端异步ACK机制，如果确认成功，就完成数据的可靠同步。
步骤S2中，基于SQL模式实现的全量同步，具体包括：
S2.1.API提交的全量同步任务包括多表关联拉取任务和多表独立拉取任务；
S2.2.步骤S2.1中如果是多表关联拉取任务，提交的接口数据会有1个主表和多个辅助表，对主表构建SQL，进行分片逻辑得到分片SQL，对主表的分片SQL进行并行受控拉取，由主表记录驱动反查辅助表，将查询得到的数据进行格式转换，保持和增量同步的数据格式一致，对主表和辅助表的数据进行消息批化处理(目的是为了尽可能减少S5步骤中的分片Actor实体状态在磁盘和内存之间的频繁切换，这样N条消息在Actor模型分片集群中Actor实体中只需要1次状态计算)，得到最终数据；
S2.3.步骤S2.1中如果是多表独立拉取任务，则构建表SQL，均匀分发到各节点，对表SQL进行分片逻辑得到分片SQL，对分片SQL进行并行受控拉取，将拉取到的数据进行格式转换，保持和增量同步的数据格式一致，得到最终数据；
S2.4.将步骤S2.2的最终数据或S2.3得到的最终数据作为查事件。
步骤S2中，数据库binlog日志的增量同步产生的增删改事件都包含uid和ts属性。ts为数据库binlog日志中日志的产生时间(毫秒时间戳)，而uid是由binlog日志文件名后缀中递增的数字(加上一个可配置的补偿参数，默认为0，用以解决数据库日志重置场景)以及binlog日志中的字节偏移offset组合出的一个Long类型值，该值是递增的，且能够唯一标示出数据库表中任何一行记录的CURD操作。当触发全量同步任务时，增量同步周期性记录的最新uid、ts会作为该批次全量同步的所有查事件的uid、ts值，基于uid、ts可准确判断出增删改查事件的先后顺序。
步骤S5中，基于当前状态的复杂转换逻辑包括：
S5.1.Actor模型分片集群中的Actor实体中的当前状态由经步骤S4中维度字段逻辑切分得到的多张子表构成；
S5.2.对当前状态中的1或2张子表的操作(operation)，封装成灵活的SQL方式，经过SQL计算处理后得到临时的中间表，可作为下一个操作的输入表；
S5.3.表级pipeline机制可组合多个operation得到任意复杂的转换逻辑。一个pipeline由至少一个operation组成，无依赖关系的operation间可并发执行，以加速计算速度。
步骤S7中，所述Source数据源到Sink数据源的端到端异步ACK机制，可以严格保证至少一次的消息传递语义。具体包括：
步骤S2中增量同步或全量同步产生的增删改查事件，都具有消息确认的地址ActorRef和唯一的AckId属性。当步骤S7中，数据成功写入Sink数据源后，会根据ActorRef和AckId进行Source数据源到Sink数据源的端到端异步ACK处理。如果确认失败(ACK消息丢失或超时)，增量同步会快速重启并重置到最近成功ACK过的位点，继续恢复同步；而全量同步会继续同步，保留未确认的消息待全量同步结束后进行重试。
本发明还提供了一种具备全链路反压特性的数据同步系统，其特征在于，包括：
用于配置和持久化任务元数据的任务元数据模块；
对存量数据进行高效并行同步的全量数据同步模块；
对主流关系型数据库(MySQL、PostgreSQL、TiDB、PolarDB、Oracle等)的binlog日志进行抽取和解析的增量数据同步模块；
支持最终结果持久化(支持Elasticsearch、Kafka、RabbitMQ、MySQL等)的数据Sink模块；
对海量Actor实体进行分布式管理，Actor计算逻辑可配置化的分片Actor集群管理模块；
用于管理同步并行度的动态并行度管理模块；
用于保证数据的完整性和准确性的定时数据巡检模块。
与现有技术相比，本发明具有以下有益效果：
一、受益于步骤S2中的增删改查事件都包含用于判断事件先后顺序的uid和ts属性，使得下游事件的流转和处理不需要保证严格有序，但仍能保证同步数据的最终一致性。这样同步链路不仅可以以非阻塞binlog增量同步的方式进行全量同步，而且还能充分进行事件的异步并发处理，以及动态调整并行Stream管道的并行度。
二、受益于步骤S4和步骤S5中使用的Actor模型分片集群，利用Actor模型的无锁并发特性，很容易进行海量数据的计算处理，利用Actor的钝化(Passivate)机制可以实现数据的冷热分离及内存的高效利用。
三、步骤S5中基于当前状态的复杂转换逻辑是可配置的(持久化在任务元数据中)，通过表级pipeline机制和可定制SQL操作完成多表间的复杂聚合转换，可以实现异构数据源间的不同数据模型转换(如关系数据库同步到搜索引擎)。
四、步骤S7中Source数据源到Sink数据源的端到端异步ACK机制，进一步保证了至少一次消息传递语义和数据的最终一致性。
五、本发明的同步方法完全与业务代码解耦(只依赖于业务数据库)，受益于遵循ReactiveStream标准的同步管道(如AkkaStream)实现，步骤S2～S7具有全链路反压特性，具有同步链路短，涉及组件少，资源利用率高，不高度依赖于消息中间件的优点。
附图说明
图1为本发明同步方法的流程图；
图2为本发明同步方法步骤S2中所述基于SQL模式全量同步的流程图；
图3为本发明实现的单个同步任务运行态的示意图；
图4为单个无状态同步任务(无需跨多表聚合转换)运行态的示意图。
具体实施方式
实施过程，消息中间件不是必选项，同步链路无需使用消息中间件来缓冲数据。这主要得益于从Source到Sink的整个同步链路的实现都完全遵循ReactiveStream响应流标准规范，下游向上游发送需求信号，上游按需求信号向下游发送数据，上下游的生产与消费之间存在着动态协调机制，能有效利用内存资源实现数据的稳定同步及反压(Backpressure)传递。
如图1、图2所示，一种具备全链路反压特性的数据同步方法，包括以下步骤：
S1.配置同步任务的元数据，元数据包括：Source和Sink数据源的连接配置、日志解析的库表、Actor模型分片集群的计算转换逻辑；
任务元数据的持久化可以采用etcd组件来存储，一个同步任务的元数据由一组key-value的数据构成，value存储的是JSON或HOCON格式数据，举个示例，对于S1步骤同步任务的元数据，对应的key-value格式为：
同理，对同步的库表的配置对应etcd中的key为<task_id>/table_source，数据sink端对应的配置为<task_id>/table_sink，对应转换逻辑配置存储在<task_id>/pipeline_sql，分片Actor集群状态后端配置的元数据存储在<task_id>/complextable_event_source，等等，这里尽可能将一个同步任务的元数据拆分成一组KV，是为了避免单个KV中V存储的数据过大影响读写效率问题。至于V中JSON或HOCON内容，完全由同步系统的业务需求灵活定义。
S2.利用步骤S1的元数据启动同步任务，进行基于数据库binlog日志的增量同步和基于SQL模式实现的全量同步；
基于binlog日志的增量同步，采用自定义Source的方式(遵循ReactiveStream标准的反压流实现提供了支持，如Akka Stream、Project Reactor)，可以整合目前成熟的开源组件(Canal、Debezium、Maxwell、TiCDC)扩展出Canal Source、Debezium Source、Maxwell Source、TiCDC Source等。这些自定义Source组件需要可靠存储binlog日志的消费偏移offset，可选的组件有Etcd、Zookeeper，或直接保存在源头DB中，除此之外，步骤S7中进行的Source端到Sink端的异步ACK机制需要自定义Source配合，只有在自定义Source中之前所有位点都异步ACK过，才能提交该日志的消费偏移offset，否则说明可能丢消息或ACK确认超时了，需要重置消费位点(或重启图3中名称为Binlog Parser ShardActor的Actor模型分片集群中对应的Actor)，让可能丢失的消息重新发往下游，保证至少一次的消息传递语义。这些自定义的Source由无状态的Actor模型分片集群(如图3中BinlogParserShard Actor)中的Actor实体进行一对一的托管，利用分片Actor集群的特点可以让自定义Source均匀分布在集群节点中，并行进行数据库日志的解析与订阅，还能让自定义的Source通过Actor的restart机制具有容错恢复能力。
基于SQL模式的全量同步，可以利用SQL的特点适配大部分主流关系型数据库。全量同步的主要流程，见图2，具体包括：
S2.1.根据API提交的全量同步任务可以区分是多表独立拉取还是多表关联拉取；
S2.2.步骤S2.1中如果是多表关联拉取任务，提交的接口数据会有1个主表和多个辅助表。对主表构建SQL，进行分片逻辑得到分片SQL，对主表的分片SQL进行并行受控拉取，由主表记录驱动反查辅助表，将查询得到的数据进行格式转换，保持和增量同步的数据格式一致，对主表和辅助表的最终数据进行N:1的消息批化处理(目的是为了尽可能减少S5步骤中的分片Actor实体状态在磁盘和内存之间的频繁切换，这样N条消息在Actor中只需要1次状态计算)；
S2.3.步骤S2.1中如果是多表独立拉取任务，则构建表SQL，均匀分发到各节点，对表SQL进行分片逻辑得到分片SQL，对分片SQL进行并行受控拉取，将拉取到的数据进行格式转换，保持和增量同步的数据格式一致；
步骤S2.2和S2.3对表进行分片的处理思路都是进行针对索引列的切分，构造出数据量合理的分片表的SQL，该过程如果用户明确配置了切分列，则按其进行切分，如果用户没有配置切分列，则能够自动识别出表中合适的索引列及其列类型，采用合适的切分逻辑进行处理并得到分片SQL，后续就可以利用遵循ReactiveStream标准的反压子流来实现对分片SQL的并行受控拉取数据，为了保证分片SQL在数据源正常执行，需要充分利用目前主流关系型数据库都有的游标查询特性，避免客户端内存溢出问题。
对于海量存量数据的同步，步骤S2.2和S2.3存在耗时久且局部失败中断的问题。为了快速恢复继续剩余未完成分片的同步，需要全量同步具备分片粒度的checkpoint机制。Checkpoint机制会对切分出的各分片的同步情况维护状态并定期更新，该状态中主要需要记录任务提交时间和结束时间、该任务对应的uid和ts信息、表的总分片数、表的总记录数、已成功同步的记录数、未确认ACK的记录集合(元素为具有唯一标识性的ackId)、切分出的分片列表(分片元数据主要包括分片SQL、分片是否同步完成)。
S2.4.将步骤S2.2或S2.3得到的数据与增量同步得到的数据一起汇聚到并行Stream管道。
全量数据同步与增量数据同步是共用并行的Stream管道，二者可以同时进行，数据的最终一致性保证并不由消息事件的绝对顺序传递来保证，而是由消息事件自身的uid、ts字段来保证(通过这两个字段可以严格判断出消息的先后)。ts为毫秒时间戳，表示数据库binlog日志中日志的产生时间，而uid是由binlog日志文件名后缀中递增的数字(加上一个可配置的补偿参数，默认为0，用以解决数据库日志重置场景)以及binlog日志中的偏移offset组合出的一个Long类型值，该值能够唯一标示出数据库表中任何一行记录的CURD操作，且保证是递增的。增量同步过程会周期性提交记录最近异步端到端ACK确认过的uid、ts位点信息，当触发全量同步任务时，记录的增量最新uid、ts会作为该批次同步的所有存量数据的uid、ts值。
基于uid、ts来判断消息的先后顺序，在反压流中就可以充分进行异步并行并发，只在反压流与ComplexTableShard Actor分片集群之间进行异步Request/Response时，根据uid、ts字段判断是否需要更新ComplexTableShard Actor分片集群中的Actor状态，Actor状态会维护一个微型数据库(一个业务实体涉及到的多张表数据)，同时状态中还包含一个version字段，利用Actor模型的串行特性，只要Actor状态有变化时，该version字段就累加1，这样从ComplexTableShard Actor分片集群返回给并行Stream管道的Response就可以根据这个version值来判断消息的先后顺序，最终Sink端根据这个version值来进行乐观锁控制，在并发写入的同时保证落库的最终一致性。
S3.将S2步骤产生的增删改查(CURD)事件路由到分布式的并行Stream管道；
基于事件的uid、ts属性，并不需要严格保证消息在Stream管道中的顺序。因此对于事件的路由既可以采用轮询(Round Robin)的路由策略，也可以采用最快消费端的路由策略。
并行Stream管道由无状态的Actor模型分片集群(如图3中DynamicParallismShard Actor)中的Actor实体进行一对一托管，这样可以充分利用分片Actor的分片自动均衡、Actor容错机制等重要特性来实现同步任务的动态并行度管理。
S4.并行Stream管道将CURD事件以异步Request/Response模式按各表配置的维度字段路由分发到抽象出的分片Actor实体中；
S5.Actor模型分片集群中的分片Actor实体中进行事件持久化和状态更新，以及基于历史状态的复杂转换逻辑，并将结果返回Stream管道；
步骤S4的Actor模型分片集群中的分片Actor实体，基于Request的事件的uid、ts和Actor状态中维护的历史数据的uid’、ts’来判断事件的先后顺序，如果事件乱序，就忽略Request的事件返回一个空响应，反之则持久化事件，更新Actor状态，基于更新后的当前状态进行异步计算返回Response响应，Response响应中包含一个version字段(version由Actor模型维护，严格保证单调递增)，也可以用于下游判断Response响应的先后顺序。
步骤S4和S5中的Actor模型分片集群中的分片Actor实体，指的是如图3中的ComplexTableShard Actor分片集群(可基于Akka或orleans开源框架实现)。状态的切分，原则上按业务实体的粒度(如电子签约场景，每份合同相关的所有表可以放在一个Actor)去切分和托管状态，目的是充分发挥Actor模型的无锁并发，进行海量状态计算。通过有状态的Actor作为状态容器(需要Actor状态存储后端支持，如Cassandra、EventStore、MySQL等)，可以实现异构数据源的最优数据模型转换。托管的状态优先放在内存里，可以加速计算。为了高效利用内存，需要按业务场景配置合理的钝化(将状态持久化到外部组件，释放内存)策略，如基于时间维度的钝化策略和自定义业务维度的钝化策略(如电子签约场景，合同完成时可以主动钝化)，或二者的组合。
ComplexTableShard Actor分片集群中的Actor状态聚合逻辑这块是业务强相关的，为了提升同步系统的泛化能力，需要将这部分聚合计算逻辑抽象成可配置化的。ComplexTableShard Actor分片集群中Actor包含同步进来的一个业务实体的多张原始表数据，可以当作一个微型数据库，利用Apache Calicite开源组件，可以抽象出pipeline机制和可定制SQL能力，能够实现对Actor中的状态进行灵活地聚合转换。pipeline机制由至少一个Operation级联构成，每个Operation输入为1或2张表，输出为1张新表，每个Operation的具体操作，使用可定制SQL来描述，进一步组合pipeline就可以配置出复杂的转换逻辑。
当然，引入如图3中的ComplexTableShard Actor分片集群作为状态容器是有代价成本的。对于只涉及表内数据转换(如字段类型转换，字段重命名等等，不涉及复杂的跨多表聚合转换)的简单同步任务，完全不需要引入复杂的ComplexTableShardActor分片集群，如图4所示，这样的好处是同步任务轻量高效，同步的瓶颈主要取决于数据Sink端组件的性能和Stream管道的并行度。
S6.Stream管道对Response事件进行消息批化(Batch Message)和排序去重处理；
批化消息(Batch Message)和排序去重处理的根本目的是为了优化写入性能，提升吞吐量。尤其在业务高并发场景，业务数据库中表内同一行记录可能在短时间内频繁修改，密集产生Row模式的binlog日志，下游就会产生大量Response冗余事件，只要写入具有同一唯一标识的最新Response事件(其他旧Response事件完全可以忽略)，仍能保证数据的最终一致性。
S7.将S6步骤的结果写入Sink数据源(如Elasticsearch、RabbitMQ、Kafka等)，并进行Source端到Sink端的异步ACK机制。
进行Source端到Sink端的异步ACK机制是为了保证至少一次的消息传递语义。事件在Source端到Sink端的流转过程，都具有消息确认的地址ActorRef和唯一的AckId属性。当数据成功写入Sink数据源后，会根据ActorRef和AckId进行Source端到Sink端的异步ACK处理。如果确认失败(ACK消息丢失或超时)，增量同步会快速重启并重置位点继续恢复同步，而全量同步会继续同步，保留未确认的消息待全量同步结束后进行重试。
对于上游业务产生的物理删除或逻辑删除事件，在Sink端都以逻辑删除(软删除)来处理，这样的好处是通过乐观锁机制，利用version字段来写入或忽略消息，不需要消息写入的绝对顺序保证，可以充分进行并发写入。既能保证数据最终一致性，也能在写入的数据源中查询之前的删除历史。
为了进一步保证数据的完整性和准确性，所述同步方法和系统还包含独立的定时数据巡检比对任务，能实现在系统负载低峰时主动发现不一致的数据。数据巡检定时任务，数据源端数据的拉取可以充分复用全量数据同步的实现，通过查询同步任务的元数据，基于同步链路各阶段(主要为3个阶段：Source端、ComplexTableShard Actor端、Sink端)的状态，进行数据比对校验，当比对不一致时，记录不一致的细节，方便后续查询结果和排查不一致的原因。出错的数据量少时可以自动进行修复，数据量大时，可以记录相应状态，由人工介入处理。
Claims (6)
1.一种具备全链路反压特性的数据同步方法，其特征在于，包括以下步骤：
S1.配置同步任务的元数据，元数据包括：Source数据源和Sink数据源的连接配置、日志解析的库表、Actor模型分片集群的计算转换逻辑；
S2.利用步骤S1的元数据启动同步任务，进行基于数据库binlog日志的增量同步，同步后产生增删改事件，进行基于SQL模式全量同步，同步后产生查事件，由增删改事件和查事件组成增删改查事件；
S3.将S2步骤产生的增删改查事件路由到分布式的并行Stream管道；
S4.并行Stream管道将增删改查事件以异步请求响应模式按各表配置的维度字段路由分发到Actor模型分片集群的Actor实体中；
S5.在Actor模型分片集群的Actor实体中根据增删改查事件的先后顺序进行事件持久化和状态更新，以及基于历史状态的复杂转换逻辑，并将结果返回Stream管道；
S6.Stream管道对Response事件进行消息批化和排序去重处理；
S7.将S6步骤的结果写入Sink数据源，并进行Source数据源和Sink数据源的端到端的异步ACK机制，如果确认成功，就完成数据同步。
2.根据权利要求1所述的具备全链路反压特性的数据同步方法，其特征在于，步骤S2中，数据库binlog日志中日志的产生毫秒时间戳ts，数据库binlog日志的文件名后缀和增删改查事件在数据库binlog日志的文件中的偏移两者组合形成uid属性，基于uid、ts信息准确判断出增删改查事件的先后顺序。
3.根据权利要求1所述的具备全链路反压特性的数据同步方法，其特征在于，步骤S2中，进行基于SQL模式全量同步，同步后产生查事件，具体包括：
S2.1.API提交的全量同步任务包括多表关联拉取任务和多表独立拉取任务；
S2.2.步骤S2.1中如果是多表关联拉取任务，提交的接口数据会有1个主表和多个辅助表，对主表构建SQL，进行分片逻辑得到分片SQL，对主表的分片SQL进行并行受控拉取，由主表记录驱动反查辅助表，将查询得到的数据进行格式转换，保持和增量同步的数据格式一致，对主表和辅助表的数据进行消息批化处理，得到最终数据；
S2.3.步骤S2.1中如果是多表独立拉取任务，则构建表SQL，均匀分发到各节点，对表SQL进行分片逻辑得到分片SQL，对分片SQL进行并行受控拉取，将拉取到的数据进行格式转换，保持和增量同步的数据格式一致，得到最终数据；
S2.4.将步骤S2.2的最终数据和步骤S2.3得到的最终数据作为查事件。
4.根据权利要求1所述的具备全链路反压特性的数据同步方法，其特征在于，步骤S5中，基于当前状态的复杂转换逻辑包括：
S5.1.Actor模型分片集群中的Actor实体中的当前状态由经步骤S4中维度字段逻辑切分得到的多张子表构成；
S5.2.对当前状态中的子表的操作，封装成SQL模式，经过SQL模式计算处理后得到临时的中间表，作为下一个操作的输入表；
S5.3.组合多个子表的操作得到复杂转换逻辑。
5.根据权利要求1所述的具备全链路反压特性的数据同步方法，其特征在于，步骤S7中，进行Source数据源和Sink数据源的端到端的异步ACK机制，具体包括：
步骤S2中增删改查事件具有消息确认的地址ActorRef和唯一的AckId属性，数据成功写入Sink数据源后，会根据ActorRef和AckId进行Source数据源到Sink数据源的端到端异步ACK处理，如果确认失败，基于数据库binlog日志的增量同步会重启并重置到最近成功ACK过的位点继续恢复同步，而基于SQL模式全量同步会继续同步，待全量同步结束后进行未确认的消息重试。
6.一种具备全链路反压特性的数据同步系统，其特征在于，包括：
用于配置和持久化任务元数据的任务元数据模块；
对存量数据进行高效并行同步的全量数据同步模块；
对主流关系型数据库的binlog日志进行抽取和解析的增量数据同步模块；
支持最终结果持久化的数据Sink模块；
对海量Actor实体进行分布式管理，Actor计算逻辑可配置化的分片Actor集群管理模块；
用于管理同步并行度的动态并行度管理模块；
用于保证数据的完整性和准确性的定时数据巡检模块。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310379681.6A CN116383308A (zh) | 2023-04-11 | 2023-04-11 | 一种具备全链路反压特性的数据同步方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310379681.6A CN116383308A (zh) | 2023-04-11 | 2023-04-11 | 一种具备全链路反压特性的数据同步方法及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116383308A true CN116383308A (zh) | 2023-07-04 |
Family
ID=86974775
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310379681.6A Pending CN116383308A (zh) | 2023-04-11 | 2023-04-11 | 一种具备全链路反压特性的数据同步方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116383308A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116821245A (zh) * | 2023-07-05 | 2023-09-29 | 贝壳找房(北京)科技有限公司 | 分布式场景下数据聚合同步方法及存储介质 |
-
2023
- 2023-04-11 CN CN202310379681.6A patent/CN116383308A/zh active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116821245A (zh) * | 2023-07-05 | 2023-09-29 | 贝壳找房(北京)科技有限公司 | 分布式场景下数据聚合同步方法及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11921746B2 (en) | Data replication method and apparatus, computer device, and storage medium | |
| US11604804B2 (en) | Data replication system | |
| US10866967B2 (en) | Multi-replica asynchronous table replication | |
| CN111723160A (zh) | 一种多源异构增量数据同步方法及系统 | |
| US9009104B2 (en) | Checkpoint-free in log mining for distributed information sharing | |
| US7702698B1 (en) | Database replication across different database platforms | |
| CN113535656B (zh) | 数据访问方法、装置、设备及存储介质 | |
| JP2019036353A (ja) | 索引更新パイプライン | |
| US20150032695A1 (en) | Client and server integration for replicating data | |
| WO2013155752A1 (zh) | 面向数据库与Hadoop混合平台的OLAP查询处理方法 | |
| US11176111B2 (en) | Distributed database management system with dynamically split B-tree indexes | |
| EP3958142A1 (en) | Projections for big database systems | |
| EP3391249A1 (en) | Replication of structured data records among partitioned data storage spaces | |
| WO2023066086A1 (zh) | 数据处理方法、分布式数据库系统、电子设备及存储介质 | |
| CN104750855A (zh) | 一种大数据存储优化方法和装置 | |
| CN116383308A (zh) | 一种具备全链路反压特性的数据同步方法及系统 | |
| CN114153809A (zh) | 基于数据库日志并行实时增量统计的方法 | |
| CN117056303B (zh) | 适用于军事行动大数据的数据存储方法及装置 | |
| WO2024081139A1 (en) | Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full sql support and horizontal scalability | |
| CN114003580A (zh) | 一种运用于分布式调度系统的数据库构建方法及装置 | |
| US8705537B1 (en) | Eventually-consistent data stream consolidation | |
| CN110928839B (zh) | 国际运价数据的存储方法和系统 | |
| US20240126781A1 (en) | Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full sql support and horizontal scalability | |
| CN117708243A (zh) | 一种基于Flink CDC的多源异构数据同步方法 | |
| WO2024081140A1 (en) | Configuration and management of replication units for asynchronous database transaction replication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |