數據同步方法、裝置和系統與流程

2023-04-23 23:22:07

本申請涉及數據處理技術領域，尤其涉及一種數據同步方法、裝置和系統。

背景技術：

客戶端從服務端獲取數據的過程中，如果數據量比較大，會嚴重影響客戶端的執行效率。為了解決這個問題，可以把服務端的數據放到客戶端本地，當客戶端需要讀取數據的時候，可以直接從本地讀取。

數據放到了客戶端本地後，會涉及到客戶端的數據更新的問題，傳統的更新方式是直接以整體覆蓋更新的方式重新去服務端整體獲取數據，然後刪除老數據，存儲新數據，這樣在觸發時機上，通常會採用時間維度或者存儲維度等作為觸發條件去服務端更新數據。

但是，這種在觸發時機上整體覆蓋更新的方式，會存在滯後性，並且更新效率差。

技術實現要素：

本申請旨在至少在一定程度上解決相關技術中的技術問題之一。

為此，本申請的一個目的在於提出一種數據同步方法，該方法可以提高數據更新的實時性，並提高更新效率。

本申請的另一個目的在於提出一種數據同步裝置。

本申請的另一個目的在於提出一種數據同步系統。

為達到上述目的，本申請第一方面實施例提出的數據同步方法，包括：獲知數據發生變更；在數據發生變更時，生成用於記錄數據變更情況的更新日誌；將所述更新日誌發送給客戶端，以使所述客戶端根據所述更新日誌更新發生變更的本地數據。

本申請第一方面實施例提出的數據同步方法，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

為達到上述目的，本申請第二方面實施例提出的數據同步方法，包括：接收服務端發送的更新日誌，所述更新日誌是所述服務端在獲知數據發生變更時發送的；根據所述更新日誌更新發生變更的本地數據。

本申請第二方面實施例提出的數據同步方法，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

為達到上述目的，本申請第三方面實施例提出的數據同步裝置，包括：獲知模塊，用於獲知數據發生變更；生成模塊，用於在數據發生變更時，生成用於記錄數據變更情況的更新日誌；發送模塊，用於將所述更新日誌發送給客戶端，以使所述客戶端根據所述更新日誌更新發生變更的本地數據。

本申請第三方面實施例提出的數據同步裝置，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

為達到上述目的，本申請第四方面實施例提出的數據同步裝置，包括：接收模塊，用於接收服務端發送的更新日誌，所述更新日誌是所述服務端在獲知數據發生變更時發送的；更新模塊，用於根據所述更新日誌更新發生變更的本地數據。

本申請第四方面實施例提出的數據同步裝置，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

為達到上述目的，本申請第五方面實施例提出的數據同步系統，包括：上述兩個方面的裝置。

本申請第五方面實施例提出的數據同步系統，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

本申請附加的方面和優點將在下面的描述中部分給出，部分將從下面的描述中變得明顯，或通過本申請的實踐了解到。

附圖說明

本申請上述的和/或附加的方面和優點從下面結合附圖對實施例的描述中將變得明顯和容易理解，其中：

圖1是本申請一實施例提出的數據同步方法的流程示意圖；

圖2是本申請實施例中系統結構示意圖；

圖3是本申請另一實施例提出的數據同步方法的流程示意圖；

圖4是本申請另一實施例提出的數據同步方法的流程示意圖；

圖5是本申請另一實施例提出的數據同步方法的流程示意圖；

圖6是本申請另一實施例提出的數據同步方法的流程示意圖；

圖7是本申請另一實施例提出的數據同步方法的流程示意圖；

圖8是本申請另一實施例提出的數據同步方法的流程示意圖；

圖9是本申請另一實施例提出的數據同步方法的流程示意圖；

圖10是本申請另一實施例提出的數據同步方法的流程示意圖；

圖11是本申請另一實施例提出的數據同步方法的流程示意圖；

圖12是本申請另一實施例提出的數據同步方法的流程示意圖；

圖13是本申請另一實施例提出的數據同步方法的流程示意圖；

圖14是本申請另一實施例提出的數據同步方法的流程示意圖；

圖15是本申請另一實施例提出的數據同步裝置的結構示意圖；

圖16是本申請另一實施例提出的數據同步裝置的結構示意圖；

圖17是本申請另一實施例提出的數據同步裝置的結構示意圖；

圖18是本申請另一實施例提出的數據同步裝置的結構示意圖；

圖19是本申請另一實施例提出的數據同步系統的結構示意圖。

具體實施方式

下面詳細描述本申請的實施例，所述實施例的示例在附圖中示出，其中自始至終相同或類似的標號表示相同或類似的模塊或具有相同或類似功能的模塊。下面通過參考附圖描述的實施例是示例性的，僅用於解釋本申請，而不能理解為對本申請的限制。相反，本申請的實施例包括落入所附加權利要求書的精神和內涵範圍內的所有變化、修改和等同物。

圖1是本申請一實施例提出的數據同步方法的流程示意圖，本實施例以服務端的執行流程為例，該方法包括：

S11：獲知數據發生變更。

例如，用戶可以在位於服務端的業務系統中增加、刪除或修改數據，從而服務端獲知數據發生變更。業務系統例如為位於服務端的為應用程式(APP)內的功能項提供數據的系統，如為購物類APP的收藏夾提供數據的系統等。

S12：在數據發生變更時，生成用於記錄數據變更情況的更新日誌。

參見圖2，服務端可以具體包括：消息處理中心21，業務系統在自身的數據發生變更後，可以將數據變更情況通知給消息處理中心，消息處理中心根據數據變更情況按照預設格式生成更新日誌(updatelog)。另外，在生成更新日誌後，消息處理中心可以將更新日誌保存在同步消息資料庫22內。

S13：將所述更新日誌發送給客戶端，以使所述客戶端根據所述更新日誌更新發生變更 的本地數據。

參見圖2，服務端還可以包括：消息下發中心23，消息下發中心23用於從同步消息資料庫22中讀取更新日誌並發送給客戶端。

另外，參見圖2，服務端還可以包括：訂閱關係資料庫24、用戶設備資料庫25、全雙工網絡通道26和用戶設備任務狀態獲取模塊27和進度遊標記錄資料庫28。訂閱關係資料庫24中保存一條或多條訂閱關係，訂閱關係包括：更新日誌與用戶、用戶設備、APP中的一項或多項之間的關係，以及，用戶、用戶設備與APP之間的對應關係。用戶設備資料庫25用於保存用戶設備的連接信息。全雙工網絡通道26是客戶端與服務端之間的長連接，可以提供服務端向客戶端發送消息以及客戶端向服務端發送消息。用戶設備任務狀態獲取模塊27用於獲取每個用戶設備上的更新日誌的處理情況相關信息，如未處理的更新日誌的數量，每個已處理的更新日誌是否處理成功等，之後，將獲取的處理情況相關信息記錄在進度遊標記錄資料庫28中。

在發送更新日誌時，消息下發中心23可以根據訂閱關係資料庫24中保存的訂閱關係確定作為目的地的用戶設備，再從用戶設備資料庫25中獲取作為目的地的用戶設備的連接信息，再確定與該連接信息對應的全雙工網絡通道26，通過該全雙工網絡通道將更新日誌發送給用戶設備。另外，用戶設備可以將根據更新日誌的處理情況再通過全雙工網絡通道發送給消息下發中心，消息下發中心將其保存在進度遊標記錄資料庫28中。

本實施例中，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

一些實施例中，參見圖3，S13可以具體包括：

S31：獲取同一個用戶對應的不同客戶端上的更新日誌。

例如，同一個用戶可以在不同的用戶設備上進行登錄，從而同一個用戶可以對應不同的客戶端，同一個用戶對應的不同客戶端上的更新日誌可以相同或不同。

S32：根據所述不同客戶端上的更新日誌，確定需同步的更新日誌，並將需同步的更新日誌發送給對應的客戶端，以同步不同客戶端上的更新日誌。

例如，同一個用戶在用戶設備-1和用戶設備-2上都處於登錄狀態，由於不同用戶設備的處理進度可能不同，造成不同的用戶設備上可能具有不同的更新日誌。例如，對應該同一個用戶，更新日誌包括：更新日誌-1、更新日誌-2和更新日誌-3，用戶設備-1上的更新日誌例如包括：更新日誌-1和更新日誌-2，用戶設備-2上的更新日誌例如為更新日誌-3，此時，可以對應每個用戶設備，確定該用戶設備上需同步的更新日誌，需同步的更新日誌是指自身用戶設備上沒有而其他用戶設備上已有的更新日誌，例如，對應用戶設備-1的需 同步的更新日誌是更新日誌-3，對應用戶設備-2的需同步的更新日誌包括更新日誌-1和更新日誌-2。在對應每個用戶設備確定出相應的需同步的更新日誌後，可以將需同步的更新日誌發送給相應的用戶設備，例如，將更新日誌-3發送給用戶設備-1，將更新日誌-1和更新日誌-2發送給用戶設備-2，從而使得用戶設備-1和用戶設備-2上的更新日誌一致，實現不同用戶設備間的更新日誌的同步。可以理解的是，上述以發送到用戶設備為例，在具體實施例時通常是指發送到用戶設備上某個APP所對應的客戶端。

本實施例中，通過確定需同步的更新日誌，並將其發送給對應的客戶端，可以實現多端同步。

一些實施例中，參見圖4，當需要發送給客戶端的更新日誌為多條時，S13可以具體包括：

S41：向客戶端發送一條當前的更新日誌。

其中，可以將需要發送的每條更新日誌依次作為當前的更新日誌，例如，首次時，向客戶端發送第一條更新日誌。

S42：接收客戶端發送的對應所述當前的更新日誌的響應消息。

例如，客戶端接收到第一條更新日誌後，可以根據該更新日誌進行數據更新，並在數據更新後向服務端發送響應消息。

S43：接收到該響應消息後，發送所述當前的更新日誌的下一條的更新日誌。

例如，服務端接收到客戶端發送的對應第一條更新日誌的響應消息後，可以向客戶端發送第二條更新日誌。

類似的，服務端在接收到客戶端發送的對應第二條更新日誌的響應消息後，再繼續發送第三條更新日誌，依此處理，直到將需要發送的多條更新日誌發送給客戶端。

本實施例中，通過接收到客戶端發送的對應前一條更新日誌的響應消息後再發送後一條更新日誌，可以實現更新日誌的序列化發送。

一些實施例中，參見圖5，當需要發送給客戶端的更新日誌為多條時，S13可以具體包括：

S51：同時向客戶端發送多條更新日誌。

例如，服務端根據每次能夠發送的消息數量值，向客戶端同時發送相應數量的多條更新日誌，直至將需要發送的多條更新日誌都發送給客戶端。

相應的，客戶端也可以向服務端同時發送多條與更新日誌對應的響應消息。

本實施例中，通過同時向客戶端發送多條更新日誌，可以提高發送速度。

一些實施例中，參見圖6，當更新日誌為多條時，S12之後還可以包括：

S61：獲取多條同屬於同一個數據源的數據的更新日誌。

例如，更新日誌中包含業務信息，將包含同一個業務信息的更新日誌確定為同屬於同一個數據源的數據的更新日誌。

S62：將所述多條同屬於同一個數據源的數據的更新日誌進行合併處理，得到合併處理後的更新日誌。

相應的，S13具體包括：

S63：將合併處理後的更新日誌發送給客戶端，或者，在合併處理後確定不再向客戶端發送更新日誌時，不再發送更新日誌。

例如，多條同屬於同一個數據源的數據的更新日誌包括：【消息-ADD】-【消息-MOD V2】-【消息-MOD V3】，含義是：先發生了一個增加(ADD)行為，又發生了兩次修改(MOD)行為，分別是先修改為V2，再修改為V3，那麼經過合併處理後，得到的合併處理後更新日誌包括：【消息-ADD】-【消息-MOD V3】，先讓客戶端增加該數據，然後更新到最新的V3。

又例如，多條同屬於同一個數據源的數據的更新日誌包括：【消息-MOD】-【消息-DEL】，含義是：先發生了一個MOD行為，然後發生了一個刪除(DEL)行為，那麼合併處理後的更新日誌是：【消息-DEL】，含義是：客戶端僅需要發生刪除行為。

又例如，多條同屬於同一個數據源的數據的更新日誌包括：【消息-ADD】-【消息MOD】-【消息DEL】，含義是：先增加一個數據，再修改該數據，最後刪除該數據。那麼合併處理後的更新日誌是空，也就是說客戶端不需要對該數據進行處理，因此，此時服務端不需要向客戶端發送更新日誌。

本實施例中，通過先進行合併處理再發送合併處理後的更新日誌或不發送更新日誌，可以減少下行數據傳輸的網絡佔用時間，以及減少客戶端不必要的處理過程。

一些實施例中，參見圖7，S13之後還可以包括：

S71：如果沒有接收到所述客戶端對應所述更新日誌的響應消息，則重新發送所述更新日誌。

例如，客戶端在接收到更新日誌後，可以在接收到更新日誌或根據更新日誌進行數據更新後，向服務端發送響應消息。

如果服務端在預設時間內沒有收到該響應消息，則可以重新發送更新日誌。

本實施例中，通過服務端重新發送更新日誌，可以實現服務端的重試機制，提高下行網絡傳輸的可靠性。

一些實施例中，參見圖8，S13之後還可以包括：

S81：接收所述客戶端發送的對應所述更新日誌的第一響應消息。

例如，客戶端在接收到更新日誌或根據更新日誌更新數據後，向服務端發送響應消息，為了與服務端發送的響應消息區分，此時的響應消息可以稱為第一響應消息。

S82：向所述客戶端發送對應所述第一響應消息的第二響應消息，以使所述客戶端在沒有接收到所述第二響應消息時，重新發送所述第一響應消息。

例如，服務端在接收到第一響應消息後可以向客戶端發送對應的第二響應消息。

如果客戶端沒有收到第二響應消息，則可以重新發送對應的第一響應消息。

可以理解的是，更新日誌、第一響應消息和第二響應消息中可以包含相同的關聯標識，以相互對應。

本實施例中，通過客戶端重新發送響應消息，可以實現客戶端的重試機制，提高上行網絡傳輸的可靠性。

一些實施例中，參見圖9，S13之後還包括：

S91：獲取所述客戶端未處理的更新日誌的數量。

例如，在圖2所示的用戶設備任務狀態資料庫中可以記錄每個用戶設備的處理情況，因此，服務端可以通過在用戶設備任務狀態資料庫中進行查詢，獲取每個用戶設備未處理的更新日誌的數量。

S92：如果所述數量大於預設閾值，則向客戶端發送過期指令，以使所述客戶端根據所述過期指令清理本地數據並從服務端重新獲取同步數據。

例如，客戶端-1的未處理的更新日誌的數量大於預設閾值時，服務端可以向客戶端-1發送過期指令，客戶端-1接收到該過期指令後，不再根據更新日誌進行數據更新，而是以整體覆蓋更新的方式重新從服務端獲取數據，以實現客戶端與服務端的數據同步。

本實施例中，通過在客戶端積累大量未處理的更新日誌後，不再根據更新日誌進行數據更新，可以避免大量的更新日誌耗費較長的客戶端的處理時間，從而降低對客戶端的業務使用的影響。

一些實施例中，參見圖10，S13之後，還包括：

S101：當所述更新日誌中包含的數據在客戶端被標記為過期時，接收所述客戶端發送的過期通知消息。

例如，客戶端可以將預設時間(如7天)內未使用的數據標記為過期，如果客戶端接收的更新日誌中包含過期數據，則客戶端不再根據該更新日誌進行數據更新，並且向服務端發送過期通知消息。

服務端在接收到針對數據的過期通知消息後，可以在後續的預設時間內不再發送包含過期數據的更新日誌。

本實施例中，通過客戶端發送的針對過期數據的過期通知消息，可以提高更新日誌的發送效率，避免發送無用的更新日誌。

圖11是本申請另一實施例提出的數據同步方法的流程示意圖，本實施例以客戶端的執 行流程為例，該方法包括：

S111：接收服務端發送的更新日誌，所述更新日誌是所述服務端在獲知數據發生變更時發送的。

例如，如上述實施例所示，服務端可以獲知服務端的數據發生變更，服務端在獲知數據發生變更時，可以根據變更情況生成更新日誌，之後，服務端可以將更新日誌發送給客戶端。

S112：根據所述更新日誌更新發生變更的本地數據。

其中，更新日誌中可以包括如下參數：

【commandId】:命令唯一性編號，客戶端用此編號來處理重複指令等。

【ds】：當前數據歸屬的業務的代碼，每個業務數據都有唯一性代碼。

【data】：發生變更的數據內容。

【version】：發生變更後的數據版本號。

【operate】：數據變更類型，包括：增加(ADD)、刪除(DEL)、修改(MOD)。

客戶端根據上述格式的更新日誌更新發生變更的本地數據可以具體包括：

對本地數據中的所述更新日誌中包括的發生變更的數據內容，進行所述更新日誌中包括的操作指令對應的操作。

例如，操作指令(operate)是增加(【ADD】)時，將發生變更的數據內容(【data】)添加到本地數據中。

又例如，操作指令(operate)是刪除(【DEL】)時，將發生變更的數據內容(【data】)在本地數據中刪除。

又例如，操作指令(operate)是刪除(【MOD】)時，將業務【ds】對應的數據修改為發生變更的數據內容(【data】)，並將數據版本修改為【version】指示的版本號。

一些實施例中，參見圖12，在S112之前，該方法還可以包括：

S121：判斷是否需要處理更新日誌，若是，執行S112，否則執行S122。

其中，可以根據如下項中的一項或多項判斷是否需要處理更新日誌：

判斷更新日誌是否是重複指令，當是重複指令時確定不需要處理，否則需要處理。其中，可以根據commandID判斷是否是重複指令。

判斷更新日誌中包含的數據是否被標記為過期，當被標記為過期時確定不需要處理，否則需要處理。其中，客戶端可以將預設時間(如7天)內未使用的數據標記為過期，從而可以確定更新日誌中包含的數據是否被標記為過期。

判斷所述更新日誌中包含的數據的版本是否比本地數據的版本新，當本地數據的版本更新時，不需要處理，否則需要處理。其中，更新日誌中包含版本號，並且本地數據中也 可以對應配置版本號，因此，可以比較兩個版本號，得到判斷結果。

判斷客戶端當前所處的狀態是否屬於預設狀態，如果不屬於預設狀態可以確定不需要處理更新日誌，否則需要處理，其中，預設狀態包括：初始化成功、初始化失敗、同步成功或同步失敗。其中，客戶端可以根據當前處理情況更新狀態，客戶端所處的狀態可以分為：未初始化、初始化成功、初始化失敗、同步成功、同步失敗和數據過期。

S122：不處理所述更新日誌。

另外，在數據過期時，客戶端還可以向服務端發送過期通知消息。

另外，在更新日誌中的版本信息較舊時，客戶端還可以向服務端發送版本錯誤的信息。

本實施例中，通過先進行是否需要處理更新日誌的判斷，可以在不需要時不處理更新日誌，避免資源浪費。

一些實施例中，參見圖13，該方法還可以包括：

S131：根據初始化行為或者標記行為進行初始化，得到初始化狀態，所述初始化狀態包括：未初始化、初始化成功或者初始化失敗。

初始化是客戶端進行本地數據的初始化。

初始化行為可以包括：APP初始化、數據被讀取時、業務模塊主動觸發。

通過上述初始化行為可以實現數據的初始化。

另外，初始化也可以是標記行為，例如，僅被標記為初始化成功，而沒有實際上的初始化行為。

在S122之後，還可以包括：

S132：根據所述更新日誌更新發生變更的本地數據後，得到同步狀態，所述同步狀態包括：同步成功或同步失敗；

另外，還可以包括：

S133：根據數據的使用情況，將預設時間內未使用的數據標記為過期，得到數據過期狀態。

例如，如果數據A在預設時間內未被讀或寫，則客戶端將其標記為過期，之後如果客戶端接收到對A的更新日誌後，不處理該更新日誌。

本實施例中，通過確定客戶端的狀態，可以有效確定是否處理更新日誌。

一些實施例中，參見圖14，該方法還可以包括：

S141：對訂閱了所述更新日誌的業務方進行回調通知。

例如，業務方-1向客戶端訂閱了ds-1的更新日誌，則客戶端接收到ds-1的更新日誌後，不僅可以根據該更新日誌進行客戶端本地數據的更新，還可以將該更新日誌發送給業務方-1，從而業務方-1可以根據該更新日誌進行後續處理，如更新業務方內部的數據。

本實施例中，通過對訂閱了更新日誌的業務方進行回調通知，可以方便業務方的有效處理。

另外，類似對服務端的處理，客戶端還可以執行如下內容：

一些實施例中，所述接收服務端發送的更新日誌，包括：

接收服務端發送的需同步的更新日誌，所述需同步的更新日誌是所述服務端根據不同客戶端上的更新日誌確定的。

一些實施例中，當需要發送給客戶端的更新日誌為多條時，所述接收服務端發送的更新日誌，包括：

接收服務端發送的一條當前的更新日誌，以及，向服務端發送對應所述當前的更新日誌的響應消息，以使所述服務端在接收到所述響應消息後發送所述當前的更新日誌的下一條的更新日誌；或者，

接收服務端同時發送的多條更新日誌。

一些實施例中，當需要發送給客戶端的更新日誌包括：多條同屬於同一個數據源的數據的更新日誌時，所述接收服務端發送的更新日誌，包括：

接收服務端發送的合併處理後的更新日誌，或者，在服務端合併處理後確定不需要向客戶端發送更新日誌時，不接收服務端發送的更新日誌，所述合併處理後的更新日誌是所述服務端將所述多條同屬於同一個數據源的數據的更新日誌進行合併處理後得到的。

一些實施例中，還包括：

向所述服務端發送對應所述更新日誌的響應消息，以使所述服務端在沒有接收到所述響應消息時重新發送所述更新日誌。

一些實施例中，還包括：

向所述服務端發送對應所述更新日誌的第一響應消息，以使所述服務端在在接收到所述第一響應消息後向所述客戶端發送對應所述第一響應消息的第二響應消息；

如果沒有接收到所述第二響應消息，重新向所述服務端發送所述第一響應消息。

一些實施例中，還包括：

接收所述服務端發送的過期指令，所述過期指令是所述服務端在確定所述客戶端未處理的更新日誌的數量大於預設閾值後發送的；

根據所述過期指令清理本地數據，並從服務端重新獲取同步數據。

具體內容可以參照服務端的相關描述，在此不再贅述。

通過上述方式可以提高更新日誌的準確性和高效性。

圖15是本申請另一實施例提出的數據同步裝置的結構示意圖，該裝置位於服務端，該裝置150包括：獲知模塊151、生成模塊152和發送模塊153。

獲知模塊151，用於獲知數據發生變更；

生成模塊152，用於在數據發生變更時，生成用於記錄數據變更情況的更新日誌；

發送模塊153，用於將所述更新日誌發送給客戶端，以使所述客戶端根據所述更新日誌更新發生變更的本地數據。

一些實施例中，發送模塊153具體用於：

獲取同一個用戶對應的不同客戶端上的更新日誌；

根據所述不同客戶端上的更新日誌，確定需同步的更新日誌，並將需同步的更新日誌發送給對應的客戶端，以同步不同客戶端上的更新日誌。

一些實施例中，當需要發送給客戶端的更新日誌為多條時，發送模塊153具體用於：

向客戶端發送一條當前的更新日誌，並在接收到客戶端發送的對應所述當前的更新日誌的響應消息後，發送所述當前的更新日誌的下一條的更新日誌；

或者，

同時向客戶端發送多條更新日誌。

一些實施例中，當需要發送給客戶端的更新日誌包括：多條同屬於同一個數據源的數據的更新日誌時，參見圖16，該裝置還包括：

合併模塊154，用於將所述多條同屬於同一個數據源的數據的更新日誌進行合併處理，得到合併處理後的更新日誌；

發送模塊153具體用於：將合併處理後的更新日誌發送給客戶端，或者，在合併處理後確定不再向客戶端發送更新日誌時，不再發送更新日誌。

一些實施例中，發送模塊153還用於：如果沒有接收到所述客戶端對應所述更新日誌的響應消息，則重新發送所述更新日誌。

一些實施例中，參見圖16，該裝置還包括：

接收模塊155，用於接收所述客戶端發送的對應所述更新日誌的第一響應消息；

所述發送模塊153還用於：向所述客戶端發送對應所述第一響應消息的第二響應消息，以使所述客戶端在沒有接收到所述第二響應消息時，重新發送所述第一響應消息。

一些實施例中，參見圖16，該裝置還包括：

獲取模塊156，用於獲取所述客戶端未處理的更新日誌的數量；

所述發送模塊153還用於：如果所述數量大於預設閾值，則向客戶端發送過期指令，以使所述客戶端根據所述過期指令清理本地數據並從服務端重新獲取同步數據。

一些實施例中，接收模塊155還用於：當所述更新日誌中包含的數據在客戶端被標記為過期時，接收所述客戶端發送的過期通知消息。

上述模塊的具體內容可以參見上述方法實施例中的相關描述。

本實施例中，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

圖17是本申請另一實施例提出的數據同步裝置的結構示意圖，該裝置位於客戶端，該裝置170包括：接收模塊171和更新模塊172。

接收模塊171，用於接收服務端發送的更新日誌，所述更新日誌是所述服務端在獲知數據發生變更時發送的；

更新模塊172，用於根據所述更新日誌更新發生變更的本地數據。

一些實施例中，所述接收模塊171具體用於：

接收服務端發送的需同步的更新日誌，所述需同步的更新日誌是所述服務端根據不同客戶端上的更新日誌確定的。

一些實施例中，當需要發送給客戶端的更新日誌為多條時，所述接收模塊171具體用於：

接收服務端發送的一條當前的更新日誌，以及，向服務端發送對應所述當前的更新日誌的響應消息，以使所述服務端在接收到所述響應消息後發送所述當前的更新日誌的下一條的更新日誌；或者，

接收服務端同時發送的多條更新日誌。

一些實施例中，當需要發送給客戶端的更新日誌包括：多條同屬於同一個數據源的數據的更新日誌時，所述接收模塊171具體用於：

接收服務端發送的合併處理後的更新日誌，或者，在服務端合併處理後確定不需要向客戶端發送更新日誌時，不接收服務端發送的更新日誌，所述合併處理後的更新日誌是所述服務端將所述多條同屬於同一個數據源的數據的更新日誌進行合併處理後得到的。

一些實施例中，參見圖18，該裝置還包括：

第一發送模塊173，用於向所述服務端發送對應所述更新日誌的響應消息，以使所述服務端在沒有接收到所述響應消息時重新發送所述更新日誌。

一些實施例中，參見圖18，該裝置還包括：

第二發送模塊174，用於向所述服務端發送對應所述更新日誌的第一響應消息，以使所述服務端在在接收到所述第一響應消息後向所述客戶端發送對應所述第一響應消息的第二響應消息；

第三發送模塊175，用於如果沒有接收到所述第二響應消息，重新向所述服務端發送所述第一響應消息。

一些實施例中，參見圖18，所述接收模塊171還用於：

接收所述服務端發送的過期指令，所述過期指令是所述服務端在確定所述客戶端未處理的更新日誌的數量大於預設閾值後發送的；

所述裝置還包括：

清理模塊176，用於根據所述過期指令清理本地數據，並從服務端重新獲取同步數據。

一些實施例中，參見圖18，該裝置還包括：

通知模塊177，用於對訂閱了所述更新日誌的業務方進行回調通知。

一些實施例中，所述更新日誌中包括：操作指令和發生變更的數據內容，所述更新模塊72具體用於：

在本地數據中，對所述更新日誌中包括的發生變更的數據內容，進行所述更新日誌中包括的操作指令對應的操作。

一些實施例中，參見圖18，該裝置還包括：

判斷模塊178，用於判斷如下項中的一項或多項：

判斷所述更新日誌是否是重複指令，以便在不是重複指令時根據所述更新日誌更新本地數據，否則，不處理所述更新日誌；

判斷所述更新日誌中包含的數據是否被標記為過期，以便在沒有標記為過期時根據所述更新日誌更新本地數據，否則，不處理所述更新日誌，並向所述服務端發送過期消息；

判斷所述更新日誌中包含的數據的版本是否比本地數據的版本新，以便在更新日誌中包含的數據的版本比本地數據的版本新時，根據所述更新日誌更新本地數據，否則，不處理所述更新日誌；

判斷客戶端當前所處的狀態是否屬於預設狀態，以便在屬於預設狀態時，根據所述更新日誌更新本地數據，否則，不處理所述更新日誌，所述預設狀態包括：初始化成功、初始化失敗、同步成功或同步失敗。

一些實施例中，參見圖18，該裝置還包括：

狀態確定模塊179，用於執行如下項中的一項或多項：

根據初始化行為或者標記行為進行初始化，得到初始化狀態，所述初始化狀態包括：未初始化、初始化成功或者初始化失敗；

根據所述更新日誌更新發生變更的本地數據後，得到同步狀態，所述同步狀態包括：同步成功或同步失敗；

根據數據的使用情況，將預設時間內未使用的數據標記為過期，得到數據過期狀態。

上述模塊的具體內容可以參見上述方法實施例中的相關描述。

本實施例中，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可 以提高更新效率，避免資源浪費。

圖19是本申請另一實施例提出的數據同步系統的結構示意圖，該系統190包括服務端裝置191和客戶端裝置192。其中，服務端裝置可以如圖15或圖16所示，客戶端裝置可以如圖17或圖18所示。

上述模塊的具體內容可以參見上述方法實施例中的相關描述。

本實施例中，通過在數據發生變更時，將更新日誌發送給客戶端，可以降低滯後性，從而提高數據更新的實時性，另外，通過更新發生變更的本地數據，而不是整體更新，可以提高更新效率，避免資源浪費。

需要說明的是，在本申請的描述中，術語「第一」、「第二」等僅用於描述目的，而不能理解為指示或暗示相對重要性。此外，在本申請的描述中，除非另有說明，「多個」的含義是指至少兩個。

流程圖中或在此以其他方式描述的任何過程或方法描述可以被理解為，表示包括一個或更多個用於實現特定邏輯功能或過程的步驟的可執行指令的代碼的模塊、片段或部分，並且本申請的優選實施方式的範圍包括另外的實現，其中可以不按所示出或討論的順序，包括根據所涉及的功能按基本同時的方式或按相反的順序，來執行功能，這應被本申請的實施例所屬技術領域的技術人員所理解。

應當理解，本申請的各部分可以用硬體、軟體、固件或它們的組合來實現。在上述實施方式中，多個步驟或方法可以用存儲在存儲器中且由合適的指令執行系統執行的軟體或固件來實現。例如，如果用硬體來實現，和在另一實施方式中一樣，可用本領域公知的下列技術中的任一項或他們的組合來實現：具有用於對數據信號實現邏輯功能的邏輯門電路的離散邏輯電路，具有合適的組合邏輯門電路的專用集成電路，可編程門陣列(PGA)，現場可編程門陣列(FPGA)等。

本技術領域的普通技術人員可以理解實現上述實施例方法攜帶的全部或部分步驟是可以通過程序來指令相關的硬體完成，所述的程序可以存儲於一種計算機可讀存儲介質中，該程序在執行時，包括方法實施例的步驟之一或其組合。

此外，在本申請各個實施例中的各功能單元可以集成在一個處理模塊中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個模塊中。上述集成的模塊既可以採用硬體的形式實現，也可以採用軟體功能模塊的形式實現。所述集成的模塊如果以軟體功能模塊的形式實現並作為獨立的產品銷售或使用時，也可以存儲在一個計算機可讀取存儲介質中。

上述提到的存儲介質可以是只讀存儲器，磁碟或光碟等。

在本說明書的描述中，參考術語「一個實施例」、「一些實施例」、「示例」、「具體示例」、 或「一些示例」等的描述意指結合該實施例或示例描述的具體特徵、結構、材料或者特點包含於本申請的至少一個實施例或示例中。在本說明書中，對上述術語的示意性表述不一定指的是相同的實施例或示例。而且，描述的具體特徵、結構、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結合。

儘管上面已經示出和描述了本申請的實施例，可以理解的是，上述實施例是示例性的，不能理解為對本申請的限制，本領域的普通技術人員在本申請的範圍內可以對上述實施例進行變化、修改、替換和變型。