场景
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现有的备份逻辑，所以最后还是决定採用第一种方案。新开发的系统，建议採用另外一种方案