Delphi解决方案实现两个远程站点之间松散连接的数据复制

Question

我正在使用Delphi架构师(Delphi也可以)，我需要为以下问题找到一个智能解决方案，我想使用以下框架之一: XE4或RemOjects SDK / DataAbstract或RealThinClient

目前，我在站点A上使用了一个非常简单的MSSQL数据库，该数据库由站点B的用户通过远程桌面使用。应用程序有时需要显示一些图片，也需要查看一些PDF，但它主要是文本数据输入。

我没有特别的理由使用MSSQL，但它是我发现的一个已经激活并填充的数据库，而且我还没有自己构建它。现在，改变它将变得更加复杂。(数据库不重要，不使用特定特性、存储过程或触发器)

站点B的用户通过网络连接连接到A站点的速度非常慢，有时几个小时甚至一天都无法连接到A站点(这是主要问题)。遗憾的是，由于种种原因，这种联系的情况无法得到改善。

数据库非常简单，有许多表几乎没有变化，大约有10个表每天更新，并且可能会受到相互竞争的更改的影响。

这些表的记录主要包含数据，这些数据被锁在update中，由单个用户编辑某些字段，然后保存释放锁。

我想得到一些非常不同的东西来优化性能。

A站点的用户有更高的优先级，他们更重要，因为A站点是总部。

我希望在站点A有一个数据库副本到站点B，这样站点B的用户可以在本地工作，在不使用远程桌面连接到站点A的情况下，工作速度要快得多。RDP协议不是很优化，而且在任何情况下，如果没有连接，用户就无法工作。

同步和更新两个数据库之间的数据库锁记录可能不是一个大问题。

基本上，当站点B的用户获得在数据库B中编辑记录时，站点A的用户显然不应该能够在站点A的数据库上修改相同的记录。当然，这也应该朝着相反的方向工作。

我的大问题是弄清楚如何最好地处理当B和A之间的连接在几个小时内不可用时所发生的情况。(B站点上的事务/事件正在增加)。A场地上的事件一般优先于B场地上的事件(碰撞事件)。

站点B的用户必须能够继续工作。当连接处于活动状态时，应将更改发送到站点A的数据库。这显然会导致冲突，但用户B可能在记录上所做的更改可以放弃，也可以由站点B的记录用户在有选择的合并和批准记录的监督下进行。

好吧，我希望这个场景能被解释得很清楚。

其他信息：

• DB模式非常简单，只有表，没有触发器，存储过程。因此，我可以构建一个示例，但是可以想象10个表可以以并发方式更新。
• DB被销售部门的桌面应用程序使用，因此它包含了大部分机密数据。
• 远程连接通常是最大512 site，但这里的主要问题是，有时连接可能不是活动的，而且远程站点上的用户无论如何都必须工作。THis是主要关注点。
• 每日更新的总数据最多可达10 Mb，压缩后，仅用于DB连接。在同一连接上还有其他一些数据是同步的，但它们不是此工作的一部分。
• 我不想使用特定的MSSQL工具或服务(复制等等)，因为DB将来可能会改变。

谢谢

Answer 1

我们使用Delphi应用程序、基于kbmMW的Delphi应用程序、(尽管它在DBISAM数据库上也非常愉快地工作)几乎完全做到了这一点。

我们有一些只允许总部网站用户修改的表。每次出现“合并”时，都会将较小的表全部转移。较大的表和事务类型表都有一个日期添加和/或日期修改字段，并且只有在过去3周左右(可配置的)中更改或添加的记录才被传输。这意味着，网站仍然可以更新最新的数据，即使他们已经断开了相当一段时间-我们过去有客户在遥远的地方，在可疑的拨号线路！

我们每天只运行一次或两次合并例程，但它在每小时或其他时间安排上都会运行得很好。

在一天中的特定时间，每个站点(包括总部)将其更改的/新记录“导出”到文件中(例如客户数据集表或类似文件)。然后，应用程序将它们拉链起来，并放置在“传出”文件夹中。压缩文件是根据位置id、日期、时间等来命名的。文件通过一些外部方式传输，例如通过FTP /文件共享/电子邮件等。每个分支机构将其数据文件发送/传输到总部，总部将其数据传输到每个分支机构。文件以任何方式传输到“传入”文件夹。

定期(如每小时)，每个位置检查传入的文件夹，看看是否有什么新的东西可供它导入。如果是这样，则添加所有新记录，分支机构用新记录覆盖总部数据表，并以“某种方式”合并经过编辑的记录。这是个棘手的问题。最简单的策略是“总部获胜”，所以所有编辑都会被接受，除非有冲突，在这种情况下，总部版本获胜。另外，你也可以使用“最后编辑的胜利”--但是你需要确保时钟在不同的位置是同步的。另一种选择是将冲突的记录添加到某种形式的“悬念”状态中，并让最终用户在将来的某个时候作出决定。我们在一个数据集上这样做。无论选择哪种冲突方法，都需要以某种形式的日志表记录每个决策，并提示管理级别用户偶尔进行检查。

当总部导入数据或在总部添加数据时，将设置一个字段以指示数据是主数据的一部分。当分支添加数据时，此字段为空，以指示尚未到达主集。当分支导出数据时，这会有所帮助，因为它们可以包含所有没有此字段集的数据。

我们已经发现，您不能以交互方式运行合并，因为最终您将永远无法完成任何工作，并且无法在夜间运行合并等等。它需要完全自动化，管理员用户可以在事后的某个时间点进行调整。

多年来，我们在多个站点的运营中一直采用这种方法，一旦它稳定下来，它的效果就相当完美了。由于每天有两个进出口时间表，我们发现分支机构运转良好，只损失了不到一天的交易。在我们不经常发生冲突的场景中，效果很好。导出的数据在5-10MB的范围内，它的压缩足够小。

主键很重要！我们用的是GUID，它还没有让我们失望。

实际上，数据库服务器和n层框架的选择是无关的。这个过程才是重要的。

基本上，当站点B的用户获得在数据库B中编辑记录时，站点A的用户显然不应该能够在站点A的数据库上修改相同的记录。当然，这也应该朝着相反的方向工作。

如果两个站点都有自己的数据库副本，并且允许偶尔丢弃/不存在的站点间连接，我看不出您将如何使这个比特可靠地工作。