时下的数据采集工具，标配功能具备离线采集和实时采集。上次分享中，介绍了离线传输的技术原理，今天给大家大概分享下实时传输的原理。

实时传输无疑要比离线传输有技术门槛一些，技术实现上也更加的复杂。

实时采集的技术也在不断的发展，截止目前，实时采集技术经历了应用双写、准实时、主从复制、实时（Real Time）

准实时、主从复制本质上是基于日志的CDC模式（Change Data Capture）,因此在介绍实时传输原理之前，先介绍下WAL架构。

WAL就是Write Ahead Log，翻译过来就是预写日志。数据库在正式写入数据之前，都需要将写入操作写入到日志当中，在写入操作记录到日志后，才会执行写入操作。

为什么这样做呢？可以保证数据不丢失。试想在取钱的时候，数据库突然断电，钱取了出来，余额却没有变化，银行肯定不愿意干，有了WAL，就不会发生这样的情况，就算数据库断电，有预写日志可以恢复数据。

所以后面基于日志的同步技术，也是利用了数据库的WAL原理。

接下来给大家一一分享数据实时同步的各个阶段。

应用双写

应用双写，为了实现数据同步，是把同样的数据，同时根据需要望目的地写多份。假设这样的场景，应用A将一份数据写入自身的数据库，由于需要同时写入到OLAP做实时分析，所以除了写入到自身数据库，还写了一份到OLAP。

这样存在什么问题呢？如果写入到自身数据库成功，但是写入OLAP失败，于是产生了数据不一致的问题，在分析报告中就产生了少算或多算的问题。

即使应用双写存在数据不一致的问题，但是在2010年-2012年非常流行。那时候正值大数据起步阶段，大家对大数据的使用上，仅限于统计平均值等简单指标，多写或少写一个数据，不影响整体结果，不影响基本应用。随着大数据发展，人们对数据实时性和一致性要求越来越高，应用双写方案也慢慢推出了历史舞台。

准实时

准实时，言外之意，还没有实现真正的数据同步。说到准实时，不得不说Oracle 10G,这个版本提供了Logminner,可以从Logminner获取日志，实现数据的同步。为什么说是准实时呢？是因为没有一种心跳机制，保持与日志工具实时沟通与同步，需要设置一个周期，例如每隔5秒，去获取日志，重做下数据，这样就产生了“不实时”。而且时间周期也不好控制，如果设置得长，数据延时比较大，如果设置得过小，又影响源端得性能。因此这种时间周期，又称之为“MagicNumber”。

准实时需要数据库支持日志的获取，开源版本的数据库，采集工具可直接进行对接，因为能看到源代码，一些商业数据库，得看其是否有对应得工具支持对接。

那如果数据库不提供日志工具，如何做数据准实时同步呢？

这里提一个触发器的方案

Oracle 9I之前的老版本，不提供LogMinner的日志工具，可基于触发器的方案，进行数据同步。

触发器（Trigger），顾名思义，是当一个事件发生，同步触发另一个事件发生。Oracle 9i中，当有数据写入时，同样也在另一个表中执行insertinto，那只需要从另一个表中拿数据，拿了数据之后，就对表做清空处理，这样避免拿到上次的重复数据，如此完成准实时数据获取。

主从复制

提到主从复制，不得不提到MySQL主从高可用架构。在这个架构中，从节点可从主节点实时同步数据，保持数据的一致性。

这种主从复制有什么作用呢？

在数据库中可实现高可用和读写分离，主机宕机，可切换到备节点继续提供服务；主数据负责写，从节点负责数据读取，减轻节点的压力。

那市场上一些数据采集工具的实时数据同步，也用到了主从复制的协议。以Mysql为例，一些采集工具可伪装成Mysql的从节点，从主节点同步数据，达到实时同步的目的。

实时同步（Realtime）

实时同步是当前数据同步技术的最新发展阶段，也是目前最先进的技术，当前一些Oracle、Mongodb、Kudo可支持Realtime同步。

为什么说是最先进的技术呢？

它区别于基于日志的CDC模式，他是一种主动推送机制。拿Oracle 11G以后的版本举例，11G以后的版本支持CDN（Change Data Notify）机制,源端数据有变动，就会主动推送给目的端。

实时同步技术目前还在探索中，除了上述提到的数据库已实现，大部分数据库还未实现，技术上还有待进一步成熟，当前存在一些掉包问题。

今天的分享就到这，希望大家有收获，感谢关注。