根據時間戳，增量同步數據的解決辦法

因爲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種邏輯謬誤的瞭解，【轉】邏輯謬誤列表(序言)，在日常的生活中，說話作事，也就有了邏輯方面的意識；
• 間接可能得益於臺大哲學系苑舉正，苑老師講話的視頻。其實我很早之前，高中時候就喜歡哲學，《哲學的基本原理》這麼枯燥的書，我竟然認認真真仔仔細細的邊讀邊想的看了三四遍。只是那時好多徹底不懂，好多似懂非懂。十多年後雖然什麼都不記得了，可是好像又懂了。。。感受太玄了。。。