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

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

首先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到中心文件,此外还需要保证文件合并的先后顺序等。这种场景比单客户端的场景要复杂很多,不在本文讨论范围,有空单独再写

你可能感兴趣的:(基于文件的离线数据同步方案)