增量日誌迭代同步和阿基里斯悖論

假設咱們有一套數據量龐大的前臺系統須要從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完成

這是個人一些見解。在不影響用戶的前提下，但願之後可以實現完美的數據遷移，呵呵。