问如何使用rest在两个独立系统之间同步数据？

EN

1.全同步

我建议始终开发一个完全同步。即使你有部分同步，偶尔进行一次完全同步也没有错，以确保每件事都能满足你的要求。

请注意，您也不能安排完全同步，而是让支持应用程序的人手动触发它。

2.基于事件的同步-第一解释

我对你的解释有点困惑。最初，我将此理解为B触发的事件，以便在B中更新给定项时立即得到更新。

这样做的好处是复制时间非常快，您会立即意识到任何更改。它还最小化了数据传输的大小。

作为一个缺点，事件驱动的系统通常更难调试。

当A和B之间的网络连接被切断(或者当A离线时)但B仍然在处理更新时，您还会遇到这样的问题。唯一解决这个问题的方法是B有一个消息队列，在那里丢失的事件将被存储，直到您确认接收到它们为止，但我推测您无法控制B的开发。

这就是为什么您希望偶尔进行一次完全同步。它解决了任何可能在某个点或另一点上发生的问题。

基于事件的同步和完全同步(频率较低)的组合会完成这项工作吗？

因此，如果这一解释是正确的，那么事件驱动的部分同步最好使用不频繁的完全同步来修复可能偶尔发生的不可避免的问题。

2.基于事件的同步秒解释

但重新阅读时，它似乎更像是B没有参与到事件中来。您计划执行几个同步操作，并希望在应用程序中使用内部事件来一个接一个地链接这些操作。

有许多方法可以实现同步操作的编排。同步，异步，计划，触发，事件驱动，

但是，您的问题的重点似乎是最大限度地提高数据正确性，同时将网络使用率降到最低。如何在应用程序内部处理问题对此没有影响(除非代码中有任何bug，这似乎也超出了当前问题的范围)。

这里还有第三种选择，但也需要B来实现这一点。

3.差分同步。

差异同步和完全同步之间的关键区别是，差异同步只提供自上次同步以来已更新的项。

这为您提供了完全同步的好处(即您控制接收更新的时间)，但通过删除不需要更新的项(因为它们没有更改)来降低网络使用率。

差异同步可以有多种不同的风格：

• B可能跟踪上次同步的时间。或者A可能需要传递时间戳，以便A可以通过使用旧的时间戳来选择重新执行以前的同步操作，或者通过省略时间戳来完成完全同步。(我更喜欢后一种选择)。
• B可能会向您发送更新项的完整数据，也可能只发送更新项的更新字段。后者的网络使用效率要高得多，但在A和B端实现都要复杂得多。

这是版本控制工具(如Git或SVN )所基于的基本原则。它极大地降低了数据的使用(因为更新通常只改变整体的一小部分)，但与完全同步(这是一种简单的覆盖操作)相比，它需要更多的数据处理逻辑。

但是，这需要B开发差分同步功能。您不能独自完成这个任务(除非您目前已经能够查询“上次更新”字段)。

Note

如果可以在B端删除项目，则差异同步可能成为一个问题。如果A项不是差异同步数据的一部分，这可能意味着A已经被删除，或者A还没有被更新。

但是，我预计大多数系统都会实现软删除；它解决了这个问题，因为软删除是对项的更新。

如果B确实允许硬删除，则不能使用差分同步(除非B也能够更新删除的内容)。