全量与增量
一、数据同步：全量与增量
1.背景
数据如果保留多份，就会存在一致性问题，就需要同步，同步分为两大类：全量和增量
- 概述
数据如果要保留副本，要么同时写（就是多写），或者进行复制：异步写（即从主数据拷贝到副本）；
同时写（多写），引出一个问题，写多少节点算成功（场景：分布式系统）？全部写成功才算成功，还是写大多数成功算成功，还是写指定几个节点算成功？
异步写的话，如果采用异步复制，那么实时性需要考量的话，就需要采用性能优先的架构。
3.同步方式
数据同步一般分为两种方式：全量和增量。
3.1 全量
全量，这个很好理解。就是每天定时（避开业务高峰期）或者周期性全量把数据从一个地方拷贝到另外一个地方；
全量的话，可以采用直接全部覆盖（使用“新”数据覆盖“旧”数据）；或者走更新逻辑（覆盖前判断下，如果新旧不一致，就更新）；
这里面有一个隐藏的问题：如果采用异步写，主数据物理删除了，怎么直接通过全量数据同步？这就需要借助一些中间操作日志文件，或者其他手段，把这些“看不到”的数据记录起来。
3.2 增量
增量的基础是全量，就是你要使用某种方式先把全量数据拷贝过来，然后再采用增量方式同步更新。
增量的话，就是指抓取某个时刻（更新时间）或者检查点（checkpoint）以后的数据来同步，不是无规律的全量同步。这里引入一个关键性的前提：副本一端要记录或者知道（通过查询更新日志或者订阅更新）哪些更新了。
3.2.1 确定更新点
采用更新时间戳、有的采用checkpoint等来标识和记录更新点。
二、能用全量别用增量
两个系统之间需要同步数据，同步的方法可以分为全量和增量两种形式。多年的经验告诉我，能用全量就别用增量。增量有三个问题
数据提供方，很难制作增量包，事无巨细都要记录，稍微记错就全完了
数据接收方，理解并且实施增量包的逻辑比较复杂
中间过程一旦出了问题，很难定位
这里为了方便讨论，假设有两个系统，其中系统A拥有全深圳所有纳税人的当月工资，系统B需要从系统A同步这个数据。对于系统A来说，它的数据在不停的变化，但是可以分成三类
新增，比如说有毕业生来深圳打工
删除，比如说有人离职离开深圳了
变化，比如说有人涨工资了
这个时候，同步数据的方法很难决策，全量同步不合适，数据量太大而且还不值当，毕竟变化的部分比较少。增量同步又怕麻烦，一旦某次同步出问题，很难倒查故障和恢复。
其实，可以有一种折中方案，上不了台面，但是值得尝试。为了方便理解，还是以上面的例子来讨论。
我们知道所有人都有身份证号码，其中有一部分为年月日，表示生日。我们按照生日，在系统A将数据进行分组，这个分组是逻辑上的，不是真实的。如果有个人，工资涨了，生日为1999.9.1，那么系统A就记录分组1999.9.1的数据发生了变化。假设两个系统之间的同步周期是每天同步一次，那么系统A只需要整理这段时间那些分组发生了变化，但是不用记录变化的实际内容。系统B就老老实实将发生变化的分组数据删掉，然后全量同步这些分组的数据。
这个方案，就是赌每天发生变更的数据不会那么巧，波及所有分组，只会有很小的一部分分组发生变化。这样从整体看，只是同步了部分数据，从分组看又是简单的全量同步。这个方案的巧妙之处就是选择合适的分组标准，既要分的足够细，又要足够直接，方便程序处理。
三、数据全量同步有可能造成的严重问题–血的教训
数据同步在垮产品或者垮系统之间是经常用到的，且经常是不得不用的；这种地方是最容易产生
问题的地方，一般也是最恶心的地方；
数据同步有两种方式，一种是增量的同步，一种是全量的同步；两种方式各个各的好处，也各个各
的问题；增量同步，主要是生产方和接收方生成和处理数据逻辑都不会很简单，时间一长，很容易造成数据
的不一致；全量同步一般不会造成数据的不一致情况，但随着数据量的增大，全量数据到最后往往会非常大
造成生成和处理都有点不太可能；
上述这几条在数据同步中基本都考虑到了，也遇到过n次，也不得不容忍，修正之类的；但前些天
发生的一件事情使我对“全量数据同步”这一方法产生了极大的恐惧感；
全量数据同步的好处是生产方和消费方逻辑都比较简单，就是每天在某固定时刻重新生成所有的数据
不像增量那样要处理有可能非常复杂的增量逻辑；但是：正因为是重新生成，所以全量数据的准确性特别是
全面性变得非常非常重要，说白了就是全量数据如果因为某种原因导致丢失了部分甚至大部分数据，造成的
后果是非常严重非常严重的；比如：白名单问题，如果白名单是以全量数据过去的，假设某天这一同步出了
问题，产生了一个空的白名单，完蛋了，消费方看到了一个空白名单…
数据同步其实是非常容易出问题的，比如：生产方和消费方的时间点问题，rsync问题等等；如果又
刚好采用全量同步，一旦某天出问题，导致的结果有可能是灾难性的！！
怎么防止或者监控呢？需要生产方特别是消费方对全量数据进行一个检验，如果发现全量数据异常
最好立即停下处理，然后发邮件报警，然后人工干预处理；至于怎样的检测，最简单的检测方法就是：检查
数据的数量，如果发现数量明显异常（太少或者太多）之类…