业务数据的获取方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种业务数据的获取方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，5G时代的来临，互联网的出现给现代生活带来了极大的便利，越来越多的企业可以通过使用系统业务平台在线对多种业务进行处理，为用户带来便捷。特别是在一些诸如银行等涉及到群体性用户的大型系统中，其所承载的相关资料数据往往数以亿计，如何才能快速而准确的搜索到有效数据已经成为了这些行业中的重要难题。传统的业务数据的获取方式中，通过遍历查询服务器数据库中不同维度下的数据，实现数据的过滤和访问。

然而，目前业务数据的获取方式中，通常基于HTTP接口去实时读取数据库的数据，再由服务端经过关键词的过滤、排序后，将符合搜索条件的结果返回至客户端进行展示，但频繁访问数据库会带来高并发相关的性能瓶颈，尤其是在网络环境较差或者数据量较大的情况下，容易导致业务数据的获取效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高业务数据的获取效率的业务数据的获取方法、装置、计算机设备和存储介质。

一种业务数据的获取方法，所述方法包括：

获取用户发起的数据搜索请求；所述数据搜索请求中包含搜索条件；

根据所述搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合所述搜索条件的搜索结果；所述基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据；

将所述搜索结果显示在浏览器界面中。

在其中一个实施例中，所述获取用户发起的数据搜索请求之前，所述方法还包括：

向业务服务器发起异步数据获取请求；所述异步数据获取请求中携带账套标识；

接收所述业务服务器根据所述账套标识，返回的基础资料数据；

将所述基础资料数据存储至所述客户端本地缓存器中。

在其中一个实施例中，所述方法还包括：

接收长连接服务器通过长连接通道推送的通知消息；

获取所述通知消息的消息类型；

根据所述消息类型，获取对应的变更数据，并将所述变更数据更新至所述客户端本地缓存器中。

在其中一个实施例中，所述方法还包括：

响应于用户的变更操作，将变更操作对应的数据上传至业务服务器；

所述接收长连接服务器通过长连接通道推送的通知消息，包括：

接收长连接服务器通过长连接通道推送的通知消息，所述通知消息是所述业务服务器发送给长连接服务器的，所述通知消息为所述业务服务器在监听到数据变更时，确定所述数据变更的类型，并根据所述数据变更的类型，所生成携带有数据变更类型的通知消息。

在其中一个实施例中，所述长连接通道的建立方式，包括：

向长连接服务器发送长连接请求；所述长连接请求中携带已协商的秘钥、加密方式和频道管理方式；

接收所述长连接服务器根据所述已协商的秘钥、加密方式和频道管理方式，返回的与所述客户端建立长连接通道的确认信息。

在其中一个实施例中，所述客户端设置有心跳检查方式；

所述方法还包括：

通过所述心跳检查方式定期检查各个节点的情况；

当检查出现异常情况时，将所述异常情况上报至服务器，以指示所述服务器切换至传统模式搜索数据。

在其中一个实施例中，所述通过所述心跳检查方式定期检查各个节点的情况包括：

将数据库操作的时间戳进行比对，通过轮询方式对指定的节点端口进行访问，得到对应的访问结果；

根据所述访问结果，判定所述节点端口是否出现异常。

一种业务数据的获取装置，所述装置包括：

获取模块，用于获取用户发起的数据搜索请求；所述数据搜索请求中包含搜索条件；

搜索处理模块，用于根据所述搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合所述搜索条件的搜索结果；所述基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据；

显示模块，用于将所述搜索结果显示在浏览器界面中。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

获取用户发起的数据搜索请求；所述数据搜索请求中包含搜索条件；

根据所述搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合所述搜索条件的搜索结果；所述基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据；

将所述搜索结果显示在浏览器界面中。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

获取用户发起的数据搜索请求；所述数据搜索请求中包含搜索条件；

根据所述搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合所述搜索条件的搜索结果；所述基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据；

将所述搜索结果显示在浏览器界面中。

上述业务数据的获取方法、装置、计算机设备和存储介质，通过获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件，根据搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果，基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据，将搜索结果显示在浏览器界面中。由此使得，无需频繁的与服务端交互，也不依赖于服务端的数据查询能力，基于浏览器的业务缓存对象，实时查询无需依赖不稳定的网络环境，利用浏览器的语言脚本在本地缓存器中高效执行查询，能够提升用户实时搜索的效率，以最高效的方式获取到用户实际需要搜索的结果，极大的提高了业务数据的获取效率。

附图说明

图1为一个实施例中业务数据的获取方法的应用环境图；

图2为一个实施例中业务数据的获取方法的流程示意图；

图3为一个实施例中将基础资料数据存储至客户端本地缓存器中步骤的流程示意图；

图4为一个实施例中将变更数据更新至客户端本地缓存器中步骤的流程示意图；

图5为一个实施例中客户端、业务服务器和长连接服务器之间处理业务数据的流程示意图；

图6为一个实施例中长连接用户变更业务数据时的服务调用时序图；

图7为一个实施例中业务数据的获取装置的结构框图；

图8为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的业务数据的获取方法，可以应用于如图1所示的应用环境中。其中，客户端102通过网络与业务服务器104通过网络进行通信。客户端102获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件，客户端102根据搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果；基础资料数据是预先从业务服务器104下载并存储在本地缓存器中的业务数据，客户端102将搜索结果显示在浏览器界面中。其中，客户端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，业务服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种业务数据的获取方法，以该方法应用于图1中的客户端为例进行说明，包括以下步骤：

步骤202，获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件。

各个企业可以通过采用统一的业务管理信息平台，将企业内部以及企业外部供应链上所有的资源与信息进行统一的管理，这种集成能够消除企业内部因部门分割造成的各种信息隔阂与信息孤岛，例如，开发人员可以采用微服务架构，围绕着业务领域组件来创建不同业务功能的应用，这些应用可独立地进行开发、管理和更新，在分散的组件中使用微服务云架构和平台，能够使部署、管理和服务功能交付变得更加简单。BBOC(Brower-basedBusiness Object Cache)是指基于浏览器的业务对象缓存，BBOC对用户的电脑配置要求、网络要求都不高，常规的电脑都可以支撑。本申请中可以基于浏览器的业务对象缓存，实现快速有效的获取用户需要的业务数据。

具体的，客户端可以获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件。即当用户通过触发操作在浏览器中发起数据搜索请求时，则客户端可以获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件。其中，客户端或称为用户终端，是指与服务器相对应，为用户提供本地服务的程序。除了一些只在本地运行的应用程序之外，一般安装在普通的客户机上，需要与服务端互相配合运行。客户端可以包括DNS客户端(DNS是域名系统即Domain Name System的缩写)、web客户端以及移动客户端等。例如，移动客户端以手机为例，手机客户端就是可以在手机终端运行的软件。数据搜索请求是指用户根据不同需求在不同业务场景系统中发起的与业务单据对应的业务数据搜索请求。例如，在进行录单操作时，用户需要查询与不同业务单据对应的商品信息。搜索条件是指用户输入的一个或者多个标签信息的组合，用于筛选出目标信息。

步骤204，根据搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果，基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据。

客户端获取用户发起的数据搜索请求之后，客户端可以根据数据搜索请求中包含的搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果。其中，基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据。语言脚本是指客户端自带的编程语言脚本，例如，js语言脚本。基础资料数据是指与业务单据相关的业务数据。

具体的，用户可以通过在浏览器网页中输入用户名和密码的方式，登录特定场景的业务系统中，用户可以通过app(Application，应用程序)客户端或web客户端即web浏览器发起特定的数据获取请求，业务服务系统即业务服务器可以接收到用户通过客户端发送的数据获取请求，并根据该数据获取请求中的标识信息，从数据库拉取对应的基础资料数据返回至客户端。客户端接收到业务服务器返回的基础资料数据后，可以存储至本地缓存器中。进一步的，当用户通过触发操作，发起数据搜索请求时，则客户端可以获取用户发起的数据搜索请求，并根据数据搜索请求中包含搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果。例如，客户端根据数据搜索请求中包含搜索条件，利用js语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果。

步骤206，将搜索结果显示在浏览器界面中。

客户端根据数据搜索请求中的搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果之后，客户端可以直接将搜索结果显示在浏览器界面中，以方便用户快速查看。其中，用户可以预先设置自定义的显示方式，例如平铺展示或者列表展示等，可以理解的是，本申请中的将搜索结果显示在浏览器界面中的方式不限于平铺展示或者列表展示，还可以包括其他的方式。

传统的业务数据的获取方式中，通常基于HTTP接口去实时读取数据库的数据，再由服务端经过关键词的过滤、排序后，将符合搜索条件的结果返回至客户端进行展示，频繁建立HTTP请求通道不仅会带来高并发相关的性能瓶颈，同时也不利于系统的网络安全稳定，尤其是在网络环境较差或者用户使用的客户端配置较差的环境下，容易导致业务数据的获取效率较低。

而本实施例中，通过获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件，根据搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果，基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据，将搜索结果显示在浏览器界面中。由此使得，无需频繁的与服务端交互，也不依赖于服务端的数据查询能力，基于浏览器的业务缓存对象，实时查询无需依赖不稳定的网络环境，利用浏览器的语言脚本在本地缓存器中即可高效执行查询，能够提升用户实时搜索的效率，以最高效的方式获取到用户实际需要搜索的结果，极大的提高了业务数据的获取效率。

在一个实施例中，如图3所示，获取用户发起的数据搜索请求之前，该方法还包括将基础资料数据存储至客户端本地缓存器中的步骤，具体包括：

步骤302，向业务服务器发起异步数据获取请求，异步数据获取请求中携带账套标识。

步骤304，接收业务服务器根据账套标识，返回的基础资料数据。

步骤306，将基础资料数据存储至客户端本地缓存器中。

客户端获取用户发起的数据搜索请求之前，客户端可以将拉取到的基础资料数据存储至客户端本地缓存器中。具体的，当用户登录客户端以后，客户端可以向业务服务器发起异步数据获取请求，异步数据获取请求中携带账套标识。客户端接收业务服务器根据账套标识，返回的基础资料数据，将基础资料数据存储至客户端本地缓存器中。

其中，异步数据获取请求是指数据获取请求可以采用异步的方式。账套标识是指用于标识唯一的账套信息，租户信息中可以包含不同的账套信息，账套信息中可以包含不同的用户信息。业务系统中可以根据不同的企业类型创建对应的租户信息，租户之间的业务数据是完全隔离的，业务数据可以包括业务服务数据、工单数据、组织机构数据等。针对同一个租户，业务系统将该租户对应的用户管理中心和应用管理中心进行分区，用户管理中心使用统一的一套组织机构、角色信息和用户信息，即统一设置的组织机构、角色和用户等数据，是可以在同一租户中的各部门所共用的。租户的不同部门即不同账套可以通过登录管理账号，在应用管理中心界面创建该部门自己的业务服务。各个租户可以创建属于自己组织机构框架下的不同角色的用户以及不同场景的业务应用服务。

例如，当用户登录客户端以后，客户端可以向服务端发起异步无阻塞(静默)的请求去拉取对应的基础资料数据，客户端可以根据预设的对称或非对称加密方式，将拉取到的基础资料数据进行压缩、加密后，存储到客户端本地的缓存器中，以供后续查询使用。传统的基于HTTP接口实时读取数据库数据的方式中，浏览器基于http请求的通道有6通道，频繁建立HTTP请求通道容易导致前置请求会阻塞其他请求的运行，而本实施例中，基于浏览器的业务缓存对象，实时查询时无需依赖不稳定的网络环境，实时查询在浏览器的js脚本高效执行，即使在十万当量数据下，响应速度也能达到数百毫秒级别。通过发起异步无阻塞(静默)的请求去拉取对应的基础资料数据，不会影响网页其他请求的正常加载，为后续加快首屏展示提供了支撑，同时也只有在同步数据或者拉取数据时才需要网路条件支撑，无需频繁的与服务端交互，也不依赖于服务端的数据查询能力，能够有效提升用户实时搜索的效率。

在一个实施例中，该方法还包括响应于用户的变更操作，将变更操作对应的数据上传至业务服务器的步骤。具体的，用户后续在业务系统中进行变更操作时，(可能是多个客户端，例如多账套的场景)即当用户通过触发操作，触发基础资料的变更，客户端响应于用户的变更操作，将变更操作对应的数据上传至业务服务器。其中，多账套的场景是指一个业务系统可以同时有多个账套，每个账套的客户端均可以对业务系统中的数据进行变更操作。变更操作的类型可以包括新增、修改、删除、批量新增、批量修改以及批量删除。例如，用户可以对某商品信息进行批量新增操作，客户端响应于用户的批量新增操作，将批量新增操作对应的数据上传至业务服务器。当业务服务器监听到对应的基础资料(商品信息)变更时，业务服务器根据变更的情况，判断出变更的类型为批量新增操作，生成对应的通知消息，并将通知消息(包含消息类型为增量更新)发送至长连接服务器，使得长连接服务器通过长连接通道推送通知消息至对应的客户端，以指示客户端对客户端本地缓存器中的数据进行相应的更新。由此使得，通过业务服务器实时监听基础资料数据的状态，当监听到基础资料数据变更时，能够及时向长连接服务器发送对应的通知消息，并通过长连接服务器推送至对应客户端，从而保证了客户端本地缓存器中数据的准确性、实时性和安全性。

在一个实施例中，如图4所示，该方法还包括将变更数据更新至客户端本地缓存器中的步骤，具体包括：

步骤402，接收长连接服务器通过长连接通道推送的通知消息。

步骤404，获取通知消息的消息类型。

步骤406，根据消息类型，获取对应的变更数据，并将变更数据更新至客户端本地缓存器中。

当业务服务器监听到基础资料数据变更时，业务服务器根据变更的情况，生成对应的通知消息，并将通知消息(包含消息类型)发送至长连接服务器。长连接服务器的消息队列会实时消费由各个业务服务端节点发送的消息，并把这些消息推送到各个对应的长连接客户端，以使得客户端根据接收到消息的消息类型，通过api的方式去增量获取对应的变更信息，并根据变更信息，更新缓存器中存储的数据。其中，消息队列(Message queue，简称为MQ)是在消息的传输过程中保存消息的容器。消息队列可以部署在云平台上，主要提供消息的接收和发送，当面对大量任务信息时，消息队列可以对消息进行削峰平谷。

具体的，客户端接收长连接服务器通过长连接通道推送的通知消息。进一步的，客户端获取接收到的通知消息的消息类型。客户端根据消息类型，获取对应的变更数据，并将变更数据更新至客户端本地缓存器中。其中，消息类型可以包括增量更新和全量变更。由此使得，通过增量获取变更信息的方式，能够实现数据多端同步，节省更多时间成本，同时也降低了服务负载，减少了宕机的情况，保证了稳定的服务。

在一个实施例中，接收长连接服务器通过长连接通道推送的通知消息的步骤，包括：

接收长连接服务器通过长连接通道推送的通知消息，通知消息是业务服务器发送给长连接服务器的，通知消息为业务服务器在监听到数据变更时，确定数据变更的类型，并根据数据变更的类型，所生成携带有数据变更类型的通知消息。

长连接服务器的消息队列会实时消费由各个业务服务端节点发送的消息，并把这些消息推送到各个对应的长连接客户端。具体的，客户端接收长连接服务器通过长连接通道推送的通知消息，该通知消息是业务服务器发送给长连接服务器的，通知消息为业务服务器在监听到数据变更时，确定数据变更的类型，并根据数据变更的类型，所生成携带有数据变更类型的通知消息。其中，业务服务器实时监听操作动作，即业务服务器对影响结果的操作进行实时监听，当业务服务器监听到业务数据变更时，通过建立分析模型，判定业务数据变更的基本类型，再整理数据包，最后向长连接服务器发送数据包，生成对应的消费类型消息。由此使得，通过将客户端与长连接服务器建立稳定的长连接通道，同时通过业务服务器实时监听基础资料的变更，能够使得客户端实时更新信息的功能增强，保证了客户端本地缓存器中数据的准确性、实时性和安全性。

在其中一个实施例中，长连接通道的建立方式的步骤，包括：

向长连接服务器发送长连接请求，长连接请求中携带已协商的秘钥、加密方式和频道管理方式。

接收长连接服务器根据已协商的秘钥、加密方式和频道管理方式，返回的与客户端建立长连接通道的确认信息。

当用户登录客户端以后，客户端向服务端发起异步无阻塞(静默)的请求去拉取对应的基础资料数据，并将拉取到的基础资料数据存储到客户端本地之后，客户端可以向长连接服务器发送长连接请求，长连接请求中携带已协商的秘钥、加密方式和频道管理方式。客户端接收长连接服务器根据已协商的秘钥、加密方式和频道管理方式，返回的与客户端建立长连接通道的确认信息。其中，长连接服务可以是独立部署在其他服务器上的，本申请中的长连接服务器是一个高可靠的长连接消息服务系统，基于生产者-消费者的模式设计，支持消息队列、高并发等特性。各个服务端消息内部做合并处理，采用生产-消费模式，推送到消息队列给客户端处理。客户端在单位时间内收到大量消息也会进行合并后处理，每个客户端只有一个socket单例，以此提高客户端实际处理消息的吞吐能力。此外，当网络波动时，长连接通道可能会断开，客户端会按照预设规则自动进行长连接重连操作。当长连接断开时后，客户端会按一个递增时间区间不断尝试重连，重连超过预设阈值次数(例如10次)，如果依然无法连上，则开关切换到旧模式，走全量拉取数据的模式，以保证数据的准确性。

本实施例中，长连接服务器与客户端建立唯一的长连接通道，涉及一个房间层概念的设计，目的是为了保证客户的唯一性，即长连接服务器会根据密钥、加密方式、频道等要素，生成一个json文件在长连接服务器中进行统一管理。本实施例中，通过发起与长连接服务相关的长连接(websocket)通道请求，根据已协商的秘钥、加密方式、频道管理等信息，与各个客户端建立唯一的通道(uid)，以便后续客户端能够实时接收消息推送，从而保证了客户端本地缓存器中数据的准确性、实时性和安全性。

在一个实施例中，客户端设置有心跳检查方式，该方法还包括将异常情况上报至服务器的步骤，具体包括：

通过心跳检查方式定期检查各个节点的情况。

当检查出现异常情况时，将异常情况上报至服务器，以指示服务器切换至传统模式搜索数据。

基于BBOC的长连接推送服务，系统整体的链路较长，需要协调众多节点，故设置了心跳检测机制，当链路出现问题时，可以切换至旧模式以保证服务可用，同时也可以及时上报节点异常情况至业务服务器总部排查问题根源。具体的，客户端可以通过心跳检查方式定期检查各个节点的情况，当检查出现异常情况时，将异常情况上报至服务器，以指示服务器切换至传统模式搜索数据。例如，当心跳检查接口挂断，会忽视这次检查，当超过预设阈值次数(例如10次)检查失败，则客户端统计上报异常并尝试切换旧模式，在此状态下服务依然可以继续保持运行。由此使得，当出现异常情况时，能够及时上报，并且保证服务的不间断，采用了切换旧模式的方式，保证整个系统的高可用性。

在其中一个实施例中，通过心跳检查方式定期检查各个节点的情况的步骤，包括：

将数据库操作的时间戳进行比对，通过轮询方式对指定的节点端口进行访问，得到对应的访问结果。

根据访问结果，判定节点端口是否出现异常。

客户端可以通过心跳检查方式定期检查各个节点的情况。具体的，客户端可以通过将数据库操作的时间戳进行比对，通过轮询方式对指定的节点端口进行访问，得到对应的访问结果。进一步的，客户端可以根据访问结果，判定节点端口是否出现异常。例如，客户端可以通过api轮询方式对服务端指定的端口进行访问，得到对应的访问结果。客户端可以根据访问结果，判定节点端口是否出现异常。由此使得，当出现异常情况时，能够及时上报，并且保证服务的不间断，保证整个系统的高可用性。

在一个实施例中，如图5所示，为客户端、业务服务器和长连接服务器之间处理业务数据的流程示意图。其中，业务服务器中部署有基础资料服务和监听器。客户端本地部署有缓存器。消息推送Long服务部署在长连接服务器中。具体的，用户登录客户端以后，客户端通过Api服务拉取对应的基础资料数据，并写入缓存中。进一步的，客户端向消息推送Long服务发送请求，与消息推送Long服务建立对应的长连接通道。当用户在录单搜索商品数据时，客户端可以获取用户发起的数据搜索请求，根据数据搜索请求中包含的搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果，即客户端将缓存内搜索结果对应的搜索数据展示在浏览器界面中，以供用户快速查看，完成录单操作。基于各个客户端缓存器中的数据，由客户端自身的脚本语言去高效地过滤、匹配、排序出符合要求的搜索内容，使得搜索更加高效。

进一步的，当业务服务器的监听器监听到基础资料变更时，则生产不同消息类型的消息发送至消息推送Long服务，消息推送Long服务可以消费不同类型的消息，并推送至各个同频客户端。其中，同频客户端是指基于同一个长连接通道接收推送消息的客户端，例如，同一个账套下的不同用户对应的客户端。客户端根据接收到的不同类型的推送消息，采用拉对齐的方式获取缓存数据的变更。其中，拉对齐是指缓存在各个浏览器的数据可能存在一定差异，例如，如果A客户端更新了数据，那么B客户端也需要实时更新数据保持一致，这个保持一致的过程就是拉对齐。客户端会多次尝试拉对齐，当api接口偶发异常时，客户端会进行预设次数(例如三次)尝试获取业务数据的请求，直到成功，确保拉取基础资料对齐的准确性，若api接口彻底挂断，则客户端会记录并上报触发时间以及请求信息。由此，实现了高并发、高可用、可监控的业务数据获取方案，使得用户搜索流畅度更高，用户即输即查，开单更加高效。

此外，客户端根据预设的模型，可以采用增量和全量两种方式更新浏览器本地缓存中数据，比如，单个商品新增，那么客户端可以采用增量更新，如果批量商品新增，那么客户端可以采用全量更新本地缓存数据。客户端更新浏览器本地缓存中数据之后，客户端可以通过心跳检查方式，定期检查数据对齐以及链路闭环的情况，当检查出现异常情况时，将异常情况上报至服务器，以指示服务器切换至传统模式处理数据。由此使得，基于各个客户端缓存器中的数据，由客户端自身的脚本语言去高效地过滤、匹配、排序出符合要求的搜索内容，不需要请求网络，将查询服务器后台数据库所需的时间成本下滑至客户端浏览器自身，实现了更加高效搜索的效率，从而极大的提高了业务数据的获取效率。

在一个实施例中，如图6所示，为长连接用户变更业务数据时的服务调用时序图。其中，BD service即基础资料服务管理，用于统一管理变更数据，可以部署在业务服务器中；RabbitMQ是一个开源的消息代理和消息队列服务器，用于处理消息部署在长连接服务器中；tf-apprise是指业务消息通知，用于统一向长连接服务下发请求，可以部署在业务服务器中；Long service即长连接服务，用于保证实时数据的一种服务，可以部署在长连接服务器中。其中，长连接服务(WebSocket)支持高并发的长连接推送服务，完整的消息队列管理机制，具有优秀的数据吞吐能力。Web缓存器SDK支持跨越多个终端的直出技术集成，具有高可用、扩展性好、兼容良好的特点。

具体的，用户可以对基础资料数据进行变更操作，即当BD service监测到基础资料变更时，同步发送变更消息至消息队列服务器，消息队列服务器可以异步消费消息，通过业务消息通知将通知消息推送至长连接服务，使得长连接服务通过长连接通道推送通知消息至对应的客户端，客户端可以根据接收到的推送消息，从BD service即业务服务器中请求获取对应的基础资料，业务服务器根据请求返回对应的增量基础资料。此外，开发人员也可以在长连接服务队列处理消息的基础上，衔接不同业务的具体操作逻辑，从而将消息推送给客户端时，则无需客户端再次通过api去查询接口这一步骤，即长连接服务需要集成更多的业务操作逻辑。本申请中解耦业务与推送服务的关联逻辑，更易于维护，可监控的各个节点保证了整体系统的稳定性，能够实现数据多端同步，节省更多时间成本。

应该理解的是，虽然图1-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1-6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图7所示，提供了一种业务数据的获取装置，包括：获取模块702、搜索处理模块704和显示模块706，其中：

获取模块702，用于获取用户发起的数据搜索请求，数据搜索请求中包含搜索条件。

搜索处理模块704，用于根据搜索条件，利用自身语言脚本对客户端本地缓存器中的基础资料数据进行搜索处理，得到符合搜索条件的搜索结果，基础资料数据是预先从业务服务器下载并存储在本地缓存器中的业务数据。

显示模块706，用于将搜索结果显示在浏览器界面中。

在一个实施例中，该装置还包括：发送模块、接收模块和存储模块。

发送模块用于向业务服务器发起异步数据获取请求，异步数据获取请求中携带账套标识。接收模块用于接收业务服务器根据账套标识，返回的基础资料数据。存储模块用于将基础资料数据存储至客户端本地缓存器中。

在一个实施例中，该装置还包括：更新模块。

接收模块还用于接收长连接服务器通过长连接通道推送的通知消息。获取模块还用于获取通知消息的消息类型。更新模块用于根据消息类型，获取对应的变更数据，并将变更数据更新至客户端本地缓存器中。

在一个实施例中，该装置还包括：上传模块。

上传模块用于响应于用户的变更操作，将变更操作对应的数据上传至业务服务器。接收模块还用于接收长连接服务器通过长连接通道推送的通知消息，通知消息是业务服务器发送给长连接服务器的，通知消息为业务服务器在监听到数据变更时，确定数据变更的类型，并根据数据变更的类型，所生成携带有数据变更类型的通知消息。

在一个实施例中，发送模块还用于向长连接服务器发送长连接请求，长连接请求中携带已协商的秘钥、加密方式和频道管理方式。接收模块还用于接收长连接服务器根据已协商的秘钥、加密方式和频道管理方式，返回的与客户端建立长连接通道的确认信息。

在一个实施例中，该装置还包括：检查模块。

检查模块用于通过心跳检查方式定期检查各个节点的情况；当检查出现异常情况时，将异常情况上报至服务器，以指示服务器切换至传统模式搜索数据。

在一个实施例中，该装置还包括：访问模块和判定模块。

访问模块用于将数据库操作的时间戳进行比对，通过轮询方式对指定的节点端口进行访问，得到对应的访问结果。判定模块用于根据访问结果，判定节点端口是否出现异常。

关于业务数据的获取装置的具体限定可以参见上文中对于业务数据的获取方法的限定，在此不再赘述。上述业务数据的获取装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种业务数据的获取方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述各个方法实施例的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。