DB2一个基于Cache Table的数据复制方案
IBM 数据库复制产品 Infosphere Replication Server 中的多向 SQL 复制既能捕获源表也能捕获目标表的数据变化，因此能很好地保持数据在各方的一致。
但数据冲突的现象仍是无法完全杜绝。因此我们需要尽可能地改进方案，以期接近完美效果。本文在这样的背景下，介绍了 IBM 相关产品 Infosphere Replication Server 和 Infosphere Federation Server 通过合作提出的一个基于 Cache Table 的数据复制方案。
计算机、网络、传感技术等各项信息技术的发展，使得我们生活的环境变成了今天这个由数据统治的世界，每天都有大量纷繁复杂的数据、信息充斥耳边。据称现在只需两天就能创造出自文明诞生以来到 2003 年所产生的数据总量。而企业数据也以 55% 的速率逐年增长。这些大量的交易数据、交互数据中并不是 100% 都是有意义的，但我们又不得不去接收它们。这是因为数据当中隐含着有价值的信息，并且这些信息都是有时效的，需要及时进行整合、分析、再创造，然后才能更好地与用户交互，实现在合适的时间、通过合适的途径、销售合适的产品，最终实现企业利润增长。数据复制产品正是这一数据处理过程中最关键的一环，它能够将接收到的数据分发到各个场所，用于及时整合数据，产生实时报表，或者为实时统计提供输入。
数据集中 / 分发经典场景
对于集团型企业，例如银行、电信、保险等，通常包含多个子系统，每个系统对应一项或多项业务，而业务终端也往往部署在各个省市地区。某个地区的某个子系统里数据在一定时间内只能代表该地区的业务特征。因此，业务的广泛性和区域性使得企业不能对内部的数据进行全盘规划和统一，这大大影响了企业对业务的分析决策。具体影响有：
- 关键数据不唯一，集团无法判断数据的准确性，需要花费更多的人工和资源验证并纠正数据，因此不能对分公司或子公司的数据进行及时分析，从而进行全盘分析和规划；
- 分公司或子公司间数据无交互或交互较少，各自为政，数据无共享，造成各分公司或子公司间不能有效借鉴或沿用有价值或有代表性的决策和方案，集团范围内数据管理困难，数据丢失的风险性较高。
没有统一的关键数据管理会造成集团范围内不能实时监控并及时分配关键资源，不能及时获取各地数据掌握全局趋势，也往往会造成决策失误。这些问题严重的话会造成企业无法弥补的损失。因此企业通常会建立数据中心、部署一套数据集中 / 分发方案以保证各地各项业务数据的统一。典型场景如图 1 所示，在集团所在地或附近建立中心，在各分公司或子公司部署分级。中心服务器与分级服务器间通过网络实时通信，分发或集中数据。各分级服务期间根据需要也可进行通信。
图 1. 数据集中 / 分发场景
数据集中 / 分发对数据冲突和负载均衡的要求
数据的集中和分发根据实际情况要求和设计考虑的角度的不同，具体实现起来方案有很多。有些由中心服务器承担主要业务输入，有些反之，有些根据具体情况不同，对不同的业务指定不同的主承受服务器。但究其本质是如何保证事务的原子性和数据在各个副本中的一致性。这方面从技术发展历程来看，早期主要通过两阶段提交协议实现原子性，通过两阶段锁或时间戳模型实现副本的一致性。这种模式即为通常所说的同步复制过程，涉及到各副本与提交事务的节点间的互相确认过程，因此具有一定的性能影响。后来为提高吞吐率，缩短响应时间，对一致性级别进行了放松，出现了异步复制，面对不同的目的，出现了不同的异步复制协议。目前企业中使用的复制产品大多为异步复制。这种方案不能像同步复制那样实现完全实时复制，必然会出现一定的延时，虽然这种延时通过各种技术手段可以控制在秒级，甚至更小，但对于在每个副本都能操作数据的系统中，还是有可能出现数据冲突。
数据冲突简单地说，是因为某一行数据在不同地点被不同的应用同时进行了修改。这种修改具体表现有插入、更新、删除。举例来说，有表（列 1，列 2，列 3），其中列 1 是表的主键，该表同时部署在两地的 Server A 和 Server B 中。最普遍的冲突情况是，A 和 B 同时有应用对该表插入了具有相关关键字的数据，该事务在本地服务器上能执行成功，但当数据变化传递到对方时，会发现以这个关键字值标记的行已存在，冲突发生；另一种普遍的冲突是，A 和 B 同时修改了相同关键字行的非关键字列，这样当变化传递到对方时，冲突发生。无论具体冲突是什么情况，在异步复制中都无法完全避免，因此在设计方案时必须要有在发生数据冲突时，一些有效的冲突解决方案，这样才能最终保证数据的一致。
由于业务的多样性，由单个服务器承受所有的业务具有很高的风险性，当出现断电等意外，或者更大的自然灾害时，损失是无法挽回的。因此设计数据集中 / 分发方案时需要考虑如何实现负载均衡。从全局来看，需要合理分配各项业务的连接；从具体业务来看，需要合理均衡读连接和写连接，特别对于具有大用户量的业务，用户对系统响应一般都具有较高的期望，用户量也往往跟系统响应时间负相关，而受限于服务器以及数据库系统的处理能力，单个表是很难满足大量同时的读写连接的。
多向 SQL 复制实现数据集中 / 分发
IBM InfoSphere Replication Server 产品中的 SQL 复制框架最早可以追溯到 1994 年 IBM DB2 发布的 DataPropagator Relational（DPropR）的第一个版本。因此，相较于 2004 年推出的 Q 复制框架，SQL 复制功能的客户基础较深厚，事实证明它在实现数据集中 / 分发方面具有较好的优势和稳定性。本节将带领读者简单回顾一下多向 SQL 复制的实现。