服務器與客戶端的數據同步

問題

• 從一個例子提及，咱們的客戶端從服務器獲取數據，這裏假定獲取文章。第一次使用，咱們獲取服務器端最新發表的幾篇文章。

• 咱們能夠每次都從新獲取，但這樣費時又費流量。好的設計應該是咱們把獲取過的文章存下來，下次只獲取最新發表的文章。

• 這樣就有個問題，若是某一篇文章，咱們已經獲取過了，可有一天它更新了。。。。

• 還有個問題，文章持續獲取下去，咱們手機沒空間了。。。。

• 如何使咱們客戶端能保存有限的文章，而且同時能夠獲得更新呢？

解決方法

• 爲了保證客戶端不存過多文章，咱們應該設置一個過時期限，當緩存的文章比較老舊，刪除掉便可。

• 爲了保證客戶端的文章可以獲得更新，服務器的文章表應該有個最後修改時間字段。同時服務器端保存客戶端最後一次獲取文章的時間，保存在session裏。

一、文章表設計

• | index | content | ts | dl |
• index 索引；
• content 內容；
• ts 文章最後一次的修改時間。把ts的格式設計爲：NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，即默認爲當前的時間戳，且隨着文章更改，自動更新爲更改時間。
• dl 文章是否被刪除了；

二、客戶端查詢文章時服務器端的工做

1. 從session中查詢該用戶對文章的最後一次獲取時間，last_gotten_ts；
2. 若是有該記錄，說明只須要給客戶端發送last_gotten_ts只後的文章（dl != 1 AND ts > last_gotten_ts）；
3. 若是沒有該記錄，表示是這個用戶第一次獲取，那發送最近的若干條文章（dl != 1 ORDER BY index DESC LIMIT 10）。
4. 將session裏的last_gotten_ts設置爲結果集裏最大的ts.

三、客戶端查詢到最新文章時的工做

1. 根據接收到的文章，新增或更新本地緩存。這裏使用REPLACE INTO更合適。同時，根據dl字段判斷是否已經被刪除，若是是，刪除本地的文章；
2. 刪除過時的緩存文章；
3. 展現文章列表，注意這裏應該以index，而不是ts排序。這樣保證文章是以建立時間排序，而非更新時間。

四、向前查詢

1. 這種狀況適用於上拉列表時加載更多文章的功能。目標是獲取某個文章以前的文章。所以客戶端請求時，應該帶着最後一條文章的index，服務器返回該index以前的若干文章。注意這時候，不該該存儲last_gotten_ts。

五、爲何將last_gotten_ts存到session而不是數據庫

1. 咱們也能夠新建一個表。相似這樣的結構： | user_index | last_gotten_ts | 可是這樣會有以下兩個問題：
2. 用戶在其它設備登陸了，這時候服務器會覺得是從老設備上請求的，只發送last_gotten_ts後的文章，致使兩個設備相互干擾。
3. 當客戶端好長時間沒有使用時，可能致使服務器這段時間累積的文章量比較大。而事實上當客戶端再次使用時，客戶端不必所有接受，只須要接收最新的若干文章（就像第一次使用時那樣）。
4. 使用session則能夠巧妙解決這兩個問題。
5. 兩個設備相互干擾，顯然不是咱們但願的。而session是跟設備相關的，在服務器端每一個設備有本身的session，這樣的話至關於每一個設備都相互獨立，能夠巧妙避開干擾。
6. 若是咱們把session的過時時間設置恰當，當客戶端再次使用時，舊session已通過期。新的session裏並無任何查詢歷史。正如客戶端第一次使用那樣。這樣就完美地解決了服務器端文章累積的問題。

六、客戶端的文章「斷層」

1. 當客戶端長時間不用，後面再使用時，由於沒有所有獲取，可能致使與緩存的老文章之間不連續，有「斷層」。這樣的話，若是用戶再想加載更多文章時，可能咱們的代碼會跳過這個斷層，直接加載老文章以前的文章。這樣的話這個「斷層」就沒機會獲取到了，丟失了。
2. 如何解決這個問題呢？其實很簡單，只要設置好客戶端本地的過時期限便可。客戶端每次啓動，都檢查是否是有緩存文章過時了，若是過時了，就刪除之。很明顯，這個時間期限不能大於服務器端的session的過時時間。

七、服務器端的文章的dl字段

1. 這個字段既然是刪除的意思，那爲何不直接刪除該記錄呢？這個字段的實質目的，是要告訴客戶端該記錄被刪除了。若是直接刪除了該記錄，客戶端無從得知這個刪除信息，那本地的緩存也就沒法刪掉。
2. 若是已經被刪了，還留在表裏，是否是不太好？的確很差。服務器按期檢查這些被刪記錄的刪除時間（ts）,若是超過必定期限了，那也刪除之。注意這個期限不能小於客戶端緩存的時間，即：保證在客戶端刪除了本地緩存記錄以後，再刪除該記錄。