请求处理方法及系统、存储介质、电子设备与流程

1.本公开涉及互联网技术领域，具体涉及一种请求处理方法、请求处理系统、存储介质和电子设备。


背景技术：

2.随着互联网技术的发展，近年来软件的规模日益庞大，需要把复杂的系统划分成小的组成部分，为了使应用程序开发人员得以调用一组例程功能，而无须考虑其底层的源代码为何、或理解其内部工作机制的细节，所以设计了应用程序接口(application programming interface，api)。
3.大规模高并发场景下，通常采用数据缓存的方法提高api的处理速度和并发量，减少后端压力。第一类是把mysql、etcd等存储数据库中常用的字段缓存到redis、memcached等内存数据库中，利用内存数据库的高并发来对api的请求处理进行计算；第二类是在api请求侧把请求结果缓存，例如浏览器通过强缓存、协商缓存等方法减少与服务器的交互请求、减少服务器的负载。但是上述两类方法都存在一定的局限性，每次请求仍需要大量的查询和计算对初始数据进行组装，会造成重复计算问题，采用缓存计算结果的方式又难以保持数据同步和一致性。
4.需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
5.公开内容
6.本公开的目的在于提供一种请求处理方法、请求处理系统、存储介质和电子设备，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。
7.根据本公开的一个方面，提供一种请求处理方法，包括：
8.获取应用程序编程接口api的数据写入请求；
9.根据数据写入请求删除内存数据库中与api对应的字段，更新存储数据库内与api对应的字段；
10.根据更新后的字段，确定内存数据库中与字段对应的请求结果；
11.删除内存数据库中与字段对应的请求结果。
12.在本公开的一种示例性实施例中，根据更新后的字段确定内存数据库中与字段对应的请求结果，包括：
13.预先对多个api的数据写入请求导致的字段更新与字段对应的请求结果进行聚类分析，得到对应的关联关系；
14.根据关联关系确定内存数据库中与字段对应的请求结果。
15.在本公开的一种示例性实施例中，请求处理方法还包括：
16.在将更新后的字段缓存到内存数据库之前，设定预设时间内停止从内存数据库中读取字段。
17.根据本公开的一个方面，提供另一种请求处理方法，包括：
18.获取应用程序编程接口api的数据读取请求；
19.如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则读取api对应的请求结果；
20.如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，则计算api对应的请求结果；
21.将api对应的请求结果缓存到内存数据库中。
22.在本公开的一种示例性实施例中，计算api对应的请求结果，包括：
23.如果内存数据库中不存在api对应的字段，则将存储数据库中的api对应的字段缓存到内存数据库中；
24.根据api的数据读取请求对内存数据库中api对应的字段进行计算得到请求结果。
25.在本公开的一种示例性实施例中，请求处理方法还包括：
26.如果在限时取消缓存规则的预设时间内，将api对应的请求结果停止缓存到内存数据库中，限时取消缓存规则包括更新存储数据库中字段后，在预设时间内停止从内存数据库中读取字段；
27.如果在限时取消缓存规则的预设时间外，将api对应的请求结果缓存到内存数据库中。
28.根据本公开的一个方面，提供一种请求处理系统，包括：
29.业务处理逻辑模块：用于获取应用程序编程接口api的数据写入请求，根据数据写入请求删除内存数据库中与api对应的字段，更新存储数据库内与api对应的字段，删除内存数据库中与字段对应的请求结果。
30.内存数据库：用于存储api对应的字段和字段数据以及api对应的请求结果；
31.存储数据库：用于存储字段以及字段对应的数据；
32.api变化感知模块：用于根据更新后的字段，确定内存数据库中与字段对应的请求结果。
33.根据本公开的一个方面，提供另一种请求处理系统，包括：
34.业务处理逻辑模块：用于获取应用程序编程接口api的数据读取请求，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则读取api对应的请求结果，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，则计算api对应的请求结果，将api对应的请求结果缓存到内存数据库中；
35.内存数据库：用于存储api对应的字段和字段数据以及api对应的请求结果；
36.存储数据库：用于存储字段以及字段对应的数据；
37.api缓存管理：用于存储缓存列表。
38.根据本公开的一个方面，提供一种电子设备，包括：处理器；以及存储器，用于存储处理器的可执行指令；其中，处理器配置为经由执行可执行指令来执行上述任意一种方法。
39.根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任意一种方法。
40.本公开示例性实施例可以具有以下部分或全部有益效果：
41.在本公开的一实例实施方式所提供的请求处理方法中，根据api的数据请求，自动
识别api与存储数据库中字段的关系，将api对应的请求结果缓存到内存数据库中。一方面，在字段变化时以代码零侵入的方式即可完成请求结果的同步修改，保持数据的强一致性关系；另一方面，可以根据系统的请求状态决策是否对api进行缓存，在大规模场景下可以有效解决重复计算，能够减少服务端的数据查询和计算量，从而提升系统的整体性能。
42.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
43.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
44.图1示出了可以应用本公开实施例的一种请求处理方法的流程图；
45.图2示意性示出了根据本公开的一个实施例的请求处理方法的流程图；
46.图3示意性示出了根据本公开的另一个实施例的请求处理方法的流程图；
47.图4示意性示出根据本公开的一个实施例的日志数据图；
48.图5示出了可以应用本公开实施例的另一种请求处理方法的流程图；
49.图6示意性示出了根据本公开的一个实施例的具体场景下请求处理方法流程图；
50.图7示意性示出了根据本公开的一个实施例的具体场景下请求处理方法流程图；
51.图8示意性示出了根据本公开的另一个实施例的具体场景下请求处理方法流程图；
52.图9示意性示出了根据本公开的一个实施例的请求处理系统的示意图；
53.图10示意性示出了根据本公开的另一个实施例的请求处理系统的示意图；
54.图11示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
具体实施方式
55.现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
56.此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
57.大规模高并发场景下，通常采用数据缓存的方法提高api的处理速度和并发量，减少后端压力。存储数据库是指系统存储相对初始的数据，包括了系统内所有信息，内存数据库是指将数据放在内存中直接操作的数据库，比如在数据缓存时存储数据库相当于仓库，内存数据库相当于一种中转站。内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。第一类是把mysql、etcd等存储数据库中常用的字段缓存到redis、memcached等内存数据库中，利用内存数据库的高并发和快速查询能力降低持久化存储数据库的性能瓶颈；第二类是在api请求侧把请求结果缓存，例如浏览器通过强缓存、协商缓存等方法减少与服务器的交互请求、减少服务器的负载。但是就会有这样的问题出现，重复计算与数据不一致性。
58.内存数据库通常使用key-value的键值方式缓存相对初始的数据，对于汇聚查询及需要大量计算的api，每次请求仍需要大量的查询和计算对初始数据进行组装，会造成重复计算问题。相关技术会采用缓存计算结果的方式来解决上述问题，但同时会引入新的问题：需要熟悉业务代码，初始数据更新后能够同时修改聚合数据/计算结果，保证数据一致性；修改逻辑会造成现有业务代码的侵入；聚合数据/中间结果的缓存价值跟请求频率和并发性相关，需要根据系统的状态决策是否进行缓存。
59.相关技术方案中为了保持数据的一致性关系，根据实际业务场景有较多变种，本质上都是对字段的缓存，这里以“延时双删”举例。
60.延时双删策略是分布式系统中存储和缓存数据保持一致性的常用策略，下面从宏观上观察系统布局，了解数据一致性。由于多个节点间的数据异步操作，多个业务程序节点读写数据；redis读写分离，主从同步；mysql读写分离，主从同步。
61.其中数据工作的流程可以用以下步骤来概括：删除redis主库数据；服务节点修改mysql主库数据；服务节点使得当前业务处理等待一段时间，等redis和mysql主从节点数据同步成功；服务节点从redis主库删除数据；当前或其它服务节点读取redis从库数据，发现redis从库没有数据，从mysql从库读取数据，并写入redis主库。
62.下面详细描述api的数据写入请求中如何保持数据一致性。
63.基于此，在本示例实施例中，提供了一种请求处理方法，参考图1所示，该请求处理方法包括以下步骤：
64.步骤s110，获取应用程序编程接口api的数据写入请求；
65.步骤s120，根据数据写入请求删除内存数据库中与api对应的字段，更新存储数据库内与api对应的字段；
66.步骤s130，根据更新后的字段，确定内存数据库中与字段对应的请求结果；
67.步骤s140，删除内存数据库中与字段对应的请求结果。
68.在本公开的一实例实施方式所提供的请求处理方法中，根据api的数据请求，自动识别api与存储数据库中字段的关系，将api对应的请求结果缓存到内存数据库中。在字段变化时以代码零侵入的方式即可完成请求结果的同步修改，保持了数据的强一致性关系。
69.在获取到api的数据写入请求后，根据延时双删策略，数据工作的流程如图2所示，当api的数据写入请求通过负载均衡后进入业务处理模块，经过业务处理逻辑后，先删除内存数据库中的缓存数据，再更新存储数据库中的值，等待存储数据库与内存数据库之间数据的同步，在固定时间间隔后再次删除缓存数据，以保障内存数据库和存储数据库的数据
一致性。
70.本示例实施方式中，在延时双删策略的基础上增加了部分功能，以对延时双删策略进行优化，内存数据库中不仅有缓存数据，还有不同api的请求结果，请求结果是根据api请求信息中的要求对通过逻辑处理数据计算后封装的结果。
71.步骤s110中，获取应用程序编程接口api的数据写入请求。
72.本示例实施方式中，服务端获取从应用程序编程接口api传来的数据写入请求，获取该数据写入请求以后，对该数据写入请求进行分析。例如，客户端需要修改个人信息，进行操作后门户网站收到了修改个人信息api接口传来的数据写入请求。
73.步骤s120中，根据数据写入请求删除内存数据库中与api对应的字段，更新存储数据库内与api对应的字段。
74.本示例实施方式中，许多服务端把客户端经常使用的某些字段的数据都提前缓存到了内存数据库中。但是如果客户端发起了数据写入请求，需要修改存储数据库中某些字段的数据，那么此时内存数据库中的缓存数据便是无效数据，所以获取到数据写入请求后首先就需要删除内存数据库中与api对应的字段，防止其他线程进行调用，导致出现错误的请求结果。接着根据数据写入请求更新存储数据库内与api对应的字段。例如，客户端需要修改个人信息中的年龄从20到21，那么就先将内存数据库中的缓存年龄字段删除，然后再去存储数据库中的修改年龄字段中的数据为21。在修改过程中如果有其他请求来调用年龄字段的话，那么就会发现内存数据库中没有了该字段的缓存数据，只能去存储数据库中重新查询，这样就保持了数据的一致性。
75.还有，可以根据客户端的业务需求设置更新规则，比如每次相同的api的写入请求只能对该api对应的字段数据进行单次累加(比如每次加一)。本公开对更新规则的具体规则内容不做限制。在配置更新规则之后，利用该更新规则对存储数据库中该api对应的字段数据进行更新。
76.步骤s130，根据更新后的字段，确定内存数据库中与字段对应的请求结果。
77.本示例实施方式中，由于内存数据库中还存在该字段对应的请求结果，比如有一个api的请求结果是对年龄和身高进行计算得到一个生长关系度，此时由于年龄字段被改变，所以该api的请求结果就会发生变化。于是需要根据更新后的字段去自动寻找对应的请求结果，可以通过如图3中的步骤来使字段自动寻找到对应请求结果。
78.步骤s310，预先对多个api的数据写入请求导致的字段更新与字段对应的请求结果进行聚类分析，得到对应的关联关系。
79.本示例实施方式中，聚类(clustering)是按照某个特定标准(如距离)把一个数据集分割成不同的类或簇，使得同一个簇内的数据对象的相似性尽可能大，同时不在同一个簇中的数据对象的差异性也尽可能地大，是一种无监督学习(unsupervised learning)方法。数据聚类方法主要可以分为划分式聚类方法(partition-based methods)、基于密度的聚类方法(density-based methods)、层次化聚类方法(hierarchical methods)等。
80.本示例实施方式中，如图4所示，可以预先根据日志中的api请求返回数据以及字段的修改记录进行训练。例如，根据k-means算法的流程如下：预将api请求返回数据以及字段分为k组，则随机选取k个对象作为初始的聚类中心，然后计算每个对象与各个种子聚类中心之间的距离，把每个对象分配给距离它最近的聚类中心。聚类中心以及分配给它们的
对象就代表一个聚类。每分配一个样本，聚类的聚类中心会根据聚类中现有的对象被重新计算。这个过程将不断重复直到满足某个终止条件。终止条件可以是没有(或最小数目)对象被重新分配给不同的聚类，没有(或最小数目)聚类中心再发生变化，误差平方和局部最小。
81.步骤s320，根据关联关系确定内存数据库中与字段对应的请求结果。
82.本示例实施方式中，若同一api的两次请求结果相同，则这之间修改的字段与该api无相关性；若两次请求结果不同，则这之间修改的字段与该api可能相关(频率越高相关性越大)。例如可以通过watch机制来查询修改的字段，其作用是一个对象或者数据节点可能会被多个客户端监控，当对应事件被触发时，会通知这些对象或客户端。
83.此外，还可以通过关联规则算法来寻找api请求返回数据以及字段的修改记录中的关联关系。比如apriori算法、fp-growth算法等，通过不同api请求返回数据以及字段的修改记录中挖掘出频繁项集，再计算置信度与支持度，然后找出api请求返回数据以及字段的修改记录之间的联系。
84.步骤s140，删除内存数据库中与字段对应的请求结果。
85.本示例实施方式中，对于已经改变的字段数据其对应在内存数据库中的请求结果也会发生改变，为了确保数据一致性，也需要将字段对应的请求结果进行删除，因为另一api的数据读取请求可能在读取缓存时会出现错误。
86.本示例实施方式中，在删除内存数据库中与字段对应的请求结果后，在将更新后的字段缓存到内存数据库，以计算新的请求结果。服务端将更新后的字段缓存到内存数据库，以使后面的api的数据读取请求来读取缓存数据，然后快速计算请求结果以返回客户端。
87.此外，在将更新后的字段缓存到内存数据库之前，设定预设时间内停止从内存数据库中读取字段。mysql和redis主从节点数据不是实时同步的，同步数据需要时间，在此期间，其它服务节点直接去存储数据库中直接读取最新的数据，保证了数据的一致性。
88.上述实施方式中讲述了api的数据写入请求，下面讲述api的数据读取请求。
89.基于此，在本示例实施例中，提供了一种请求处理方法，参考图5所示，该请求处理方法包括以下步骤：
90.步骤s510，获取应用程序编程接口api的数据读取请求；
91.步骤s520，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则读取api对应的请求结果；
92.步骤s530，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，则计算api对应的请求结果；
93.步骤s540，将api对应的请求结果缓存到内存数据库中。
94.在本公开的一实例实施方式所提供的请求处理方法中，可以根据系统的请求状态决策是否对api进行缓存，在大规模场景下可以有效解决重复计算，能够减少服务端的数据查询和计算量，从而提升系统的整体性能。
95.在获取到api的数据读取请求后，根据延时双删策略，数据工作的流程如图6所示，当api的数据读取请求通过负载均衡后进入业务处理模块，经过业务处理逻辑后，先在内存数据库中查找数据，如果没有查询到所需数据，再到存储数据库中查询，并将结果缓存到内
存数据库。
96.例如，在k8s(kubernetes)集群中，pod是所有业务类型的基础，也是k8s管理的最小单位级，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，pod是它们的逻辑主机，pod包含业务相关的多个应用容器。查询一个中等规模集群pod的资源分配情况，假如其中有50个namespace(命名空间)，每个namespace中有100个pod，按照上述这种方式查询的话，需要5000次查询，同时对数据的封装和计算也需要消耗资源。
97.本示例实施方式中，在延时双删策略的基础上增加了部分功能，以对延时双删策略进行优化，增加了缓存管理，可以通过订阅或者根据请求频率和并发阈值的方式设定需要缓存的api请求结果，并提供缓存查询及限时取消缓存查询功能。
98.步骤s510，获取应用程序编程接口api的数据读取请求。
99.本示例实施方式中，服务端获取从应用程序编程接口api传来的数据读取请求，获取该数据读取请求以后，对该数据读取请求进行分析。例如，客户端需要查询个人信息，进行查询操作后门户网站收到了查询个人信息api接口传来的数据写入请求。
100.步骤s520，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则读取api对应的请求结果。
101.本示例实施方式中，缓存列表是根据请求频率和并发阈值的方式设定需要缓存的api。比如，根据门户网站中经常会出现查询天气api的数据读取请求，该api的请求频率较高，然后服务端就会根据该api的请求频率自动设定到缓存列表里。然后下一次获取相同api的请求，会先去查看该缓存列表中是否包括该api的请求，然后再去内存数据库中进行查询，如果有api对应的请求结果，那么直接将api请求结果发送回客户端。当然，也可以根据需求设定某些api设定在缓存列表中。
102.步骤s530，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，则计算api对应的请求结果。
103.本示例实施方式中，如果缓存列表中有该api的请求，但是去查询内存数据库时却没有该api对应的请求结果，那么就需要计算该api对应的请求结果。比如，一个api对应的请求是需要获取a+b的结果，所以这时需要先获取到a与b对应的数据。
104.如果内存数据库中不存在api对应的字段，则将存储数据库中的api对应的字段缓存到内存数据库中。例如，获取a+b的结果，这时在存储数据库中找到a与b字段对应的数据，然后缓存到内存数据库中。
105.根据api的数据读取请求对内存数据库中api对应的字段进行计算得到请求结果。如api的数据读取请求是获取a+b的结果，在内存数据库对a与b的结果进行相加，然后得到结果。
106.步骤s540，将api对应的请求结果缓存到内存数据库中。
107.本示例实施方式中，将api对应的请求结果缓存到内存数据库中，这样下一个相同api的请求到来时，先查询缓存列表，然后在内存数据库中直接获取到请求结果直接就返回客户端了，有效解决重复计算，能够减少服务端的数据查询和计算量，从而提升系统的整体性能。
108.例如，在k8s集群中，查询一个中等规模集群pod的资源分配情况，假如其中有50个namespace(命名空间)，每个namespace中有100个pod，按照上述这种方式查询的话，仅需要1次查询。
109.此外，设置一个限时取消缓存规则，该规则可以是更新存储数据库中字段后，在预设时间内停止从内存数据库中读取字段。这时为了防止获取的请求结果是旧的计算结果。如果在限时取消缓存规则的预设时间内，将api对应的请求结果停止缓存到内存数据库中。如果在限时取消缓存规则的预设时间外，将api对应的请求结果缓存到内存数据库中。字段和api对应请求结果缓存本质上的差异在于省去了中间过程的数据查询及计算。因此不消耗服务端的查询、计算、网络传输等资源消耗。
110.下面结合具体应用场景对本示例实施方式中的上述请求处理方法应用于请求处理过程中。
111.参考图7所示，获取一个api的数据写入请求后，通过负载均衡后进入业务逻辑处理模块，然后在内存数据库中删除该api涉及字段缓存，更新存储数据库中的字段。接着通知api变化感知模块，api变化感知模块根据api与该字段的映射关系，得到该字段的改变会影响的缓存请求结果，api与该字段的映射关系由api与字段分析模块预先对存储数据库中的数据进行训练得到。缓存请求结果已发生改变，因此不可用也需要删除，为保持数据强一致性，设定间隔时间内不从内存数据库读取数据。在将更新后的字段缓存到内存数据库后，再删除该字段缓存。
112.参考图8所示，获取一个api的数据读取请求后，通过负载均衡后进入api缓存管理模块进行查询，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则返回api对应的请求结果。如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，先去内存数据库中拿缓存字段，内存数据库中也不存在的情况下，去存储数据库将字段数据缓存到内训数据库，然后计算api对应的请求结果，再将api对应的请求结果缓存到内存数据库中，最后返回api对应的请求结果。
113.在本公开的一实例实施方式所提供的请求处理方法中，根据api的数据请求，自动识别api与存储数据库中字段的关系，将api对应的请求结果缓存到内存数据库中。一方面，在字段变化时以代码零侵入的方式即可完成请求结果的同步修改，保持数据的强一致性关系；另一方面，可以根据系统的请求状态决策是否对api进行缓存，在大规模场景下可以有效解决重复计算，能够减少服务端的数据查询和计算量，从而提升系统的整体性能。
114.应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
115.进一步的，本示例实施方式中还提供了一种请求处理系统。
116.参考图9，请求处理系统包括业务处理逻辑模块901、内存数据库902、存储数据库903，api变化感知模块904，其中：
117.业务处理逻辑模块：用于获取应用程序编程接口api的数据写入请求，根据数据写入请求删除内存数据库中与api对应的字段，更新存储数据库内与api对应的字段，删除内存数据库中与字段对应的请求结果；
118.内存数据库：用于存储api对应的字段和字段数据以及api对应的请求结果；
119.存储数据库：用于存储字段以及字段对应的数据；
120.api变化感知模块：用于根据更新后的字段，确定内存数据库中与字段对应的请求结果。
121.参考图10，请求处理系统包括业务处理逻辑模块,1001、内存数据库1002、存储数据库1003，api缓存管理1004，其中：
122.业务处理逻辑模块：用于获取应用程序编程接口api的数据读取请求，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中存在api对应的请求结果，则读取api对应的请求结果，如果缓存列表中包括api对应的数据读取请求结果且内存数据库中不存在api对应的请求结果，则计算api对应的请求结果，将api对应的请求结果缓存到内存数据库中；
123.内存数据库：用于存储api对应的字段和字段数据以及api对应的请求结果；
124.存储数据库：用于存储字段以及字段对应的数据；
125.api缓存管理：用于存储缓存列表。
126.图11示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
127.需要说明的是，图11示出的电子设备的计算机系统1100仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
128.如图11所示，计算机系统1100包括中央处理单元(cpu)1101，其可以根据存储在只读存储器(rom)1102中的程序或者从存储部分1108加载到随机访问存储器(ram)1103中的程序而执行各种适当的动作和处理。在ram 1103中，还存储有系统操作所需的各种程序和数据。cpu 1101、rom 1102以及ram 1103通过总线1104彼此相连。输入/输出(i/o)接口1105也连接至总线1104。
129.以下部件连接至i/o接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至i/o接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。
130.特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(cpu)1101执行时，执行本技术的方法和装置中限定的各种功能。
131.作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现本公开方法所示的各个步骤等。
132.需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
133.附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
134.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。