增量日志迭代同步和阿基里斯悖论

假设咱们有一套数据量庞大的前台系统须要从MySQL上转到Hbase上，比较粗糙的数据同步方法有：
一、将整个前台系统变为只读
二、全量dump MySQL数据
三、将MySQL数据导入到Hbase上
四、将前台系统切换到Hbase上，并打开更新
该方案比较简单，易于维持数据一致性，可是缺点是影响了全部用户的写入，而且时间过长。

用户体验看起来比较友好的数据同步方法有：
一、全量dump某个时间点以前的数据，并记录期间的增量日志A
二、apply日志A内的数据，并记录期间的增量日志B
三、apply日志B内的数据，并记录期间的增量日志C
四、不断重复第3步，直到日志C足够小
五、将整个前台系统变为只读，apply日志C内的数据
六、将前台系统切换到Hbase上，并打开更新
该方案实现比较复杂，迭代日志的作法看起来没完没了，并且容易引发少部分用户数据不一致。可是只读的时间很是短，大部分用户都能在数据同步期间自由使用应用。

简单归纳一下：
方案1：全部用户都会受到长时间的小影响（只读）
方案2：少部分用户会受到短期的大影响（数据不一致）

问题：
是否是牺牲小部分人来成全大部分人就是对的？
在这个问题上，德先生（democracy）是否是最终答案？

这个问题我没有想到答案，
可是针对迭代日志是否是没完没了的疑问，阿基里斯悖论给了我一点线索：
阿基里斯是一个跑得很快的神话人物，芝诺提出“假如乌龟领先阿基里斯1000米，则阿基里斯永远不可能追上乌龟”。这个结论的推理过程是这样的：
一、乌龟领先阿基里斯1000米
二、阿基里斯追了1000米
三、乌龟前进了100米（假设乌龟速度是阿基里斯的十分之一）
四、阿基里斯追了100米
五、乌龟前进了10米
。。。
六、阿基里斯追了n米
七、乌龟前进了n/10米
。。。
八、阿基里斯无限逼近乌龟，可是永远不可能追上

阿基里斯真的追不上乌龟？固然不可能：
1000*(1+0.1+0.01+…)=1000*(1+1/9)=10000/9
在10000/9米处，阿基里斯就会和乌龟并驾齐驱，而后超越。

回到增量日志迭代同步的问题。咱们在什么前提下，能够认为迭代可终止：
一、日志apply无停顿（阿基里斯一直在跑）
若是apply完一段日志，不是立刻去aply新产生的增量日志，那么迭代极可能没法终止
二、日志apply速度大于增量日志生成速度（阿基里斯要跑得比乌龟快）
这个比较显而易见。若是不是这样，日志只会越积越多，不可能apply完成

这是个人一些见解。在不影响用户的前提下，但愿之后可以实现完美的数据迁移，呵呵。

原文地址：http://www.taobaodba.com/html/564_%E5%A2%9E%E9%87%8F%E6%97%A5%E5%BF%97%E8%BF%AD%E4%BB%A3%E5%90%8C%E6%AD%A5%E5%92%8C%E9%98%BF%E5%9F%BA%E9%87%8C%E6%96%AF%E6%82%96%E8%AE%BA.html