转载

数据同步原理

数据同步

原文： https://www.objc.io/issues/10-syncing-da...

这里的数据同步的问题描述的是-多个不同的端存储相同的数据，并需要保证数据的同步。这在现实开发中实在是个令人头疼的难题，参考原文在理解的基础上做了修改和调整

本文想借此展开相关的理论和实例来深入研究一下数据同步问题。

同步客户端服务器 (Synchronous Client-Server, S-CS)

应用直接和远程服务通讯，将数据同步

实例：微信发送一条消息，只有消息发送完成过后才会存储在本地消息发送成功列表中，未发送成功会提示重新发送

异步客户端服务器 (Asynchronous Client-Server, A-CS)

应用将数据保存在本地，应用保持本地数据和远程数据的同步（后台运行）

实例：Mac QuickTime 录制了一段视频，存储在文件系统中，iCoud 自动将文件系统中的数据同步到云端

异步对等方式 (Asynchronous Peer-to-Peer, A-P2P)应用数据保存在本地，应用保持本地数据和其他端的数据同步，每个端存储数据的完成备份，服务器端不存在备份。

识别对象识别需要使用全局标识符 uuids (universaaly Unique identifiers)

变化追踪

描述算法如何确定自上一次数据同步后，数据发生了哪些变化，然后本地存储应该如何修改。

当多端都在共同修改一个实例的时候，就会出现冲突。

假设我们有一个像 iTunes 那样的 Mac 应用程序，它可以通过 USB、蓝牙或者 Wi-Fi 和 iPhone 进行同步通讯。（凭借快速的本地网络，我们不用太在意限制数据传输大小）

第一步：当 iPhone 第一次同步的时候，两个应用程序通过 Bonjour 发现对方，然后 Mac 应用程序将它的所有存储数据压缩，通过套接字将压缩后的文件传递给 iPhone 应用程序，然后 iPhone 将其解压并安装。
第二步：现在假设用户使用 iPhone 对已经存在的对象做了修改 (比如，给一首歌打了星级)。该设备上的应用程序给该对象设置了一个 Boolean 型的标记(比如，changedSinceSync)，用来表示该对象是新的还是已经被修改过的。
第三步：当下一次同步发生的时候，iPhone 应用程序将它的所有数据存储压缩并回发给 Mac。Mac 装载这些数据，寻找被修改的实例，然后更新它自己对应的数据。然后 Mac 又将更新后的数据存储的完整拷贝发送给 iPhone，用来替代 iPhone 已经存在的数据存储，然后整个流程又重新开始。

总结来说，同步操作需要设备能够向其他设备传输数据，并且能够决定哪些被修改、合并，然后回传更新后的数据。保证了这两个设备同步之后具有相同的数据，所以，有很强的健壮性。

当加入了服务器的时候，服务器是为了能够更加灵活地同步数据，但是它是以数据传输和存储为代价的。需要尽可能地减少通讯开销，所以来回地拷贝整个数据是不可行的。

前置条件：假设数据存储在服务器上的数据库中，并且每一个对象都有一个最后更新的时间戳。
第一步：当客户端程序第一次同步的时候下载所有的数据，然后建立一个本地存储，同时也在本地记录同步的时间戳。
第二步：当客户端程序发生改变的时候，它会更新对象的最后更新时间戳。
第三步：当下一次同步发生的时候，客户端会决定自上一次同步后，哪些对象做了修改，然后仅把被修改的对象发送给服务器。服务器会合并这些修改。如果服务器对某一个对象的拷贝被另一个客户端做了修改，那么它会以最近的时间戳为准来保存修改。然后服务器会回传所有比上一次从客户端发来的时间戳新的变化。这需要考虑到合并的问题，删除所有覆盖的变化。

也许有很多不同的方法。比如，你可以为每一个属性引入一个时间戳，然后在属性粒度级去追踪变化。或者你可以在客户端合并所有的数据，然后将合并后的结果发回给服务器，这实际上是互换了角色。但是，基本说来，一个设备发送修改结果给其他设备，然后接收方合并并回发合并后的结果。

删除需要考虑更多。因为一旦删除了一个对象，就不可能跟踪它了。一种选择是使用软删除，也就是对象并不是被真正的删除，而是标记为删除 (比如使用一个 Boolean 属性)。 (这和在 Finder 中删除一个文件类似。只有当你清空的垃圾桶之后，它才被永久地删除。)