CN110633299A

CN110633299A - 业务数据的缓存方法、装置、计算机设备及存储介质

Info

Publication number: CN110633299A
Application number: CN201910762976.5A
Authority: CN
Inventors: 覃甫俊; 刘平刚
Original assignee: Ping An Property and Casualty Insurance Company of China Ltd
Current assignee: Ping An Property and Casualty Insurance Company of China Ltd
Priority date: 2019-08-19
Filing date: 2019-08-19
Publication date: 2019-12-31
Anticipated expiration: 2039-08-19
Also published as: CN110633299B

Abstract

本申请实施例属于大数据存储技术领域，涉及一种业务数据的缓存方法，包括接收业务请求并跳转至与所述业务请求相关联的业务处理流程；在缓存数据库中为所述业务请求建立上下文对象；从所述业务处理流程对应的业务界面中提取业务数据；将所述业务数据存储至所述上下文对象中；当所述上下文对象中满足预设的删除条件时，删除所述上下文对象。本申请还提供一种业务数据的缓存装置、计算机设备及存储介质。本申请能够减少移动设备前端数据的缓存数据量，减少必要的流量消耗和移动设备内存消耗，降低网络依赖性，并避免了将过程数据存储到数据库中容易引发数据库拥堵甚至导致系统不可用的风险。

Description

业务数据的缓存方法、装置、计算机设备及存储介质

技术领域

本申请涉及大数据存储技术领域，尤其涉及一种业务数据的缓存方法、装置、计算机设备及存储介质。

背景技术

随着互联网技术的不断发展，各种服务性、娱乐性等网站出现，给人们的生活带来了极大的便利，但是用户登录各种网站会产生的大量的用户数据，例如，目前市面上车险移动端询价投保流程中，需要录入的用户数据比较多，包括车主、车辆、投保人、被保人、单证发票、配送地址、保单特约等信息。在生成车险投保单之前，需要做一系列的接口调用，包括续保检查，上年保单信息查询，车险查询，车辆信息查询，套餐查询，平台投保查询，车险报价、特约查询、验车状态查询、申请核保等，在此过程中也会产生大量的过程数据。

现有技术中，对于页面访问过程(如保险询价至生成车险投保单的过程)中，产生的从大量的过程数据的保存通常有两种方式，一种方式是保存在前端页面，另一种方式是保存在数据库。如果将过程数据保存在前端页面，则由于其网络依赖性较强，保存效率低下，并且会影响页面体验，导致用户体验比较差；如果保存在数据库，则会产生很多冗余数据并且降低性能，容易引发数据库拥堵甚至导致系统不可用的风险。

发明内容

本申请实施例的目的在于提出一种业务数据的缓存方法、装置、计算机设备及存储介质，用于解决现有数据的缓存网络依赖性较强，容易引发数据库拥堵甚至导致系统不可用的问题。

为了解决上述技术问题，本申请实施例提供一种业务数据的缓存方法，包括下述步骤：

接收业务请求并跳转至与所述业务请求相关联的业务处理流程；

在缓存数据库中为所述业务请求建立上下文对象；

从所述业务处理流程对应的业务界面中提取业务数据；

将所述业务数据存储至所述上下文对象中；

当所述上下文对象中满足预设的删除条件时，删除所述上下文对象。

进一步的，所述在缓存数据库中为所述请求建立上下文对象的步骤之后，所述方法还包括：

为所述上下文对象配置一个唯一的ID值；

将所述ID值与所述上下文对象的存储位置的对应关系存储到所述缓存数据库中。

进一步的，所述从业务处理流程对应的业务界面中提取业务数据的步骤具体包括：

根据所述业务界面关联的业务请求，获取所述业务请求的请求标识；

从所述业务界面中提取业务数据，并将所述业务数据与所述请求标识整合在一起构成所述业务数据。

进一步的，所述根据所述业务界面关联的业务请求，获取所述业务请求的请求标识的步骤，包括：

当所述业务页面为所述业务请求跳转的第一个业务界面时，直接从所述业务请求中获取请求标识；或者

当所述业务界面不是跳转的第一业务界面时，从上一跳转界面中获取所述业务请求的请求标识。

进一步的，所述将所述业务数据存储至所述上下文对象中，包括：

根据所述业务数据中的请求标识确定所述业务请求的上下文对象；

根据所述上下文对象的ID在所述缓存数据库中查找所述上下文对象的存储位置，并将所述业务数据存储到所述上下文对象中。

进一步的，所述预设的删除条件包括上下文对象的存储时长达到预设的有效时间或者完成所述业务请求，当所述预设的删除条件为上下文对象的存储时长达到预设的有效时间时，所述方法还包括：

在所述业务处理流程中，实时监测请求访问量；

当所述请求访问量达到预设阈值上限时，调低所述有效时间值；或者

当所述请求访问量达到预设阈值下限时，调高所述有效时间值。

进一步的，所述接收业务请求并跳转至与所述业务请求相关联的业务处理流程的步骤包括：

接收业务请求；

对所述业务请求进行验签；

验签通过后，跳转至与所述业务请求对应的页面。

为了解决上述技术问题，本申请实施例还提一种业务数据的缓存装置，其特征在于，包括：

接收模块，用于接收业务请求；

跳转模块，用于在接收到业务请求后跳转至与所述业务请求相关联的业务处理流程；

上下文对象建立模块，用于在缓存数据库中为所述业务请求建立上下文对象；

数据提取模块，用于从所述业务处理流程对应的业务界面中提取业务数据；

数据存储模块，用于将所述业务数据存储至所述上下文对象中；

删除模块，用于在所述上下文对象中满足预设的删除条件时，删除所述上下文对象。

为了解决上述技术问题，本申请实施例还提供一种计算机设备，采用了如下所述的技术方案：

包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时实现如上所述的业务数据的缓存方法的步骤。

为了解决上述技术问题，本申请实施例还提供一种计算机可读存储介质，采用了如下所述的技术方案：

所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的业务数据的缓存方法的步骤。

与现有技术相比，本申请实施例主要有以下有益效果：

在缓存数据库中为所述业务请求创建上下文对象，并将业务请求处理过程中产生的业务数据存储至所述上下文对象中，能够减少移动设备前端数据的缓存数据量，减少必要的流量消耗和移动设备内存消耗，降低网络依赖性；另外一方面，避免了将过程数据存储到数据库中容易引发数据库拥堵甚至导致系统不可用的风险。

附图说明

为了更清楚地说明本申请中的方案，下面将对本申请实施例描述中所需要使用的附图作一个简单介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请可以应用于其中的示例性系统架构图；

图2根据本申请的业务数据的缓存方法的一个实施例的流程图；

图3是根据本申请的业务数据的缓存装置的一个实施例的结构示意图；

图4是根据本申请的计算机设备的一个实施例的结构示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了使本技术领域的人员更好地理解本申请方案，下面将结合附图，对本申请实施例中的技术方案进行清楚、完整地描述。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture ExpertsGroup Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving PictureExperts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的业务数据的缓存方法一般由服务器，相应地，业务数据的缓存方法装置一般设置于服务器中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本申请的业务数据的缓存方法的一个实施例的流程图。所述的业务数据的缓存方法，包括以下步骤：

步骤201，接收业务请求并跳转至与所述业务请求相关联的业务处理流程。

在本实施例中，业务数据的缓存方法运行于其上的电子设备(例如图1所示的服务器)可以通过有线连接方式或者无线连接方式接终端的业务请求。需要指出的是，上述无线连接方式可以包括但不限于3G/4G连接、WiFi连接、蓝牙连接、WiMAX连接、Zigbee连接、UWB(ultra wideband)连接、以及其他现在已知或将来开发的无线连接方式。

实际应用中，以车险移动端询价为例，用户可以进入车险页面，在通过车险页面向询价服务器发送询价请求。询价服务器接收到请求后，跳转至询价页面，进行询价处理流程。

本实施例中步骤201可以包括如下步骤：

接收业务请求；

对所述业务请求进行验签；

验签通过后，跳转至与所述业务请求对应的页面。

实际应用中，验签的目的主要为了保证交互时数据的安全，它需要消息发送方对消息进行加签。

加签是指消息发送方(即发起业务请求的移动端)，对消息加签名。

验签是指接受消息方(业务处理系统)，验证签名是否正确。

一种可行的加签、验签的方案可以采用如下方法：

在加签时，用指定的hash算法,获取信息的hash值；用私钥,对hash值进行加密,输出加密串(也就是签名值)。

在验签时，对要签名的信息(也就是签名原文),用指定的hash算法,获取信息的hash值；用公钥信息,解密签名值,从中获取加密的hash串,和获取的hash值进行对比,一致则认为验签通过,不一致则不通过。

步骤202，在缓存数据库中为所述请求建立上下文对象。

实际应用中，每一个Web Project(网页项目)，运行时都部署在Tomcat(容器)下，称为一个应用。部署后，启动Tomcat时，Tomcat将为每一个应用创建一个对象，这个对象称之为上下文对象。

本实施例中，可以在redis缓存数据库中建立所述请求的上下文对象。

Redis是一个Key-value存储系统，通常被称为数据结构服务器，为描述方便，本发明实施例称其为redis缓存数据库。

本实施例中，上下文对象存储在redis缓存数据库。

本实施例中，步骤202之后，所述方法还包括：

为所述上下文对象配置一个唯一的ID值；

将所述ID与所述上下文对象的存储位置的对应关系存储到所述redis缓存数据库中。

实际应用中，业务处理流程涉及的页面可以只有一个页面，也可以有多个页面。当业务处理流程涉及多个页面时，要多次页面跳转。

以车险移动端询价为例，其涉及的页面可以包括用户信息收集页面、车险类型选择界面、费用评估结果反馈界面、合同签订页面等。这些页面会收集并产生大量的中间数据，由于其是由同一个请求触发的页面跳转，需要将其存储到通过一个对象中，因此需要为每个请求的上下文对象设置一个唯一的ID值，并存储到redis缓存数据库中(如可以设置一个专门的文件列表，存储ID值和上下文对象存储位置的对应关系)，方便查找。

步骤203，从所述业务处理流程对应的业务界面中提取业务数据。

本实施例中，步骤203可以包括：

本实施例中，本实施例中，所述根据所述业务界面关联的业务请求，获取所述业务请求的请求标识的步骤，可采用如下方法实现：

当所述业务页面为所述业务请求跳转的第一个业务界面时，直接从所述业务请求中获取请求标识；

实际应用中，当所述业务请求涉及多个业务界面时，需要进行多次页面跳转，也就需要进行多次数据提取，每次提取的业务数据不同，例如：

用户信息收集页面提取的数据包括用户姓名、联系方式、居住地等信息；

车险类型选择界面提取的数据包括车辆信息、车险类型等信息；

费用评估结果反馈界面提取的数据包括预处理的城市信息、机构开关、业务功能开关数据、渠道数据等数据；

合同签订页面提取的数据包括上述各反馈页面提取的数据。

从各个业务数据提取的业务数据均是由同一个业务请求触发的，因此需要将各业务页面提取的业务数据通过请求标识进行关联，将具有相同请求标识的数据存储到同一个上下文对象中。

实际应用中，在正式进入出单页面前，需要对提取的数据进行预处理，即需要把城市信息、机构开关、业务功能开关数据、渠道数据等数据进行初始化(即从数据库、系统配置文件中加载所述相关数据的值),然后存入redis缓存中，由于提取的数据比较多，关联性强，对提取的数据进行预处理，可以很好的提升系统运行效率。

具体的，城市信息主要用于购买保险后保单配送，包含具体的省市区街道等，这些城市信息和机构信息有一定的映射关系，需要事先校验用户选择的投保城市是否正确；

机构开关是指不同机构的个性化需求开关，例如不同的机构(如设置在深圳、海南、广西等地的机构)，他们会有很多不同的个性化需求，比如在深圳的机构需要双录，默认保单为电子，其他机构可能默认为纸质；在海南、广西的机构需要支付前需要验证码、实名认证等；类似的开关大概有上百个，进入投保流程页面前就要明确；

业务功能开关则跟业务相关，比如，某个渠道是否可以出纸质保单(北京必须电子)、是否可以出捆绑非车等；

渠道数据用于区分数据的渠道和来源，这些数据跟费用、业绩归属相关。

步骤204，将所述业务数据存储至所述上下文对象中。

本实施例中，步骤204包括如下步骤：

根据所述上下文对象的ID在所述redis缓存数据库中查找所述上下文对象的存储位置，并将所述业务数据存储到所述上下文对象中。

步骤205，当所述上下文对象满足预设的删除条件时，删除所述上下文对象。

实际应用中，预设的删除条件可以是上下文对象的存储时长达到预设的有效时间或者完成所述业务请求。

本实施例中，当所述预设的删除条件为上下文对象的存储时长达到预设的有效时间时，可以根据实际情况对预设的有效时间进行调整，方法如下：

在所述业务处理流程中，实时监测请求访问量；

当所述请求访问量达到预设阈值上限时，调低缓存的有限时间值；或者

当所述请求访问量达到预设阈值下限时，调高缓存的有限时间值。

实际应用中，通过实时监控请求访问量来调整缓存的有效时间可以保证系统的稳定高效。比如在双十一双十二访问高峰期，自动调低缓存最大时间值，来减少redis的缓存容量，保证系统稳定高效。

实际应用中，当预设的删除条件是完成所述业务请求时,可以通过判断是否生成了业务合同来确定所述业务流程是否完成。例如，车险询价请求业务，可以以生成保险合同为完成业务流程的标志。

本实施例中，在redis缓存数据库中为所述业务请求创建上下文对象，并将将业务请求处理过程中产生的业务数据存储至所述上下文对象中，能够减少移动设备前端数据的缓存数据量，减少必要的流量消耗和移动设备内存消耗，降低网络依赖性；另外一方面，避免了将过程数据存储到数据库中容易引发数据库拥堵甚至导致系统不可用的风险。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM)等。

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

进一步参考图3，作为对上述图2所示方法的实现，本申请提供了一种业务数据的缓存装置装的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图3所示，本实施例所述的一种业务数据的缓存装置包括：接收模块301、跳转模块302、上下文对象建立模块303、数据提取模块304、数据存储模块305及删除模块306。其中：

接收模块301，用于接收业务请求；

跳转模块302，用于在接收到业务请求后跳转至与所述业务请求相关联的业务处理流程；

上下文对象建立模块303，用于在缓存数据库中为所述业务请求建立上下文对象；

数据提取模块304，用于从所述业务界面中提取业务数据；

数据存储模块305，用于将所述业务数据存储至所述上下文对象中；

删除模块306，用于在所述上下文对象中满足预设的删除条件时，删除所述上下文对象。

在本实施例中，本实施例中业务数据的缓存装置还可以包括验签模块，用于对接收的业务请求对所述业务请求进行验签；

所述跳转模块302，还用于在验签通过后，跳转至与所述业务请求对应的页面。

验签是指接受消息方(业务处理系统)，验证签名是否正确。

一种可行的加签、验签的方案可以采用如下方法：

本实施例中，上下文对象建立模块303，还用于在redis缓存数据库中为所述业务请求建立上下文对象。

本实施例中，上下文对象存储在redis缓存数据库。

本实施例中，上下文对象建立模块303，还用于在建立上下文对象之后，为所述上下文对象配置一个唯一的ID值，并将所述ID与所述上下文对象的存储位置的对应关系存储到所述redis缓存数据库中。

本实施例中，数据提取模块304可以包括：

标识获取子模块，用于根据所述业务界面关联的业务请求，获取所述业务请求的请求标识；

业务数据提取子模块，用于从所述业务界面中提取业务数据；

整合子模块，用于将所述业务数据与所述请求标识整合在一起构成所述业务数据。

本实施例中，标识获取子模块还用于：

在所述业务页面为所述业务请求跳转的第一个业务界面时，直接从所述业务请求中获取请求标识；

在所述业务界面不是跳转的第一业务界面时，从上一跳转界面中获取所述业务请求的请求标识。

实际应用中，当所述业务请求涉及多个业务界面时，需要进行多次页面跳转，也就需要进行多次数据提取，每次提取的业务数据不同。

本实施例中，数据存储模块305，还包括：

确定子模块，用于根据所述业务数据中的请求标识确定所述业务请求的上下文对象；

位置查找子模块，用于根据所述上下文对象的ID在所述redis缓存数据库中查找所述上下文对象的存储位置；

存储子模块，用于将所述业务数据存储到所述上下文对象中。

实际应用中，删除模块306，还可以用于在上下文对象的存储时长达到预设的有效时间或者完成所述业务请求时，删除所述上下文对象。

本实施例中，当所述预设的删除条件为上下文对象的存储时长达到预设的有效时间时，所述删除模块306还包括：

存储时长判断子模块，用于判断所述上下文对象的存储时长是否达到预设的有效时间；

删除子模块，用于在所述存储时长达到预设的有效时间时，删除所述上下文对象。

所述装置还可以包括：

监测模块，用于实时监测请求访问量；

预设删除条件调整模块，用于在所述请求访问量达到预设阈值上限时，调低缓存的有限时间值，或者用于在所述请求访问量达到预设阈值下限时，调高缓存的有限时间值。

实际应用中，当预设的删除条件是完成所述业务请求时,删除模块306还包括：

判断子模块，用于判断是否生成了业务合同，若是，来确定所述业务流程已完成；

删除子模块，用于在业务合成生成后，删除所述上下文。

例如，车险询价请求业务，可以以生成保险合同为完成业务流程的标志。

为解决上述技术问题，本申请实施例还提供计算机设备。具体请参阅图4，图4为本实施例计算机设备基本结构框图。

所述计算机设备4包括通过系统总线相互通信连接存储器41、处理器42、网络接口43。需要指出的是，图中仅示出了具有组件41-43的计算机设备4，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable GateArray，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

所述计算机设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述计算机设备可以与用户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互。

所述存储器41至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器41可以是所述计算机设备4的内部存储单元，例如该计算机设备4的硬盘或内存。在另一些实施例中，所述存储器41也可以是所述计算机设备4的外部存储设备，例如该计算机设备4上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(FlashCard)等。当然，所述存储器41还可以既包括所述计算机设备4的内部存储单元也包括其外部存储设备。本实施例中，所述存储器41通常用于存储安装于所述计算机设备4的操作系统和各类应用软件，例如业务数据的缓存方法的程序代码等。此外，所述存储器41还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器42在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器42通常用于控制所述计算机设备4的总体操作。本实施例中，所述处理器42用于运行所述存储器41中存储的程序代码或者处理数据，例如运行所述业务数据的缓存方法的程序代码。

所述网络接口43可包括无线网络接口或有线网络接口，该网络接口43通常用于在所述计算机设备4与其他电子设备之间建立通信连接。

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有业务数据的缓存程序，所述业务数据的缓存程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的业务数据的缓存方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

显然，以上所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例，附图中给出了本申请的较佳实施例，但并不限制本申请的专利范围。本申请可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本申请的公开内容的理解更加透彻全面。尽管参照前述实施例对本申请进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本申请说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本申请专利保护范围之内。

Claims

1.一种业务数据的缓存方法，其特征在于，包括下述步骤：

在缓存数据库中为所述业务请求建立上下文对象；

从所述业务处理流程对应的业务界面中提取业务数据；

将所述业务数据存储至所述上下文对象中；

2.根据权利要求1所述的业务数据的缓存方法，其特征在于，所述在缓存数据库中为所述请求建立上下文对象的步骤之后，所述方法还包括：

为所述上下文对象配置一个唯一的标签ID值；

3.根据权利要求2所述的业务数据的缓存方法，其特征在于，所述从所述业务处理流程对应的业务界面中提取业务数据的步骤具体包括：

从所述业务界面中提取业务数据，并将所述业务数据与所述业务请求的请求标识整合在一起构成所述业务数据。

4.如权利要求3所述的业务数据的缓存方法，其特征在于，所述根据所述业务界面关联的业务请求，获取所述业务请求的请求标识的步骤，包括：

5.如权利要求3所述的业务数据的缓存方法，其特征在于，所述将所述业务数据存储至所述上下文对象中，包括：

6.如权利要求1所述的业务数据的缓存方法，其特征在于，所述预设的删除条件包括上下文对象的存储时长达到预设的有效时间或者完成所述业务请求，当所述预设的删除条件为上下文对象的存储时长达到预设的有效时间时，所述方法还包括：

在所述业务处理流程中，实时监测请求访问量；

7.如权利要求1至6任意一项所述的业务数据的缓存方法，其特征在于，所述接收业务请求并跳转至与所述业务请求相关联的业务处理流程的步骤包括：

接收业务请求；

对所述业务请求进行验签；

验签通过后，跳转至与所述业务请求对应的页面。

8.一种业务数据的缓存装置，其特征在于，包括：

接收模块，用于接收业务请求；

9.一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的业务数据的缓存方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的业务数据的缓存方法的步骤。