本发明涉及计算机网络领域，具体涉及一种数据同步方法和装置。
背景技术：
随着互联网使用的普及，以及互联网应用7*24全天服务的天然属性，网站的可用性对大型互联网公司越来越重要。即使几分钟的宕机都有可能给互联网公司和用户造成巨大损失。导致网站宕机的因素主要包括服务器、网络设备、机房、isp网络线路、天气自然灾害等不可抗力。冗余是提升网站可用性的主要方式。通常大型互联网公司都会将重要的网站系统部署到多台服务器、多个机房、多个城市、甚至全球。对于数据系统来说，在比较稳定可靠的网络环境下，我们一般使用数据库本身提供的复制技术来实现数据冗余。当网络环境变得不稳定时，数据库自身提供的复制技术往往达不到足够的健壮性；而且无法提供足够低的复制延时。因此，在跨机房、跨地域的网络环境中，如何提供一种低延时高可用的数据库同步系统，就成为提高可用性的关键。
现有技术之一是mysqlreplication，即mysql主从复制。mysql复制是一种基于事务日志传输(logshipping)的主从同步技术。当主服务器上有事务写入时，主服务器先将事务数据写入事务日志(writeaheadlog)中，然后再执行事务包含的数据变更，修改数据文件。在从服务器上执行指定主服务器的操作后，从服务器运行io线程，连接主服务器，向主服务器请求事务日志传输。从服务器上的io线程将接收到的事务日志写入本地的事务日志文件(relaylog)。从服务器同时运行sql线程，读取本地的事务日志文件，逐条执行事务中包含的数据变更，最终写入从服务器的数据文件。
另一种现有技术是oraclegoldengate。这是一种支持oracle、mysql等多种数据库的复制技术。其原理上与mysql类似，也是基于事务日志传输，主要不同在于oraclegoldengate是以第三方组件的方式运行，部署上独立于数据库系统。
但是，这两种技术都存在较为明显的缺点。mysql主从复制技术在日常数据库运维中使用非常广泛，主要是因为这种复制技术由mysql自身直接提供，不需要安装任何三方组件；另外使用上比较简单。不过，mysql复制一直遭到诟病的地方就在于复制性能。直到mysql5.6，mysql才开始对复制性能进行优化。另外，由于mysql复制由mysql自身提供，外围系统无法介入，也就无法实现诸如异构复制、双向复制、消息分发等高级功能。oraclegoldengate由于对oracle的良好支持，在电信、银行等传统行业应用比较广泛。但其商业产品属性，决定了有限的扩展性，无法适应互联网公司需求复杂多变的使用场景。
技术实现要素：
有鉴于此，本发明提供了一种低延时高可用的数据同步方法和装置。其提高mysql复制的性能，跟mysql复制相比提高5-10倍。同时，本发明从设计上提供了通过事务日志传输进行数据变更分发的架构灵活性。
根据本发明的实施例的第一方面，提供一种数据同步方法，包括：向中继器(relay)请求事务日志，如果无法从中继器接收事务日志，则向快照服务器请求事务日志；从中继器或快照(snapshot)服务器接收事务日志；以及应用事务日志以同步数据。
根据本发明的实施例的第二方面，还提供了一种数据同步装置，包括：请求单元，被配置为向中继器请求事务日志，如果无法从中继器接收事务日志，则向快照服务器请求事务日志；接收单元，被配置为从中继器或快照服务器接收事务日志；以及事务日志应用单元，被配置为应用事务日志以同步数据；以及应用单元，被配置为接收并应用所述事务日志以同步数据。
附图说明
图1是示出根据本发明的实施例的数据同步中心的示意图。
图2是示出根据本发明的实施例的数据同步方法的流程图。
图3是示出根据本发明的实施例的用于快照服务器的方法的流程图。
图4是示出根据本发明的实施例的数据同步装置的框图。
具体实施方式
本发明从基本原理上跟mysql复制相同，都是通过将主数据库上的事务日志传输到从数据库，然后逐条应用到从数据库上。本发明通过高度并行化改进了从数据库端入库算法，从而提高了复制性能。
图1示出根据本发明的实施例的数据同步中心的示意图。数据同步中心主要由三个组件构成：中继器(relay)，快照(snapshot)，复制器(replicator)。整个系统的核心工作流程如下：
(1)relay从数据源抽取事务日志，放到环形缓存(ringbuffer)中，作为内存日志队列；
(2)replicator跟relay建立连接，请求在线变更(onlinetransfer)，即请求一段增量事务日志；
(3)relay从ringbuffer中取出对应的事务日志块，发送给replicator；
(4)replicator接收事务日志后，跟目标数据库建立连接，并应用事务日志；
(5)如果1.3中relay没有找到对应的事务日志块，就发送未找到通知(例如，404)给replicator；
(6)replicator收到未找到通知404后，跟snapshot建立连接，请求快照增量(snapshotdelta)；
(7)snapshot从其存储器中取出对应的快照增量，发送给replicator；
(8)replicator收到快照增量后，跟目标数据库建立连接，并应用事务日志；
(9)在2-8过程中，snapshot作为一个relay的特殊消费端，一直在从relay订阅所有的在线变更，并写到存储器中，作为relay数据过期时的后备；
以下将描述本发明的主要组件中继器(relya)、复制器(replicator)以及快照(snapshot)。
1、中继器(relay)
中继器relay从来源数据库抽取事务日志，并对replicator提供日志订阅服务，角色上相当于mysqlslaveiothread。relay在设计上以单线程方式连接源数据库，使用环形缓存(ringbuffer)作为事务日志存储的数据结构，保证了读取性能；另外对于大写入量的数据库，relay还可以使用内存镜像文件作为事务日志存储，保证可以接收足够高的写入量。
relay的工作流程如下：
1.1eventproducer线程向数据源建立连接，发起事务日志抽取请求，持续拉取事务日志；
1.2eventproducer将拉取过来的事务日志进行解析，根据事先定义的avroschema，序列化成avro格式；
1.3eventproducer将事务日志的avro格式添加到ringbuffer中；
1.4如果达到指定的checkpoint时间间隔，eventproducer将当前已写入ringbuffer的最大事务日志序号写入checkpoint；
2、复制器(replicator)
replicator是事务日志的消费端，从relay或snapshot拉取事务日志，将事务日志按配置的一致性应用到目标数据库，角色上相当于mysqlslavesqlthread。
replicator可以根据一致性配置，灵活的选择库、表、行等各级并行度的入库算法；对于大批量的连续数据写入，使用批量提交。replicator还提供了统一的事务日志消费接口，消除了与数据源事务日志格式的耦合。
replicator的主要工作流程如下：
2.1relaypuller线程跟relay建立连接，订阅事务日志，并将收 到的事务日志写入ringbuffer中；
2.2dispatcher从ringbuffer中取出批量的事务日志块，根据一致性配置，对事务日志进行分组、合并、生成入库语句等处理，发送到callback线程；
2.3callback线程池，根据一致性配置，对分组的入库语句，执行并行提交；
2.4当2.2.2.1中relaypuller线程从relay收到404时，转而发起snapshotpuller线程向snapshot发送订阅请求，从snapshot收到事务日志后，继续执行剩余处理步骤；
2.5每个callback线程执行成功后，将已提交成功的事务序列号写入线程对应的checkpoint；
3、快照(snapshot)
快照(snapshot)负责从relay订阅所有事务日志，写入持久存储作为快照，同时向replicator提供批量日志订阅服务，角色上相当于mysqlslaverelaylog。
如前所述，正常情况下，replicator直接连接relay，消费relay内存队列中的事务日志。但有些情况下，因为网络抖动、目标库的负载过高等因素，可能导致replicator相对relay落后很多。另外，当新的消费端加入同一数据源的订阅者时，新消费端有冷启动的问题。为了避免重新从数据源做全量快照，snapshot作为relay的一个特殊消费端，通过一种高吞吐的消费方式，从relay源源不断的消费在线事务日志，通过对事务日志的有效处理，最终保存了数据源的一份一致快照，即包括了数据源库表中每一行的最新状态的快照，同时保留了一段回溯时间比relaybuffer更长的事务日志。
snapshot主要包括snapshot增量流程和snapshot快照工作流程。
snapshot增量工作流程如下：
3.1当replicator向snapshot发送订阅请求时，snapshot检查请求参数中的起始事务日志序号，如果起始事务日志序号在snapshot当前的事务日志存储(logstore)范围内，则启动快照增量流程；
3.2snapshotserver从事务日志存储中读取一个事务日志块，发送 给replicator；
3.3重复执行3.2，直到消费完事务日志存储中的所有日志；
3.4这时，replicator已经追赶上relay，于是replicator重新连接relay，继续消费在线变更；
snapshot快照工作流程如下：
3.1当replicator向snapshot发送订阅请求时，snapshot检查请求参数中的起始事务日志序号，如果起始事务日志序号不在snapshot当前的事务日志存储范围内，则启动快照传输流程；
3.2snapshotserver从快照存储中读取一个事务日志块，发送给replicator；
3.3重复执行3.2，直到消费完快照存储中的所有日志；
3.4replicator继续请求snapshot，进入快照增量工作流程。
此外，本发明还提供了高可用设计，包括：
4.1检查点(checkpoint)机制为整个系统中提供了事务日志的安全生产和消费的保障。为了保证checkpoint的跨机器、跨机房的高可用性，我们选择zookeeper作为checkpoint存储机制。zookeeper使用跨机房部署机构，保证checkpoint跨机房可用。
4.2relay作为高性能的事务日志的中转地，对于保证整个系统端到端的低延时非常重要。为了保证relay的高可用性，我们选择zookeeper实现relay的active-standbyfailover机制。
另外，本发明还提供一个通用的api接口，方便三方系统订阅主数据库上的数据变更。
图2是示出根据本发明的实施例的数据同步方法200的流程图。所述方法200可以在replicator中执行。
在步骤201中，向中继器请求事务日志。步骤202，判断中继器是否存在所请求的事务日志。如果中继器中存在所请求的事务日志，则在步骤204，从中继器接收事务日志。如果中继器中不存在所请求的事务日志，在步骤203向快照服务器请求事务日志，然后在步骤204从快照服务器接收事务日志。在步骤205，应用事务日志以同步数据。
图3是示出根据本发明的实施例的用于快照服务器的方法300的 流程图。
在步骤301，快照服务器从replicator接收事务日志请求。在步骤302，判断事务日志存储中是否存在所请求的事务日志。如果事务日志存储中存在所请求的事务日志，则在步骤303向replicator发送该事务日志。如果在事务日志存储中不存在所请求的事务日志，则在步骤304中，从快照存储中获取事务日志，并向replicator发送该事务日志。
图4是示出根据本发明的实施例的数据同步系统400的框图。所述数据同步装置400包括：请求单元401，被配置为向中继器请求事务日志，如果无法从中继器接收事务日志，则向快照服务器请求事务日志；接收单元402，被配置为从中继器或快照服务器接收事务日志；以及应用单元403，被配置为应用事务日志以同步数据。
综上，本发明通过一种分布式内存队列的数据结构和消费端并行入库的优化算法，可以提供跨机房、跨地域场景下低延时、高可用的数据库同步机制。