[发明专利]海量数据同步系统及方法

说明书

技术领域

本申请涉及一种数据同步技术，尤其是涉及一种可进行自我修复的海量数据实时同步系统及方法。

背景技术

在有着某种业务关联的分布式数据库和分布式信息系统的各类应用中，常常需要对不同的分布式数据库和/或信息应用系统中的一些关键数据进行同步，以维护它们之间的数据的一致性。在需要同步的数据量、信息应用系统的独立性、实时性及容错性要求不高的情况下，通常使用数据库同步、ftp、http下载或者简单的接口调用等方法就可以满足需求。

可是，数据库同步方法无疑会导致两个关联的信息应用系统有相当部分的数据库表结构完全一样，这样做的后果是两个关联的信息应用系统之间会出现底层表设计的直接依赖，令这两个关联的信息应用系统都必须有同样的数据库表设计，产生不必要的数据传输，并浪费网络带宽。其次，一旦所涉及的数据量达到海量(数以亿计)级别而需要同步的数据仅仅为总数据量的一个很小的子集时，如何快速定位到需要同步的数据也会是一个异常突出的问题。再次，如果需要进行数据同步的信息应用系统是对外提供某种服务的应用系统(例如大型在线购物网站、大型社交网站或大型游戏网站)，通常会在某些时段出现访问高峰，高峰时段额外非核心的数据同步需求会很巨大，从而导致服务器负载升高，还会消耗大量的网络带宽。在这种情况下，要么是造成服务堵塞，要么就是导致系统崩溃。因此同步系统的服务能力的高低的可拓展性和对错误的修复能力就至关紧要。

具体而言，例如，假设在涉及数据同步的两个相互关联的信息应用系统中，将出现资源数据变化的系统称为资源系统A，将关注资源数据变化并随之进行数据变化的系统称为目标系统B。同时，还将控制和执行数据同步步骤以将资源系统A的数据同步到目标系统B的系统称为同步系统C，即数据需要从系统A经由同步系统C而同步到系统B。数据同步的过程一般包括以下步骤：

1)资源数据在系统A中发生变化；

2)系统A通过发布通知消息或者调用依附于同步系统C的监听接口来告知同步系统C；

3)同步系统C筛选出需要同步到系统B中的数据；

4)同步系统C将筛选出的数据同步到系统B中。

现有的数据筛选技术通常包括数据库查询、文件索引、内存索引以及重做日志(redo log)监控方式等。其中：

●数据库查询方式是在同步时每次都通过查询数据是否存在于系统B的数据库中，从而实现数据筛选。

●内存索引方式是建立全量数据的内存映射关系索引，在同步时每次查询该内存索引，从而实现数据筛选。

●文件索引方式是建立全量数据的文件映射关系的索引(即建立索引文件)，在同步时每次查询该索引文件，从而实现数据筛选。此索引文件被存储于持久化存储系统(非易失性存储器)中，当系统访问该索引文件里的数据时，需要先将该索引文件中的数据加载到内存中。文件索引方式比内存索引方式多了一个加载的步骤，但是数据是持久化地保存在存储系统中，不会因为断电或者系统重新启动而导致数据丢失。

●重做日志监控方式是实时或者准实时地监控系统A的数据库的重做日志来感知数据的变化，从而实现数据同步。其中重做日志(redo log)是一种数据库文件，每当执行一次操作以真正改变数据之前，将原数据或之前的操作写入该数据库文件中，这样当发生断电等故障而导致后续任务无法完成时，可以从中恢复原来的状态并继续进行后续任务。

这些现有的数据筛选技术的缺点是：

数据库查询方式往往需要执行sql语句查询请求、编译sql语句、sql语句优化、索引查找、数据收集、结果返回等一系列操作，进行数据库查询的代价是非常昂贵的。实时性比较差，也不适合海量数据的同步。

文件索引方式与数据库查询的方式类似，只是少了网络传输，不过却需要一直维护新数据的索引文件的创建、与原有索引合并等操作，同样是代价巨大的。

而内存索引方式会随着数据量的增大而消耗大量的内存。

重做日志监控方式虽然能够通过实时或者准实时地监控系统A的数据库(redo log)来感知数据的变化，但当发生变化的数据量中仅有小部分数据需要被同步时，现有技术仍不能有效筛选出此小部分数据，因此仍然存在大量的重复操作和内存占用过多等问题。

此外，数据库查询、文件索引、内存索引和重做日志监控方式都不能解决异常容错(即发生错误或者超出服务能力而不崩溃的能力)和自我修复的问题。因此上述方案都不能提供实际应用中所要求的海量数据高效同步、高度解耦、流量控制和自我修复等多项要求。

发明内容