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

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

转自： 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

April 21st, 2011陶方Leave a commentGo to comments

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

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

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

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

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

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

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

这是我的一些看法。在不影响用户的前提下，希望以后能够实现完美的数据迁移，呵呵。