数据同步两种方式

背景

如果数据要存储多份的时候，为了保证数据的准备性，我们需要保证数据更新的同步性

同步方式

1.全量同步：就是每天定时（避开业务高峰期）或者周期性全部把数据从一个地方拷贝到另一地方。（全部的数据）

2.增量同步：只需要去同步那些改动过，需要跟新的数据。增量的基础是全量，首先需要将全量数据拷贝过来，然后再采用增量方式同步更新。增量会抓取某个时刻（更新时间）或者检查点（checkpoint）以后的数据来同步。这里有个关键性的前提：副本一端要记录或知道（通过查询更新日志或者订阅更新）哪些数据更新了

各自的优缺点

增量：生成和接受方生成和处理数据逻辑复杂，时间一长容易造成数据不一致问题

  1⃣️数据提供方，制作增量包很麻烦，所有的改动都要记录，稍微记错就全部完了

  2⃣️数据接收方，更加增量包来实施更新的逻辑比较麻烦

  3⃣️中间过程出现问题是很难定位的

全量：

  1⃣️数据量太大，没有改动的数据也要同步

  2⃣️生成方和消费方的逻辑比较简单，固定某一时刻导出重新生成所有的数据。于是对于全面性和准确方面需要很高的要求。

  例如：使用全量的方式同步白名单，但是某天数据同步时，丢失了数据，那么这个系统或者数据会产生崩溃的现象。那么如何防止或者检查这种现象？

  通过生产方特别是消费方对全量数据做一个检查，如果发现数据异常，则立马停止同步，并检查。最简单的方法就是检查：数据处理的数量（太多或者太少）

例子

这里为了方便讨论，假设有两个系统，其中系统A拥有全深圳所有纳税人的当月工资，系统B需要从系统A同步这个数据。对于系统A来说，它的数据在不停的变化，但是可以分成三类

1. 新增，比如说有毕业生来深圳打工

1. 删除，比如说有人离职离开深圳了

1. 变化，比如说有人涨工资了

这个时候，同步数据的方法很难决策，全量同步不合适，数据量太大而且还不值当，毕竟变化的部分比较少。增量同步又怕麻烦，一旦某次同步出问题，很难倒查故障和恢复。

其实，可以有一种折中方案，上不了台面，但是值得尝试。为了方便理解，还是以上面的例子来讨论。

我们知道所有人都有身份证号码，其中有一部分为年月日，表示生日。我们按照生日，在系统A将数据进行分组，这个分组是逻辑上的，不是真实的。如果有个人，工资涨了，生日为1999.9.1，那么系统A就记录分组1999.9.1的数据发生了变化。假设两个系统之间的同步周期是每天同步一次，那么系统A只需要整理这段时间那些分组发生了变化，但是不用记录变化的实际内容。系统B就老老实实将发生变化的分组数据删掉，然后全量同步这些分组的数据。

这个方案，就是赌每天发生变更的数据不会那么巧，波及所有分组，只会有很小的一部分分组发生变化。这样从整体看，只是同步了部分数据，从分组看又是简单的全量同步。这个方案的巧妙之处就是选择合适的分组标准，既要分的足够细，又要足够直接，方便程序处理。