根据时间戳，增量同步数据的解决办法

因为markdown的样式太丑了，懒得再调整了，我另外再贴一个github的博客该文的 github连接

前言

最近在工做中遇到一个比较棘手的问题，客户端从服务端同步数据的问题。
背景简介：客户端有N个，客户端上的同步时间，各不相同。同步的时候，是一次获取10条数据，多批次获取。即分页获取。
在代码中存在两种同步的方式：

1. 全量同步。同步过程是从服务端拉取所有的数据；依赖具备惟一约束的ID来实现同步。只适用于数据量小的表，浪费网络流量。
2. 增量同步。从服务器拉取大于客户端最新时间的数据；依赖于时间戳，问题时间戳不惟一存在相同时间点下面多条数据，会出现数据遗漏，也会重复拉取数据，浪费网络流量。

本文的所使用到的解决办法，就是结合了惟一ID和时间戳，两个入参来作增量同步。本文也只作逻辑层面的说明。

模拟场景

表结构：ID 具备惟一约束， Name 姓名， UpdateTime 更新时间；如今问题的关键是ID为3，4，这两条时间点相同的数据。
假如一次只能同步一条数据，如何同步完ID 2后，再同步 ID 3。

ID	Name	UpdateTime
1	张三	2018-11-10
2	李四	2018-12-10
3	王五	2018-12-10
4	赵六	2018-11-20
5	金七	2018-11-30

解决思路

生成新的惟一标识

经过 UpdateTime 和 ID 这两种数据，经过某种运算，生成新的数。而这个新的数具有可排序和惟一；同时还要携带有ID和UpdateTime的信息。
简单表述就是，具备一个函数f： f(可排序A，可排序惟一B) = 可排序惟一C 。 C 的惟一解是 A和B。RSA加密算法

我想出了一个方法，也是生活中比较经常使用的方法：

1. 先把 UpdateTime 转变成数字。如： 字符串 2018-12-10 -> 数字 20181210;
   
2. 而后 UpdateTime 乘以权重，这个权重必须大于ID的可能最大值。如： 20181210 * 100 = 2018121000，Max(ID)<999
   
3. 而后再把第二部的结果，加上惟一键ID。如： 2018121000 + 3 = 2018121003。

这个时候，2018121003 这个数，既包含了UpdateTime和ID的信息，又具备可排序和惟一性。用它做为增量更新的判断点，是再好不过的了。
可是它具备很大的缺点：数字太大了，时间转化成数字，目前仍是用的是天级别，若是换成毫秒级别呢。还有ID可能的最大值也够大了，若是是int64那就更没得搞了。

这个方法理论上可行，实际中不可用基本不可行，除非找到一种很是好的函数f；
PS: 个人直觉告诉我： 很可能存在这种函数，既知足个人须要，又能够克服数字很大这个问题。只是我目前不知道。

数据库表修改(不推荐)

修改数据内容

修改数据内容，使 UpdateTime 数据值惟一。缺点也比较明显：

1. 脚本操做数据的状况下，或者直接sql更新。可能会，形成时间不惟一；
2. 只是适用在数据量小，系统操做频率小的状况下。由于毫秒级别的时间，在绝大多数软件系统中，能够认为是惟一；
3. 尤为是老旧项目，历史遗留数据如何处理。

增长字段

还有一种办法，就是在数据库中，增长一个新的字段，专门用来同步数据的时候使用。
比方说，增长字段 SyncData int 类型。若是 UpdateTime 发生了改变，就把它更新为 SyncData = Max(SyncData) + 1;
也就是说， SyncData 这个字段的最大值必定是最新的数据，SyncData的降序就是 更新时间的降序。SyncData是更新时间顺序的充分没必要要条件。

总的来讲，这种办法是比较好的，但缺点也比较明显：

1. 须要修改表结构，而且额外维护这个字段；
   
2. 新增或者更新的时候，会先锁表，找出这个表的最大值，再更新，资源浪费明显。
   
3. 若是表的数据量比较大，或者更新比较频繁时候。时间消耗较大。

个人解决方法

分页提取数据的可能状况

首先，先来分析一下，一次提取10条数据，提取的数据，存在的可能状况。再次说明前提，先时间倒序，再ID倒序。Order By UpdateTime DESC, ID DESC
可能状况以下图，能够简化为三种：

1. 情景1。当前获取的数据中包含了，全部相同时间点的数据；图1，图5
   
2. 情景2。当前获取的数据中包含了，部分相同时间点的数据；图2，图3，图4，图6，图7
   
3. 情景3。当前获取的数据中包含了，没有相同时间点的数据；图···

其中情景1和情景3，能够把查询条件变为：WHERE UpdateTime > sync_time LIMIT 10
可是情景2的状况不能使用大于>这个条件。假如使用了大于>这个条件，情景2就会变成情景1或情景3或图3这种状况。不是包含部分了，须要额外特别处理。
注：图3的结束点 ]不重要，下面情景5有解释。

情景2部分状况，提取的起始点

提取的起始点：也就是说图中[左中括号的位置，须要准肯定位这个位置。
至于结束点：图中]右中括号的位置是在哪里。这个就不重要了，由于下一次的分页提取的起始点，就是上一次的结束点。只须要关注起始点就足够了。

而根据起始点，又能够把情景2，再作一次简化：

1. 情景4。起始点在相同时间点集合内的；图2，图4，图6，图7
2. 情景5。起始点不在相同时间点集合内的；图3，

针对情景4。这个时候，时间戳sync_time一个入参就不够了，还额外须要惟一键ID来准肯定位。能够把查询写做：WHERE UpdateTime = sync_time AND ID > sync_id LIMIT 10。
若是查询的行数 等于 10，则是图4；小于 10，则是图2，图6，图7的状况。

针对情景5。依旧可使用：WHERE UpdateTime > sync_time LIMIT 10

完整的分页过程

完整的分页过程的步骤：
1、先用起始点来过滤：WHERE UpdateTime = sync_time AND ID > sync_id LIMIT 10，查询结果行数N。若是 N=10是图4的状况，则结束，而且直接返回结果。若是 0<= N <10 ，则进行第二步，其中N=0是图1，图3，图5，图···的状况；

2、再用时间戳查询：WHERE UpdateTime > sync_time LIMIT 10-N，查询结果行数 M ，0<= M <=10-N；这个阶段，是否同一个时间点都不重要了。只须要按着顺序取已排序的数据就能够了；

3、把一和二的结果集合并，一并返回。

4、重复步骤一二三，直到，分页获取的最后一条数据的ID，是服务端数据库中最新的ID；(防止存在，刚好这十条是所须要获取的最后十条)。

服务端中最新ID获取：Select Id From myTable Order by UpdateTime desc,ID desc Limit 1;

经验总结

寻找关键信息，以及具备指标意义的数据，或者数据的组合。

• 最开始，我只执着于 UpdateTime 这个数据，甚至提出去数据库中，修改历史数据，再把 UpdateTime 加上惟一约束(之前也没有据说过在 UpdateTime 这个字段上面加惟一约束)。而且这种办法，局限性有很强，不能够通用。
  
• 主键ID惟一，可是它不具备时间属性。只适用于所有更新。
  
• 把他们两个结合起来，才算是打开了新的思路。

拆分问题，简化问题

• 把 UpdateTime 和 ID 组合使用时。妄图在一个sql里面来实现。发现不管怎么改，都会存在逻辑上面的问题；
• 没有拆分化简的时候，若是用存储过程来写的话，会很是很是复杂；
• 直到，我在脑壳里面，模拟出来可能的状况后。也就是上面的图片同步数据的可能性，慢慢归类，简化后；才发现。问题没有那么难，仅仅是起始点这一个小小的问题。

使用逻辑分析和哲学概括

• 在分析数据的意义和性质的时候，偶然间使用到了概括的方法；也就是惟一和可排序；跳出了具体字段，使用场景的框架束缚，而去考虑这两种性质怎么结合的问题；
• 在逻辑分析的时候，先用排列组合，算出多少种可能性；在脑中勾画出图形，把性质相同的可能性合并化简；
• 在化简的过程当中，不要仅仅着眼于查询的对象，也要去化简查询的方法；有点绕，打个比方，既要优化最终产品，也要去优化制做工艺；

最后，我认为我最近的逻辑分析能力，好像有比较大的提高。

• 直接得益于，常见的24种逻辑谬误的了解，【转】逻辑谬误列表(序言)，在日常的生活中，说话作事，也就有了逻辑方面的意识；
• 间接可能得益于台大哲学系苑举正，苑老师讲话的视频。其实我很早之前，高中时候就喜欢哲学，《哲学的基本原理》这么枯燥的书，我竟然认认真真仔仔细细的边读边想的看了三四遍。只是那时好多彻底不懂，好多似懂非懂。十多年后虽然什么都不记得了，可是好像又懂了。。。感受太玄了。。。