生产中的数据同步问题

目前在维护一个搜索服务。在做数据同步的时候有遇到数据同步的问题，该问题的描述大概如下：

有一个处理服务A，会定时重建一份用于搜索的索引数据。例如每天凌晨0点开始，从一个全量数据文件接口，获取全量文件，我们假设这份全量文件是时间点1生成的。

0点开始处理全量数据，然后写一份新的索引数据，因为这份数据时间点1生成的，但是我们生成完全量数据的索引已经到了时间点2，所以肯定需要追回增量才能保证数据的完整性，所以我们调用了增量接口，一次获取从时间点1到时间点2的增量，并把增量更新也写到索引数据中，然后做一个索引切换，用新的索引切换旧的，线上搜索继续用新索引搜索，然后实时的变更到新的索引，完成。

perfect。。but。。

问题就在看上去很完美的情况下出现了。待我描述一下时间轴和线上、正在处理的索引的情况就大概知道问题在哪了。

可以看到在最后切换的时候，这个alias2020...的这个索引相对于线上的索引，因为下载增量需要时间、更新增量需要时间，索引优化切换别名需要时间，已经缺少了时间点T2到切换时间点T5的数据变更。

生产中发现了这个问题，怎么办？解决。。然后有了解决方案1：在时间点T5之后，再拉取一次时间点T1到T5的增量，覆盖之，这样就解决了T2到T5增量丢失的问题，解决如下：

这样加上阿里山20200730...这个索引在T5开始之后的实施变更，就保证了数据的完整连续。

然而问题继续出现了，看了上面流程的同学肯定已经意识到了：那就是时序问题。T1-T6时间段的增量，如果在T6-T7也发生了实时变更，那么写入到alias20200730...的数据会被T1-T6的数据覆盖。所以继续解决该问题：从T6时刻开始记录下实施变更的key，一直到T1-T6的数据变更结束为知。这段时间内的key，在T1-T6数据变更期间，不会被更新。

问题解决了。真是一波三折。

也和开始没考虑周全有关系。