CN108632300A - 数据同步系统、方法、服务器、客户端及电子设备 - Google Patents

Abstract

本发明实施例提供一种数据同步系统、方法、服务器、客户端及电子设备，其中，方法包括：客户端接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；客户端采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。本发明实施例的方案可以减轻服务器下行数据至客户端的过程中，服务器的压力。

Description

数据同步系统、方法、服务器、客户端及电子设备

技术领域

本申请涉及通信技术领域，尤其涉及一种数据同步系统、方法、服务器、客户端及电子设备。

背景技术

传统的客户端(Client)和服务器(Server)架构(简称“C/S”架构)中，服务器需要把数据实时通知到客户端，并且不同类型的用户使用的数据不同。通常服务器先会通过长连接通知客户端数据有变更，然后客户端根据自身处理数据的需要，调用指定的接口从服务器获取所需的数据。所谓长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

现有技术的缺陷：

传统的C/S架构中，服务器需要根据不同客户端所请求的数据内容，在本地通过逻辑计算来组织形成针对不同客户端的下行业务数据。由于客户端在接到数据变更的通知后，会立即向服务器请求数据，此方式会突发性的给服务器造成巨大的瞬间压力，进而影响服务器其他的业务处理。甚至可能造成服务器雪崩。

发明内容

本发明提供了一种数据同步系统、方法、服务器、客户端及电子设备，以减轻服务器下行数据至客户端的过程中，服务器的压力。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面，提供了一种基于C/S架构的数据同步系统，包括：服务器和客户端；

所述服务器向所述客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

所述客户端采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

第二方面，提供了一种基于C/S架构的数据同步方法，包括：

向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

第三方面，提供了另一种基于C/S架构的数据同步方法，包括：

接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

第四方面，提供了一种服务器，包括：

数据下发模块，用于向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

第五方面，提供了一种客户端，包括：

数据接收模块，用于接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

数据同步模块，用于采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

第六方面，提供了一种电子设备，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

第七方面，提供了另一种电子设备，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

本发明提供的数据同步系统、方法、服务器、客户端及电子设备，服务器在向客户端同步业务数据时，只需向客户端下发一次业务变更数据即可，该业务变更数据包括至少一个业务的业务数据和计算逻辑；客户端采用该计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步，从而降低服务器的业务处理压力。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为传统C/S架构的示意图；

图2为基于传统C/S架构的服务器下行数据同步的处理流程图；

图3为本发明实施例的C/S架构示意图；

图4为本发明实施例的基于C/S架构的数据同步处理流程图；

图5为本发明实施例的基于C/S架构的数据同步系统结构图；

图6为本发明实施例的基于C/S架构的数据同步方法流程图一；

图7为本发明实施例的基于C/S架构的数据同步方法流程图二；

图8为本发明实施例的服务器的结构示意图；

图9为本发明实施例的客户端的结构示意图；

图10为本发明实施例的电子设备的结构示意图一；

图11为本发明实施例的电子设备的结构示意图二。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明改变了现有技术中，在C/S架构下的服务器下行数据同步过程中，服务器需先向客户端下发数据变更通知，然后根据各客户端的不同的数据请求，有针对性的组织和下发业务数据，其核心思想在于，服务器通过将当次变更的全部业务数据以及计算逻辑一次性下发给所有客户端，使客户端通过将当前登录的用户的属性数据经上述计算逻辑计算，然后根据计算结果从下发的业务数据中提取出适用于本客户端的业务数据，然后进行业务数据同步，从而减轻了服务器因针对不同客户端进行组织和下发业务数据带来的业务负担，提高了下行业务数据同步的效率。

首先，结合图1所示，对传统的C/S架构进行简单说明。

现有的C/S架构中，服务器的接入层与客户端的网络层之间形成数据传输通路，使得客户端和服务器之间可进行数据交互，这其中也包括服务器向客户端进行业务数据同步。对于C/S架构的交互程序，为了降低客户端多次调用接口完成每次建立链接所消耗的时间，以及服务器能实时的下发数据到达客户端，客户端都会选择与服务器建立一个长连接。

客户端在需要数据的时候会发起一个数据请求从服务器拉取需要的业务数据。这种请求一般是http请求。客户端拉取到业务数据之后，这个http请求对应的底层链接就会断开。有些客户端为了避免频繁发起数据请求导致频繁建立底层链接带来的消耗，会在客户端和服务器之间建立一个长连接。在长连接之上发起http请求。客户端获取到业务数据之后，在本地进行业务处理。当然客户端也可先将获取到的业务数据进行数据存储以备后续使用。

如图2所示，为基于传统C/S架构的服务器下行数据的数据同步处理流程。在传统C/S架构下，服务器实时下行业务数据到客户端的过程包括如下步骤：

服务器通过长连接下行一个业务数据变更的通知；

客户端收到业务变更的通知后，对通知内容进行处理，从中解析出客户端需要处理的业务；

客户端发起获取此业务对应的接口调用，以向服务器请求相应的业务数据；

服务器根据不同客户端数据请求，组织和生成相应的业务数据；

服务器将生成的业务数据下发给客户端，以使客户端使用业务数。

以上的基于传统C/S架构下，服务器实时下行业务数据到客户端的过程存在如下技术缺陷：

成本高：当客户端同时向服务器发起数据请求时，会对服务器造成瞬间压力升高。据不完全统计：当同时在线用户达700万时，服务器下行数据一般在一个心跳周期90秒内完成，即90秒内会有700万的客户端同步发起数据请求，每秒的数据请求量会达到700万/90秒≈8万/秒。这个数据请求量是非常巨大的，假如每台处理机可以处理2000/秒的数据请求，也需要40台机器，而且处理机增多，会导致服务器的不稳定，影响其他的业务。

效率低：因为客户端请求数据会给服务器造成巨大的压力，所以一般在实际实施时会有一些权衡方案。一般的权衡方案如下：

a)服务器在下行业务变更的通知的时候会降低频率，这个频率的设置会考虑到当前服务器能承受的压力来计算。比如：30分钟内通知到全部在线用户，此时服务器的压力为700万/30*60秒≈3.9千/秒。

b)服务器在短时间内下行业务变更通知给全部在线客户端，但是客户端在30分钟内随机请求服务器，压力和a)方案一样。

c)服务器在短时间内下行业务变更通知给全部的在线客户端，客户端请求服务器，但是服务器进行流量控制，同一时间只能服务部分客户端。

以上这些权衡方案都在效率上面做了牺牲，对于某些对时间要求比较高的业务仍没办法满足要求。

本发明要解决的问题是：对于C/S架构的应用如何以低成本、高效率的方式同步数据到客户端，并且能做到不同类型的用户使用不同的数据。

为了解决上述问题，本方案提供了一种改进后的C/S架构，如图3所示，该C/S架构在传统的C/S架构的基础上，在各客户端中增加了数据计算层。与现有服务器下行业务数据至客户端不同的是，在改进后的C/S架构中，服务器不在下发业务变更的通知到客户端，转而下发业务数据以及计算逻辑，客户端将当前登录的用户的属性数据在本地经上述计算逻辑进行逻辑计算，从而根据计算结果从业务数据中提取自身需要的业务数据部分，而不需要再向服务器请求具体的业务数据。

如图4所示，为基于图3所示的C/S架构的服务器下行数据的数据同步处理流程。在图3所示的C/S架构下，服务器实时下行业务数据到客户端的过程包括如下步骤：

服务器通过其与客户端之间建立的长连接直接下行已变更的所有业务数据和计算逻辑；

客户端收到业务数据和计算逻辑后，将当前登录的用户的属性数据经计算逻辑进行本地计算，并根据计算结果从业务数据中提取中适用于本客户端的业务数据部分，并进行业务处理；

客户端处理业务数据成功后，向服务器回执处理成功的消息；

服务器接收到回执处理成功的消息后，标记相应用户的业务数据处理成功，以进行记录。

改进后的服务器下行业务数据的数据同步流程较现有技术在以下几个方面有所提升：

成本：因为没有客户端向服务器额外发送获取业务数据的数据请求，服务器不必针对每个客户端组织和下发业务数据，所以没有相应压力的增长，提升了服务器的稳定性，不会对服务器的其他正常业务造成影响，不需要额外增加机器来支撑这些数据请求，降低了服务器的成本。

效率：基本上一个数据变更可以在一个长连接心跳周期(一个心跳周期一般在90秒-4分钟左右)可以同步到全部在线客户端，客户端本身处理基本上在几十ms之内。

基于改进后的C/S架构的服务器下行数据的数据同步处理流程，本发明实施例提供了一种基于C/S架构的数据同步系统，用以减轻服务器下行业务数据至客户端过程中的压力，同时提高下行数据的同步效率。如图5所示，该系统包括：服务器510和客户端520。其中，服务器510用于向客户端下发业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

客户端520用于采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

其中，服务器510和客户端520之间可通过预先建立的长连接，进行数据传输。

具体地，服务器510包括：

数据下发模块，用于向客户端520下发业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使客户端根据计算结果从业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

数据下发模块，通过客户端520与服务器510之间建立的长连接，向客户端520下发业务变更数据。客户端520接收到业务变更数据后，采用计算逻辑对当前登录客户端520的用户的属性数据进行逻辑计算，并根据计算结果从业务数据中提取与该客户端520相适用的数据部分，进行本地业务数据同步。

进一步地，服务器510还可包括：

接收处理模块，用于接收客户端发送的业务数据同步成功消息，并在服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

如果客户端520成功提取出业务数据中与其相适用的数据部分，并完成本地业务数据同步，会向服务器510发送的业务数据同步成功消息，服务器510收到这样的消息后，会在本地将登录该客户端的用户的本次业务数据标记为同步成功状态，以对该用户的业务数据进行记录。

进一步地，服务器510还可包括：

状态查询模块，用于针对本次待下发的业务数据，查询登录该客户端的用户的业务数据是否标记为同步成功状态，如果否，则触发数据下发模块执行向客户端下发业务变更数据的操作。

如果针对本次待下发的业务数据，服务器510本地已经存储了登录当前客户端的用户业务数据标记为同步成功状态的记录，则不再向该客户端发送业务变更数据；否则，触发数据下发模块执行向该客户端下发业务变更数据的操作。

客户端520包括：

数据接收模块，用于接收服务器510下发的业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

数据接收模块，通过客户端520与服务器510之间建立的长连接，接收客户端520下发业务变更数据。

数据同步模块，用于采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

进一步地，客户端520还包括：

消息发送模块，用于在本次业务数据同步成功后，向服务器510发送业务数据同步成功消息，以使服务器510将登录该客户端的用户的本次业务数据标记为同步成功状态。

本发明实施例提供的基于C/S架构的数据同步系统，由于省去了客户端向服务器额外发送获取业务数据的数据请求，服务器不必针对每个客户端组织和下发业务数据，所以没有相应压力的增长，提升了服务器的稳定性，并且利用客户端在本地计算得到其所需要的业务数据，合理发挥了客户端的效力，提高了服务器下行数据的同步效率。

下面通过多个实施例来进一步说明本申请的技术方案。

实施例一

基于上述客户端在本地通过逻辑计算获取其所需的业务数据的方案思想，如图6所示，其为本发明实施例示出的基于C/S架构的数据同步方法流程图一，该方法的执行主为C/S架构下的服务器。如图6所示，该基于C/S架构的数据同步方法包括如下步骤：

S610，向客户端下发业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

其中，用于供客户端从下发的所有业务数据中选取其所需的业务数据的计算逻辑可以是采用Lua编写的脚本程序。Lua是一个小巧的脚本语言，它具有以下一些特性：轻量级、可扩展、高效率、跨平台。Lua几乎可以运行在所有系统上，例如目前主流的移动端IOS系统，以及Android也都很好的支持了Lua语言。计算逻辑的作用，就是将服务器下发的业务数据与不同的客户端的进行匹配，从而使客户端能够从下发的所有业务数据中提取出其自身所需的业务数据部分，而匹配的依据，就是登录当前客户端的用户的属性数据。

如此，服务器不必再根据各客户端请求数据的差异，有针对性的组织和下发业务数据，减轻了服务器的工作压力。

进一步地，如果客户端成功从下发的业务数据中提取出与该客户端相适用的数据部分，并完成了本地业务数据同步，则相应的，服务器还会执行如下步骤，即接收客户端发送的业务数据同步成功消息，并在服务器将登录该客户端的用户的本次业务数据标记为同步成功状态，以进行记录。这样，服务器在下发业务数据时，就可以知道哪些客户端已经下发了业务数据，哪些客户端还没有下发业务数据，并向还没有下发本次业务数据的客户端下发业务数据。

在此基础上，在服务器下发业务变更数据至客户端时，可先执行如下步骤：

针对本次待下发的业务数据，查询登录该客户端的用户的业务数据是否标记为同步成功状态，如果否，则执行所述向客户端下发业务变更数据的操作，从而更加准确的下发业务数据。

进一步地，服务器向客户端下发业务变更数据可包括：服务器基于与客户端之间建立的长连接，向客户端下发业务变更数据。

本实施例提供的基于C/S架构的数据同步方法，以服务器为执行主体，通过一次性下发所有的业务数据和计算逻辑至客户端，由客户端在其本地对登录用户的属性数据经计算逻辑进行计算，以从业务数据中提取其所需的业务数据，从而减轻了服务器的业务压力。

实施例二

如图7所示，其为本发明实施例示出的基于C/S架构的数据同步方法流程图二，该方法的执行主为C/S架构下的客户端。如图7所示，该基于C/S架构的数据同步方法包括如下步骤：

S710，接收服务器下发的业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述的计算逻辑可以是采用Lua编写的脚本程序。计算逻辑的作用，是将服务器下发的业务数据与不同的客户端的进行匹配，从而使客户端能够从下发的所有业务数据中提取出其自身所需的业务数据部分。

S720，采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

其中，所述的用户的属性数据为当前用户登录客户端之后，从服务器获取的，该属性数据可包括用户的：用户名、用户ID、客户端版本等信息。

具体地，客户端采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，计算的结果即为当前业务数据是否适用于客户端的标识或指示。

进一步地，客户端在本次业务数据同步成功后，还可向服务器发送业务数据同步成功消息，以使服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

进一步地，客户端接收服务器下发的业务变更数据可包括：客户端基于与服务器之间建立的长连接，接收服务器下发的业务变更数据。

本实施例提供的基于C/S架构的数据同步方法，以客户端为执行主体，在接收到服务器下发的业务数据和计算逻辑后，通过在客户端本地，对登录用户的属性数据经计算逻辑进行计算，并从业务数据中提取其所需的业务数据，并采用该业务数据进行业务处理，从而减轻了服务器的业务压力，提高了服务器下行数据至客户端的数据同步效率。

实施例三

如图8所示，为本发明实施例的服务器的结构示意图，该服务器可用于执行如图6所示的方法步骤，其包括：

数据下发模块810，用于向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使客户端根据计算结果从业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

进一步地，如图8所示，上述服务器还可包括：

接收处理模块820，用于接收客户端发送的业务数据同步成功消息，并在服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

进一步地，如图8所示，上述服务器还可包括：

状态查询模块830，用于针对本次待下发的业务数据，查询登录该客户端的用户的业务数据是否标记为同步成功状态，如果否，则触发数据下发模块810执行向客户端下发业务变更数据的操作。

本实施例提供的服务器，通过一次性下发所有的业务数据和计算逻辑至客户端，由客户端在其本地对登录用户的属性数据经计算逻辑进行计算，以从业务数据中提取其所需的业务数据，从而减轻了服务器的业务压力。

实施例四

如图9所示，为本发明实施例的客户端的结构示意图，该客户端可用于执行如图7所示的方法步骤，其包括：

数据接收模块910，用于接收服务器下发的业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

数据同步模块920，用于采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

进一步地，在图9所示的客户端中，还可包括：

消息发送模块930，用于在本次业务数据同步成功后，向服务器发送业务数据同步成功消息，以使服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

本实施例提供的客户端，在接收到服务器下发的业务数据和计算逻辑后，通过在客户端本地，对登录用户的属性数据经计算逻辑进行计算，并从业务数据中提取其所需的业务数据，并采用该业务数据进行业务处理，从而减轻了服务器的业务压力，提高了服务器下行数据至客户端的数据同步效率。

实施例五

前面描述了服务器的整体架构，该服务器的功能可借助一种电子设备实现完成，如图10所示，其为本发明实施例的电子设备的结构示意图，具体包括：存储器101和处理器102。

存储器101，用于存储程序。

除上述程序之外，存储器101还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器101可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器102，耦合至存储器101，用于执行存储器101中的程序，以用于：

向客户端下发业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

上述的具体处理操作已经在前面实施例中进行了详细说明，在此不再赘述。

进一步，如图10所示，电子设备还可以包括：通信组件103、电源组件104、音频组件105、显示器106等其它组件。图10中仅示意性给出部分组件，并不意味着电子设备只包括图10所示组件。

通信组件103被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件103经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件103还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件104，为电子设备的各种组件提供电力。电源组件104可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件105被配置为输出和/或输入音频信号。例如，音频组件105包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器101或经由通信组件103发送。在一些实施例中，音频组件105还包括一个扬声器，用于输出音频信号。

显示器106包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

实施例六

前面描述了客户端的整体架构，该客户端的功能可借助一种电子设备实现完成，如图11所示，其为本发明实施例的电子设备的结构示意图，具体包括：存储器111和处理器112。

存储器111，用于存储程序。

除上述程序之外，存储器111还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器111可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器112，耦合至存储器111，用于执行存储器111中的程序，以用于：

接收服务器下发的业务变更数据，该业务变更数据包括至少一个业务的业务数据和计算逻辑；

采用计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

上述的具体处理操作已经在前面实施例中进行了详细说明，在此不再赘述。

进一步，如图11所示，电子设备还可以包括：通信组件113、电源组件114、音频组件115、显示器116等其它组件。图11中仅示意性给出部分组件，并不意味着电子设备只包括图11所示组件。

通信组件113被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件113经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件113还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

电源组件114，为电子设备的各种组件提供电力。电源组件114可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件115被配置为输出和/或输入音频信号。例如，音频组件115包括一个麦克风(MIC)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器111或经由通信组件113发送。在一些实施例中，音频组件115还包括一个扬声器，用于输出音频信号。

显示器116包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (15)

1.一种基于C/S架构的数据同步系统，其特征在于，包括：服务器和客户端；

所述服务器，用于向所述客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

所述客户端，用于采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

2.一种基于C/S架构的数据同步方法，其特征在于，包括：

向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

接收客户端发送的业务数据同步成功消息，并在所述服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

4.根据权利要求3所述的方法，其特征在于，所述向客户端下发业务变更数据之前，还包括：

针对本次待下发的业务数据，查询登录该客户端的用户的业务数据是否标记为同步成功状态，如果否，则执行所述向客户端下发业务变更数据的操作。

5.根据权利要求2所述的方法，其特征在于，所述向客户端下发业务变更数据包括：

基于与所述客户端之间建立的长连接，向客户端下所述发业务变更数据。

6.一种基于C/S架构的数据同步方法，其特征在于，包括：

接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在本次业务数据同步成功后，向服务器发送业务数据同步成功消息，以使所述服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

8.根据权利要求6所述的方法，其特征在于，所述接收服务器下发的业务变更数据包括：

基于与所述服务器之间建立的长连接，接收所述服务器下发的业务变更数据。

9.一种服务器，其特征在于，包括：

数据下发模块，用于向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

10.根据权利要求9所述的服务器，其特征在于，所述服务器还包括：

接收处理模块，用于接收客户端发送的业务数据同步成功消息，并在所述服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

11.根据权利要求10所述的服务器，其特征在于，所述服务器还包括：

状态查询模块，用于针对本次待下发的业务数据，查询登录该客户端的用户的业务数据是否标记为同步成功状态，如果否，则触发所述数据下发模块执行所述向客户端下发业务变更数据的操作。

12.一种客户端，其特征在于，包括：

数据接收模块，用于接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

数据同步模块，用于采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。

13.根据权利要求12所述的客户端，其特征在于，所述客户端还包括：

消息发送模块，用于在本次业务数据同步成功后，向服务器发送业务数据同步成功消息，以使所述服务器将登录该客户端的用户的本次业务数据标记为同步成功状态。

14.一种电子设备，其特征在于，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

向客户端下发业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

其中，所述计算逻辑用于，对当前登录客户端的用户的属性数据进行逻辑计算，以使所述客户端根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，进行本地业务数据同步。

15.一种电子设备，其特征在于，包括：

存储器，用于存储程序；

处理器，耦合至所述存储器，用于执行所述程序，以用于：

接收服务器下发的业务变更数据，所述业务变更数据包括至少一个业务的业务数据和计算逻辑；

采用所述计算逻辑对当前登录客户端的用户的属性数据进行逻辑计算，根据计算结果从所述业务数据中提取与该客户端相适用的数据部分，并进行本地业务数据同步。