一种client同步server数据的方案
2017-05-18 20:14
239 查看
场景
clientA不定时地把本地数据同步到server上,然后还有一个clientB(app)从server把数据同步下来,汇总展示clientA数据结构
原始的数据(来自clientA)。每条都有create_time和modify_time,用于表示这条记录的创建时间和改动时间。同一时候系统里还有latest_backup_time字段,用来表示上次备份的时间。client每次备份。都会以这3个字段作为条件,找出须要备份的数据,上传到server服务端数据结构
因为历史遗留问题,服务端收到备份数据之后,没有做其它的处理。而是直接写入数据库clientB同步逻辑
clientB有latest_sync_time字段,用于表示最后一次从server同步的时间。这个字段是每次同步之后,服务端确定并返回的。client把这个时间戳记下来。请求同步时,再带上这个时间戳。
然后服务端就以create_time。modify_time,latest_sync_time这3个字段作为条件,找出须要下发的数据,返回clientB
查询哪些数据须要下发的逻辑是:
这个方法的关键是。怎样确定latest_sync_time。因为create_time和modify_time都是clientA的本地时间。服务端也没有字段表示服务端入库的时间,所以服务端返回latest_sync_time到clientB的时候,不能用server接收到同步请求的时间,而要用本次查询到的数据中。最后的create_time或modify_time
其它方案
上面这个方法主要在确定latest_sync_time的时候比較麻烦。根源在于服务端入库的时候,没有把入库的服务端时间保存下来。假设在服务端有sync_time,那么比較起来就非常easy,仅仅要找到sync_time在latest_sync_time和now之间的数据就能够了。这些数据就是从上次同步到当前时刻的新数据,然后仅仅要把当前的时间,放在响应里一起返回client。client刷新latest_sync_time即可了另外,上面这个方法把推断insert和update的逻辑也放在了服务端。
事实上服务端也能够把满足的数据直接发回clientB,然后在client推断id是否存在。就能够确定该数据是新增的。还是须要update的
这个方法感觉会更简单。并且因为sync_time是由服务端控制的,也能够避免因为clientA修改本地系统时间引起的逻辑错误。应该是一个更优的方案。
可是因为如今server里已经存在没有记录sync_time的历史数据。迁移起来比較麻烦,并且这样的方案也须要修改server现有的备份逻辑,所以最后还是决定採用第一种方案。新开发的系统,建议採用另外一种方案
相关文章推荐
- 一种客户端同步server数据的方案
- Redis改造,一种异构系统Redis的数据同步方案实现
- Client:TSocketConnection 和Server: Scktsrvr关系----压缩数据传输方案
- linux和windows同步数据 cwrsync client to rsync server
- Silverlight Client←→Server数据同步备忘代码
- Client:TSocketConnection 和Server: Scktsrvr关系----压缩数据传输方案
- Sql Server 2005 与Sql Server Mobile(Sql server 2005 mobile Edition)数据同步步骤以及问题解决方案
- 分布式数据库数据从属与client与server的数据同步
- Client:TSocketConnection 和Server: Scktsrvr关系----压缩数据传输方案
- 多Client同步Server端数据
- linux和windows同步数据 cwrsync client to rsync server
- 两地业务系统数据实时同步方案
- OracleDataguard数据同步复制的容灾技术方案
- 一种分布式数据库同步方案
- ISCSI+单机同步软件构成局域网数据备份方案
- ISCSI+单机同步软件构成局域网数据备份方案
- ipad 无法同步 问题修复的一种方案
- Client:TSocketConnection 和Server: Scktsrvr关系----压缩数据传输
- SQL Server Compact Edition 与SQL Server 2005数据同步之请求和推送
- ASP.NET+SQL Server 网站的数据备份的一种方法