CN102043783A - 一种数据更新的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种数据更新的方法，包括：网站服务器确定客户端登录本地后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息；并在接收客户端返回的用户识别信息时，对该用户识别信息进行解析，以获得用户ID，以及在确定对应所述用户ID保存的用户属性信息符合第二预设条件时，对指定的业务相关数据进行更新。这样，网站服务器通过能够及时控制新注册用户和已注册用户的有效操作行为所导致的业务相关数据更新的频率，从而降低了整个系统的资源消耗和运行负荷，提高了系统的处理效率。本发明同时公开了一种网站服务器和一种互联网系统。

Description

一种数据更新的方法、装置及系统

技术领域

本申请涉及互联网技术，特别涉及一种数据更新的方法、装置及系统。

背景技术

目前，在类目繁多的互联网业务中，很多业务都是围绕着用户数据存储和用户数据更新而进行的。在何时以何种方式进行用户数据存储，以及在何时以何种方式进行用户数据更新，对于网站而言至关重要，因为提供准确、及时、丰富的数据信息将会提升网站服务的性能，从而提高网站服务质量，这也就给网站开发和运行维护带来了更高的挑战。

现有技术下，在互联网系统中，用户访问网站时，进行用户数据更新的方法包括以下四种：

1)用户停等的同步方式。即是在用户访问网页页面时，网站服务器执行代码按照逻辑逐步执行，从用户身份识别，到业务数据的获取，再到业务数据的逻辑组织和展现构造，最终完成数据的更新。

这种方法的典型特征是：网站服务器停等和按队列一步一步执行，直到各步骤都完成，用户才能看到希望访问的网页页面。这种方法的优点是数据信息准确而实时；而缺点是当存在执行较慢的逻辑步骤时，需要用户等待的时间较长，甚至会因超时而无结果出现，从而令网站的服务质量降低。因此，这种方法只适合处理逻辑简单，能快速获得的数据页面。

2)AJAX的异步方式。AJAX全称为“Asynchronous JavaScript and XML”(异步JavaScript和XML)，是一种创建交互式网页应用的网页开发技术。

这种方法的典型特征是：网站服务器先执行简单的逻辑处理和数据展现，而同时却通过AJAX异步技术执行复杂、长时间的逻辑处理，执行完成后对之前展现部分数据的页面进行更新，从而完成最终的数据展现。这种方法的优点是能够更为有效、及时地更新基于各种业务的用户数据，并且不影响系统当前的运行，亦不影响用户当前的使用感受。是大大提高了用户的使用感受，但是，这种方法并没有从根本上改变用户需要经过长时间等待，才能获得经过复杂逻辑处理的业务数据的本质。

3)定期预先构造数据的方式。即网站服务器预先完成每个用户访问其业务页面时所需的逻辑处理，并将获得的数据保存起来，在用户访问时，将已构造好的数据迅速展现给用户。

这种方法的优点同样是大大提高了用户的使用感受，而缺点是用户信息不能实时更新，并且对所有的用户都进行数据的预先构造，使得系统资源消耗过大，尤其是新业务的增加会导致系统复杂度和资源消耗成倍增加。

4)数据缓存法。即当缓存中的数据不存在或者缓存数据过期失效的时候，系统就按照方法1)或者方法2)执行数据更新，同时把复杂耗时的逻辑数据放到缓存系统中缓存起来，当用户下次访问的时候，直接从缓存中读取即可。

这种方法的优点是提高了用户的使用感受，也降低了数据逻辑处理流程的复杂度，但是新业务的增加同样会导致系统复杂度和资源消耗成倍增加。

有鉴于此，需要提供一种新的数据更新方法，以克服上述缺陷。

发明内容

本申请实施例提供一种数据更新方法、装置及系统，用以在互联网系统中，提高数据更新流程的处理效率，降低数据更新流程的执行复杂度。

本申请实施例提供的具体技术方案如下：

一种数据更新的方法，包括：

网站服务器确定客户端登录本地后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息；

所述网站服务器接收客户端返回的用户识别信息，并对该用户识别信息进行解析，以获得用户标识ID；

所述网站服务器确定对应所述用户ID保存的用户属性信息符合第二预设条件时，对指定的业务相关数据进行更新。

一种网站服务器，包括：

第一处理单元，用于在确定客户端登录本地后，指示该客户端在用户操作行为符合所述第一预设条件时，获取并返回该用户的用户识别信息；

解析单元，用于接收客户端返回的用户识别信息，并对该用户识别信息进行解析，获得用户标识ID；

第二处理单元，用于确定对应所述用户ID保存的用户属性信息符合所述第二预设条件时，对指定的业务相关数据进行更新。

一种互联网系统，包括若干网站服务器和应用服务器13，其中，

应用服务器，用于提供指定的业务服务，对用户的业务相关数据进行逻辑构造；

网站服务器，用于确定客户端登录本地后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息，以及在接收到该客户端返回的用户识别信息时，对该用户识别信息进行解析，以获得用户标识ID，并在确定对应所述用户ID保存的用户属性信息符合第二预设条件时，从所述应用服务器对指定的业务相关数据进行更新。

通过上述技术方案，网站服务器通过能够及时控制新注册用户和已注册用户的有效操作行为所导致的业务相关数据更新的频率，从而降低了整个系统的资源消耗和运行负荷，提高了系统的处理效率；另一方面，采用上述技术方案，针对原有系统的技术改动较小，业务耦合度为零，因此，不会对原有的系统造成明显影响，从而在一定程度上保障了用户体验，以及简化了后期维护流程。

附图说明

图1为本申请实施例中互联网网络体系架构图；

图2为本申请实施例中网站服务器功能结构图；

图3为本申请实施例中网站服务器进行数据更新流程图。

具体实施方式

在互联网系统中，为了提高数据更新流程的处理效率，降低数据更新流程的执行复杂度。本申请实施例中，网站服务器确定客户端登录本地后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息；所述网站服务器接收客户端返回的用户识别信息，并对该用户识别信息进行解析，获得用户标识(ID)；所述网站服务器确定对应所述用户ID保存的用户属性信息符合第二预设条件时，对指定的业务相关数据进行更新。

上述技术方案中，网站服务器可以通过在网页页面中嵌入指定标签，或者，也可以通过在响应消息中携带指定标识，来指示所述客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息。本申请实施例中，以第一种情况为例进行介绍。

本申请实施例中，为了对用户行为进行监测，需要在给用户提供的网页页面中嵌入用于探测用户行为的指令代码，例如，基于HTML的IMG标签，其代码内容可以设置为：

<img src＝http://events.triger.company.com width＝’0’height＝’0’/>

上述代码可以部署到登录用户有权访问的任何网页页面之中。本实施例中，由于采用了基于HTML的IMG标签，因此，根据HTML和当前网页浏览器的协议，上述代码将会和其他代码并行执行，并且由于上述代码中设定了WIDTH＝0和Height＝0，使得该代码不会对所在网页页面的外观造成任何影响，因而不会降低用户的使用感受。

下面结合附图，对本申请优选的实施方式进行详细说明。

参阅图1所示，本申请实施例中，互联网系统内包括若干网站服务器10客户端11和应用服务器13，其中，

应用服务器13，用于提供指定的业务服务，对用户的业务相关数据进行逻辑构造，所谓用户的业务相关数据有多种，例如，用户指定业务的标识信息，对用户指示进行处理后产生的操作数据等等。

网站服务器10，用于确定客户端11登录本地后，指示该客户端11在用户操作行为符合第一预设条件时，获取并向网站服务器10返回该用户的用户识别信息，以及在网站服务器10接收到该客户端11返回的用户识别信息时，对该用户识别信息进行解析，获得用户ID，并在确定对应所述用户ID保存的用户属性信息符合第二预设条件时，从所述应用服务器13对指定的业务相关数据进行更新。

参阅图2所示，本申请实施例中，网站服务器10包括存储单元100、第一处理单元101、解析单元102和第二处理单元103，其中，

存储单元100，用于保存第一预设条件和第二预设条件，以及对应用户ID设置的用户属性信息；

第一处理单元101，用于在确定客户端11登录本地后，指示该客户端11在用户操作行为符合所述第一预设条件时，获取并返回该用户的用户识别信息；

解析单元102，用于接收客户端11返回的用户识别信息，并对该用户识别信息进行解析，获得用户ID；

第二处理单元103，用于确定对应所述用户ID保存的用户属性信息符合所述第二预设条件时，对指定的业务相关数据进行更新。

基于上述系统架构，参阅图3所示，本申请实施例中，网站服务器10针对登录本地的用户进行数据更新的详细流程如下：

步骤300：接收用户通过客户端11发送的登录请求消息，该登录请求消息中携带用户ID和登录密码。

步骤310：根据获得的用户ID和登录密码对用户进行鉴权，并确认用户通过鉴权流程。

本申请实施例中，网站服务器10确认用户通过鉴权流程后，用户便可以请求浏览所需的网页页面了。

步骤320：将用户请求的网页页面发往客户端11，本申请实施例中，在发送给用户的网页页面中均含有IMG标签，用于指示客户端11在指定时机获取并返回用户识别信息(即，Cookie)。

本实施例中，各IMG标签的代码内容由管理人员预先在网络侧设置，网站服务器10可以根据各网页的页面内容预先获取对应的IMG标签嵌入至页面代码中，并在客户端11请求获取网页页面时，将相应的网页页面发送至客户端11。客户端11接收到含有IMG标签的网页页面后，对IMG标签进行代码解析，并根据解析结果确定IMG标签指示的返回用户标识信息的指定时机；所谓指定时候即是指用户对网页页面的浏览行为符合预设条件，此时客户端11将获取本地保存的用户识别信息，并将其发往网站服务器10，以触发网络侧后续处理流程。

本申请实施例中，上述预设条件可以根据实际应用环境预设。

例如，预设条件为：用户浏览网页页面的停留时间超过设定阈值时，获取用户识别信息。这样做，是为了在后续的处理流程中过滤掉大量无意继续浏览当前网页页面的用户，只针对部分能够影响网站服务器数据处理行为的用户数据进行处理，从而避免了系统资源的浪费。

又例如，预设条件为：用户点击某个特定网页元素时，获取点击该特定网页元素的用户的识别信息。这样做，可以专门针对该特定网页元素对应的某一业务下的用户提供相应的数据处理服务，而不必对所有的用户数据进行处理，从而提高了系统的处理效率，如，VIP客户。

又例如，用户初次在网站系统注册时，获取该用户的识别信息。

上述内容仅为举例，并不限制其他设置方式。

步骤330：接收客户端11返回的用户识别信息，并对该用户识别信息进行解析，以提取出用户ID。

实际应用中，网站技术通常都是采用Cookie保存用户身份信息，所以用户ID的提取即是指针对用户的Cookie进行解析识别。本申请实施例中，为了最大程度的降低Cookie解析流程对系统整体性能的影响，网站服务器10针对该流程的执行速度必须在设定时长内，否则，将会降低用户体验。如，网站服务器10针对当前处理的流程维护一计时器，当计时器记录的时长超过设定阈值时，向客户端11返回提示错误的信息，根据用户指示重新执行流程或者结束当前流程。

步骤340：根据提取出的用户ID判断该用户是否处于当前维护的用户队列中，若是，则执行步骤360；否则，执行步骤350。

本申请实施例中，网站服务器10针对已登录注册的用户维护一组队列，并定期对该队列进行更新，以明确用户的注册情况，以及用户上次登录网站的时间，便于在后续流程中更新其属性表，并将长时间未登录本地的用户从该队列中删除。

另一方面，本申请实施例中，网站服务器10针对已登录注册的用户均维护一属性表，该属性表中至少包含用户ID和向该用户发出通知的时间。例如，属性表的表项内容如表1或表2所示：

表1

用户ID	通知时间
		ID A	9:00
ID B	10::00
		......	......

表2

用户ID	通知时间
		ID A	距当前2小时
ID B	距当前1小时
		......	......

步骤350：对用户的业务相关数据进行更新，并根据提取的用户ID将用户添加至当前维护的用户队列中，同时将对应该用户设置的属性表中“通知时间”这一属性更新为当前的系统时间；接着，结束当前流程。

本申请实施例中，若提取的用户ID对应的用户未在当前维护的用户队列中，则表示该用户为新注册用户，或者，上一次登录时间距当前时间的时长超过设定阈值，因此，需要将其归入用户队列。

本申请实施例中，所谓“通知”，即是指通知相应的应用服务器13对用户的业务相关数据进行更新，以保证用户在网页页面中获得的业务信息的实时性。所谓对指定的业务相关数据进行更新，即是指按照预设规则准确调用相应的应用服务器13来完成用户的业务相关数据的更新，其具体实现方式为：

网站服务器10具有调用外部接口的功能，其作用包含但不限于以下两种：

1、维护外部接口的调用队列，其中，外部接口的属性包括被调用的应用服务器13的名称、端口号和采用的通信协议类型等等。

2、确保在接收到相关的通知消息时，能够正确调用上述队列中的所有外部接口。

应用服务器13对用户的业务相关数据进行更新时，需要重新根据自身的业务属性重新计算用户的业务相关数据，例如，若某应用服务器13的业务属性是向用户提供其联系人信息，则接收到网站服务器10发送的通知时，重新计算一遍相关用户的联系人信息，并将重新获得的最新的联系人信息通过网站服务器10呈现给客户端11。

这样，在系统运行过程中，用户的操作行为决定了其所需要使用的业务，那么网站服务器10就会定向至相应的应用服务器13来指示更新用户的业务相关数据。对于操作行为符合预设条件的用户，网站服务器10会立即调用相应的外部接口，从与用户操作行为相对应的应用服务器13获取用户最新的业务相关数据，并以网页信息的形式进行组织展现。另一方面，当有新的业务需求(即在系统中扩展出新的应用服务器13)时，网站服务器10根据系统定义的规范，将新业务对应的外部接口加入到本地维护的调用队列中即可，接着，再通过调用该外部接口指示对应的应用服务器13完成用户的业务相关数据的逻辑构造。

步骤360：根据提取出的用户ID获取对应该用户ID保存的属性表。

本申请实施例中，若提取的用户ID对应的用户已在当前维护的用户队列中，则网站服务器10会从进一步获取该用户的属性表，并提取其中的“通知时间”属性，以便后续处理。

步骤370：根据获得的属性表判断上一次向用户发出通知的时间与当前时间相距的时长量是否超过设定阈值，若是，则进行步骤380；否则，结束当前流程。

与步骤350记载的内容相同，本申请实施例中，所谓“通知”，即是指通知相应的应用服务器13对用户的业务相关数据进行更新，以保证用户在网页页面中获得的业务信息的实时性，那么，若根据用户的属性表确定上一次向用户发出通知的时间与当前时间相距的时长量超过设定阈值，则说明，用户当前浏览的网页页面中包含的业务信息已过期，需要重新进行更新，以保证业务信息的实时性。

步骤380：对用户的业务相关数据进行更新，并将该用户相应的属性表中“通知时间”这一属性更新为当前的系统时间。

通过上述实施例，网站服务器10通过维护的用户队列及队列中每个用户的属性表，能够及时控制新注册用户和已注册用户的有效操作行为所导致的业务相关数据更新的频率，从而降低了整个系统的资源消耗和运行负荷，提高了系统的处理效率。并且采用上述技术方案，针对原有系统的技术改动较小，业务耦合度为零，因此，不会对原有的系统造成明显影响，从而在一定程度上保障了用户体验，以及简化了后期维护流程。

基于上述实施例，下面以一个实际应用场景对上述技术方案进行详细说明。

假设网站服务器10支持的系统为：用户登录进入个人主页后，系统能够主动推荐与其存在相关性的其他用户作为联系人，即用户要求提供的业务相关信息为“联系人推荐信息”。而用户的实际需求为：希望联系人推荐信息尽量最新，但不要求完全实时。

那么，通常情况下，登录网站服务器10的用户群体在千万数量级以上，而一个完整的相关性计算通常需要数分钟。

现有技术下的实现方法是：将登录用户与所有其他用户之间的相关性全部计算一遍，再根据计算结果向用户呈现相关的联系人推荐信息。采用这种方法，当用户群体过于庞大时，执行一次相关性遍历计算往往需要很长的时间，而且计算出的很大一部分用户的推荐信息价值很低(如，这一部分用户并不经常登录网站服务器10)，这样就造成了大量系统资源的浪费，并且由于计算周期较长，也导致联系人推荐信息的实时性很差。

相应地，采用本实施例中提供的方法，网站服务器10在计算与登录用户存在相关性的其他用户时，根据用户的操作行为进行判断，在用户的操作行为符合预设条件时，再进行相关性的遍历计算。

例如：登录用户在网页页面的停留时间超过设定时长时，再进行相关性的遍历计算，这样，以避免登录用户无意长时间访问网页页面而触发不必要的相关性遍历计算，从而，有效避免了系统资源的浪费，降低了数据更新流程的执行复杂度，提高了系统的处理效率。

又例如：登录用户在网页页面执行特定操作时，再进行相关性的遍历计算，如，登录用户点击“服务支持”按钮进行业务信息咨询，那么，此时，网站服务器10可以执行相关性遍历计算，向其推荐所需的联系人；进一步地，网站服务器10还可以根据登录用户选择的业务内容(如，多媒体服务)，有针对性地对与该登录用户在多媒体服务方面存在相关性的用户进行遍历计算，这样，进一步避免了系统资源的浪费，提高了系统的处理效率，也提高了系统提供的联系人推荐信息的准确性。

显然，本领域的技术人员可以对本申请中的实施例进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请实施例中的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请中的实施例也意图包含这些改动和变型在内。

Claims (12)

1.一种数据更新的方法，其特征在于，包括：

网站服务器确定客户端登录后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息；

所述网站服务器接收客户端返回的用户识别信息，并对该用户识别信息进行解析，获得用户标识ID；

所述网站服务器确定对应所述用户ID保存的用户属性信息符合第二预设条件时，对指定的业务相关数据进行更新。

2.如权利要求1所述的方法，其特征在于，所述网站服务器通过在网页页面中嵌入指定标签，或者，通过在响应消息中携带指定标识，指示所述客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息。

3.如权利要求1或2所述的方法，其特征在于，所述第一预设条件为：用户浏览网页页面的停留时间超过设定阈值，或者，用户在网站系统初次注册。

4.如权利要求1或2所述的方法，其特征在于，所述第二预设条件为：对应所述用户ID保存的用户属性信息为空，或者，对应所述用户ID保存的用户属性信息指示上一次针对该用户进行业务相关数据更新的时间与当前时间相距的时长超过设定阈值。

5.如权利要求1或2所述的方法，其特征在于，所述网站服务器对指定的业务相关数据进行更新时，包括：通过预设的外部接口调用与用户操作行为相对应的应用服务器以获得用户最新的业务相关数据；再将获得的业务相关数据以网页信息的形式呈现给所述用户。

6.如权利要求1所述的方法，其特征在于，所述指定的业务相关数据包括：联系人推荐信息。

7.一种网站服务器，其特征在于，包括

第一处理单元，用于在确定客户端登录本地后，指示该客户端在用户操作行为符合所述第一预设条件时，获取并返回该用户的用户识别信息；

解析单元，用于接收客户端返回的用户识别信息，并对该用户识别信息进行解析，获得用户标识ID；

第二处理单元，用于确定对应所述用户ID保存的用户属性信息符合所述第二预设条件时，对指定的业务相关数据进行更新。

8.如权利要求7所述的网站服务器，其特征在于，所述第一处理单元通过在网页页面中嵌入指定标签，或者，通过在响应消息中携带指定标识，指示所述客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息。

9.如权利要求7或8所述的网站服务器，其特征在于，所述第二处理单元对指定的业务相关数据进行更新时，先通过预设的外部接口调用与用户操作行为相对应的应用服务器以获得用户最新的业务相关数据；再将获得的业务相关数据以网页信息的形式呈现给所述用户。

10.一种互联网系统，其特征在于，包括若干网站服务器和应用服务器13，其中，

应用服务器，用于提供指定的业务服务，对用户的业务相关数据进行逻辑构造；

网站服务器，用于确定客户端登录本地后，指示该客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息，以及在接收到该客户端返回的用户识别信息时，对该用户识别信息进行解析，获得用户标识ID，并在确定对应所述用户ID保存的用户属性信息符合第二预设条件时，从所述应用服务器13获取指定的业务相关数据并进行更新。

11.如权利要求10所述的互联网系统，其特征在于，所述网站服务器通过在网页页面中嵌入指定标签，或者，通过在响应消息中携带指定标识，指示所述客户端在用户操作行为符合第一预设条件时，获取并返回该用户的用户识别信息。

12.如权利要求10或11所述的互联网系统，其特征在于，所述网站服务器对指定的业务相关数据进行更新时，先通过预设的外部接口调用与用户操作行为相对应的应用服务器以获得用户最新的业务相关数据；再将获得的业务相关数据以网页信息的形式呈现给所述用户。

Images