基于文件的离线数据同步方案

转自：http://blog.csdn.net/kyfxbl/article/details/43457625

产品此前的数据备份方案，存在不少问题，所以需要设计一个新的方案。本文总结一下新旧方案的优劣

首先APP是一个支持离线的应用。本地数据保存在sqlite，在离线环境下，在本地数据库里读写记录，在有网络的时候，再将数据备份到服务器；同时，也可以随时将数据从服务器恢复到本地

旧方案

此前的备份方案是基于内容的，每一条记录都有create_date和modify_date字段，同时APP保存有latest_backup_date（上次备份时间）。然后开始备份的时候，就对所有表进行扫描，根据这3个时间的对比，直接生成sql语句，发到服务器执行，写入服务端的mysql数据库；收到服务器的成功响应之后，又刷新latest_backup_date

而恢复逻辑，则是从服务器的mysql数据库里，遍历找到所有的记录，也生成sql语句，发回客户端，客户端再执行sql进行恢复。当发生冲突的时候，以客户端的数据为准，违反主键约束的时候，插入数据就会失败。比如客户端将一个卖品的价格改为200，而服务器mysql里的记录还是100，那么下发的insert语句就无法执行

这个方案有几个问题：

1、客户端的备份逻辑，散落在业务模块里，因为涉及到业务操作的地方，都需要记得修改modify_date和create_date，容易造成数据备份不上去的BUG

2、备份逻辑依赖客户端本地时间，而客户端时间总是不可靠的

3、服务端缺少客户端数据库的完整镜像，也就是说，一旦有BUG导致部分数据没有备份上来，那么如果用户卸载了APP或者PAD丢失，这部分数据就永远找不回来了

4、生成恢复文件之前，需要遍历mysql表，数据量大的时候，容易使客户端超时而恢复失败

5、恢复逻辑以客户端数据为准，在某些场景下不满足需求，比如做不到在服务端对客户端的数据进行干预校正

6、sql是纯文本，当数据量大的时候，在网络间传输的数据太多

新方案

新的方案准备这样做：备份和恢复不再基于内容，而是基于文件。每次备份都把本地的数据库文件上传到服务器。但是在传输上有特别处理，只传文件的差量；在服务器利用差量文件，合并得到完整的客户端数据库文件副本。同时在数据库增加一个差量表，配合trigger，将每次的insert，update，delete操作，写到差量表中。在服务器遍历差量表，将有变化的数据写到mysql里

恢复的时候，就直接把数据库文件发到客户端，替换掉客户端的数据库文件

在这个过程中，当然需要在服务端增加专门的表，来控制整个流程，比如记录文件在OSS里的路径，最后备份的时间等，本文不展开

这个方案相比老方案的优势：

1、客户端业务代码不再需要关注数据同步的逻辑，减少了出错的机会

2、不依赖客户端时间

3、服务端始终有客户端数据库的完整镜像，即使有BUG，也只是没有写到mysql里，对汇总统计有影响，但是不会造成客户端数据直接丢失

4、恢复文件不需要每次生成，速度快

5、可以在服务端直接修改数据库文件，校正客户端的错误；版本升级时如果需要做数据迁移，也可以在服务端统一处理

6、由于每次备份的差异量小，生成的差量文件也很小，需要在网络间传输的文件一般也比较小

新方案的局限性

总的来说，新方案的优势比较明显。但是，这个方案也只能解决单个客户端操作的场景，对于多终端同时操作就无能为力了。比如说，2个PAD同时修改一个会员的余额，那先备份的那条数据将会被覆盖，造成数据错误。所以，还需要保证同时只有一个终端操作数据，这样才能放心地替换文件。因为这种场景下，是不存在数据冲突的

如果要支持离线环境下，多终端同时操作的场景，则还需要在这个方案的基础上更进一步，识别出终端差异，将各终端的数据merge到中心文件，此外还需要保证文件合并的先后顺序等。这种场景比单客户端的场景要复杂很多，不在本文讨论范围，有空单独再写