Open 6174 opened 8 years ago
原文: https://www.objc.io/issues/10-syncing-data/data-synchronization/ 关于
原文: https://www.objc.io/issues/10-syncing-data/data-synchronization/
这里的数据同步的问题描述的是-多个不同的端存储相同的数据,并需要保证数据的同步。 这在现实开发中实在是个令人头疼的难题, 参考原文在理解的基础上做了修改和调整
本文想借此展开相关的理论和实例来深入研究一下数据同步问题。
同步客户端服务器 (Synchronous Client-Server, S-CS) 应用直接和远程服务通讯,将数据同步
实例:微信发送一条消息,只有消息发送完成过后才会存储在本地消息发送成功列表中,未发送成功会提示重新发送
异步客户端服务器 (Asynchronous Client-Server, A-CS) 应用将数据保存在本地,应用保持本地数据和远程数据的同步(后台运行)
实例:Mac QuickTime 录制了一段视频,存储在文件系统中,iCoud 自动将文件系统中的数据同步到云端
异步对等方式 (Asynchronous Peer-to-Peer, A-P2P) 应用数据保存在本地,应用保持本地数据和其他端的数据同步, 每个端存储数据的完成备份,服务器端不存在备份。
识别 对象识别需要使用全局标识符 uuids (universaaly Unique identifiers)
uuids
变化追踪 描述算法如何确定自上一次数据同步后, 数据发生了哪些变化, 然后本地存储应该如何修改。
颗粒大小
记录变化
软删除
当多端都在共同修改一个实例的时候,就会出现冲突。
假设我们有一个像 iTunes 那样的 Mac 应用程序,它可以通过 USB、蓝牙或者 Wi-Fi 和 iPhone 进行同步通讯。(凭借快速的本地网络,我们不用太在意限制数据传输大小)
总结来说,同步操作需要设备能够向其他设备传输数据,并且能够决定哪些被修改、合并,然后回传更新后的数据。 保证了这两个设备同步之后具有相同的数据,所以,有很强的健壮性。
当加入了服务器的时候,服务器是为了能够更加灵活地同步数据,但是它是以数据传输和存储为代价的。 需要尽可能地减少通讯开销,所以来回地拷贝整个数据是不可行的。
也许有很多不同的方法。比如,你可以为每一个属性引入一个时间戳,然后在属性粒度级去追踪变化。或者你可以在客户端合并所有的数据,然后将合并后的结果发回给服务器,这实际上是互换了角色。但是,基本说来,一个设备发送修改结果给其他设备,然后接收方合并并回发合并后的结果。
删除需要考虑更多。因为一旦删除了一个对象,就不可能跟踪它了。一种选择是使用 软删除 ,也就是对象并不是被真正的删除,而是标记为删除 (比如使用一个 Boolean 属性)。 (这和在 Finder 中删除一个文件类似。只有当你清空的垃圾桶之后,它才被永久地删除。)
异步的数据同步框架和服务的吸引力在于它们提供了现成的解决方案。 S-CS 模式是要定制的,也就是说得为不同的应用程序以及不同的平台编写不同的代码。
异步服务 (比如, Dropbox Datastore API 和 Wasabi Sync) 通常提供框架,让应用程序开发者用起来好像是本地数据存储。这些框架在本地保存修改,然后在后台控制与服务器的同步。
A-CS 和 S-CS 的一个最主要的区别在于,A-CS 框架额外提供的抽象层,屏蔽了直接参与同步的客户端代码。这也意味着,同一服务可以用于所有的数据模型,而不是特定的一种模型。
数据同步
这里的数据同步的问题描述的是-多个不同的端存储相同的数据,并需要保证数据的同步。 这在现实开发中实在是个令人头疼的难题, 参考原文在理解的基础上做了修改和调整
本文想借此展开相关的理论和实例来深入研究一下数据同步问题。
数据同步理论
同步方式
同步客户端服务器 (Synchronous Client-Server, S-CS) 应用直接和远程服务通讯,将数据同步
实例:微信发送一条消息,只有消息发送完成过后才会存储在本地消息发送成功列表中,未发送成功会提示重新发送
异步客户端服务器 (Asynchronous Client-Server, A-CS) 应用将数据保存在本地,应用保持本地数据和远程数据的同步(后台运行)
实例:Mac QuickTime 录制了一段视频,存储在文件系统中,iCoud 自动将文件系统中的数据同步到云端
异步对等方式 (Asynchronous Peer-to-Peer, A-P2P) 应用数据保存在本地,应用保持本地数据和其他端的数据同步, 每个端存储数据的完成备份,服务器端不存在备份。
数据同步要素
识别 对象识别需要使用全局标识符
uuids
(universaaly Unique identifiers)变化追踪 描述算法如何确定自上一次数据同步后, 数据发生了哪些变化, 然后本地存储应该如何修改。
颗粒大小
: 当某个属性字段被修改过后,确定追踪这个字段还是追踪整个实例记录变化
: 是否变化简单情况可以用一个 Boolean 的标示来表示, 也可能需要用日志来记录变化并附加时间戳软删除
: 冲突解决当多端都在共同修改一个实例的时候,就会出现冲突。
对等同步通讯(S-P2P)
假设我们有一个像 iTunes 那样的 Mac 应用程序,它可以通过 USB、蓝牙或者 Wi-Fi 和 iPhone 进行同步通讯。(凭借快速的本地网络,我们不用太在意限制数据传输大小)
总结来说,同步操作需要设备能够向其他设备传输数据,并且能够决定哪些被修改、合并,然后回传更新后的数据。 保证了这两个设备同步之后具有相同的数据,所以,有很强的健壮性。
客户端-服务器同步通讯(S-CS)
当加入了服务器的时候,服务器是为了能够更加灵活地同步数据,但是它是以数据传输和存储为代价的。 需要尽可能地减少通讯开销,所以来回地拷贝整个数据是不可行的。
也许有很多不同的方法。比如,你可以为每一个属性引入一个时间戳,然后在属性粒度级去追踪变化。或者你可以在客户端合并所有的数据,然后将合并后的结果发回给服务器,这实际上是互换了角色。但是,基本说来,一个设备发送修改结果给其他设备,然后接收方合并并回发合并后的结果。
删除需要考虑更多。因为一旦删除了一个对象,就不可能跟踪它了。一种选择是使用 软删除 ,也就是对象并不是被真正的删除,而是标记为删除 (比如使用一个 Boolean 属性)。 (这和在 Finder 中删除一个文件类似。只有当你清空的垃圾桶之后,它才被永久地删除。)
客户端-服务器异步通讯 (A-CS)
异步的数据同步框架和服务的吸引力在于它们提供了现成的解决方案。 S-CS 模式是要定制的,也就是说得为不同的应用程序以及不同的平台编写不同的代码。
异步服务 (比如, Dropbox Datastore API 和 Wasabi Sync) 通常提供框架,让应用程序开发者用起来好像是本地数据存储。这些框架在本地保存修改,然后在后台控制与服务器的同步。
A-CS 和 S-CS 的一个最主要的区别在于,A-CS 框架额外提供的抽象层,屏蔽了直接参与同步的客户端代码。这也意味着,同一服务可以用于所有的数据模型,而不是特定的一种模型。
数据同步实例
@todo