数据库关系的五种基本操作，简析关系型数据库同步数据的三种方案

前言

2年前给公司研报写的一篇技术稿，走运发到了头版，也算圆了头条梦了....时隔有点久，也有日子没搞服务端了，不知道有没有过时..

关系型数据库在软件工程中的应用无处不在，随着业务需求的不断增加，会出现不同空间数据库之间进行数据共享或者集中管理的需求，如何将不同数据库之间的数据进行有效合理的迁移甚至汇总，在DB领域也是个值得摸索的方向。实际应用中，因通讯状况、业务复杂度、数据量大小的不同，会选择不同的解决方案去满足现实需要，以下以MySQL(目前最流行的关系型数据库管理系统)为例，根据个人的经验与理解简述三种可用的方案。

1.MySQL Replication方式

MySQL自带Replication功能，字面上来看，也就是将一台数据库的数据向另外一台数据库进行复制，通过对数据库日志文件的传输复制并解析，可以在两台以上数据库之间进行数据的拷贝，作为Mysql的官方功能运行也稳定，听起来似乎已经满足不同数据库进行数据同步的需求，但深究还是有局限性的。

首先它的同步原理是日志文件的传输，数据库日志文件随着时间推移会相当庞大，异步传输过程中有可能在某个时间点需要传输大量的文件流，如果网络状况不好的话会有异常发生，所以Replication功能常被用来做数据库系统的读写分离，针对同一网络环境下比如同一个机房内的不同服务器进行配置应用，一台数据库负责数据的写入，另一台数据库负责数据的读取，因为网络环境稳定，通过Replication保持数据的一致，分担读写都在一台数据库实例情景下的压力，追求负载均衡。

另外目前MySQL的Replication只支持一主多从的复制拓扑，可以将数据从一台服务器拷贝到多台服务器中，但满足不了多主一从的场景，即解决不了多台服务器向一台服务器进行数据拷贝可能引起的数据冲突问题。

2.第三方同步服务

MySQL Replication的功能有限，面对各种特定场景的数据同步需求，很多软件厂商推出了自己的同步解决方案，下面介绍一种使用较多的第三方开源服务SymmetricDS。

SymmetricDS是基于Java环境的分布式服务，在需要数据同步的每个数据库服务器中，都需要部署它的服务并根据业务进行配置。它的原理是基于触发器机制，只要当前数据库中有数据变动，例如行数据的增删改，服务就会被触发并捕获到数据变动，根据事先配置好的同步规则，向其他服务器发起变动请求。这种方式在数据有变化时才会占用网络资源，而且保证数据变化时可以实时发起同步请求。

然而，因为是第三方软件厂商提供的普遍适用性方案，做不到完全满足每种业务的需求，对于业务复杂的同步场景，需要人们在部署服务时进行繁琐的配置工作。SymmetricDS的配置大部分工作都是在其自带的物理表中完成，不光配置的规则甚多，光这些物理表的数量就达到了40张，可见显得臃肿且维护不易。而且相比第一种方案，虽然数据库静默时消耗网络资源少，但在大数据量变动的场景下，依然会消耗很多。在多主一从场景下，SymmetricDS虽然也支持多个数据库实例向一个数据库实例进行数据同步，但对多数据的整合只能依据表的物理主键进行插入或者更新操作，不能按照实际业务中的逻辑主键来决定数据的行为，简单来说，无法合理控制同步的业务逻辑，只适用于简单业务逻辑的表同步。

3.自编码方式

为使数据的同步满足自身业务的需求，同时可以控制网络资源的占用时间段，最适合的方法应该是自己编码实现服务器之间数据的传输及整合，以下以Java实现多服务器之间进行数据同步为例做介绍。

JDBC是Java中实现与各数据库进行访问的一种API，通过使用数据库连接字符串(包含数据库服务器IP、访问用户名密码等信息)，建立与数据库的通信，这使我们可以采用多线程的方式同时建立起对多个数据库的访问，并将数据读取到本地在代码层进行业务上的操作，最后再更新插入到目标数据库中。与SymmetricDS在每个数据库的节点都要部署服务的方式不同，这种方式对数据库的访问可以在代码中进行动态控制，有可能我们只要在一台服务器上部署同步服务，就可以实现对远程多台服务器上数据的读取并更新到本地。

前期的配置也必不可少，因为JDBC是通过sql语句完成对数据库的增删改查行为，这就要求在同步服务发起前，我们需要对每张物理表生成对应的sql语句模板，当然可以用编码的手段来完成这步工作，另外每个数据库节点的数据结构也有可能存在差异，实际业务操作中也需要对异构数据进行筛选才可以得到适用于目标服务器的数据，这些细节的处理在此就不做阐述了。

自编码实现同步服务的方式，对于有实时性要求的数据可以配置在短时间间隔就发起一次同步，对于没有实时要求的数据，可以让其在夜间等服务器压力相对小的时段再发起同步，这些都是可控的。当然这也并不就是一种完美的方案，因为对数据库的通讯访问是定时发起的，并不是长时间保持连接，这就意味着，在一次定时同步的过程中如果网络突然中断或者通讯条件不好，那么这一次的同步操作失去了连接导致失败，只能依赖于下一次的同步操作再重新发起连接完成同步。

可见三种同步的方式各有优缺点，在实际应用场景中，应综合考虑选择哪一种方式来尽可能的满足需求。

结语

文中的SymmetricDS方案后面将当时的 部署记录放出来，自编码方式也做过一个web工具，适用于多数据源的表数据同步，有时间也做个开源。

,