CN113778909A - 一种缓存数据的方法和装置 - Google Patents

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的缓存数据的方法的主要流程的示意图。作为本发明的一个实施例，如图1所示，所述缓存数据的方法可以包括：

步骤101，接收并解析业务请求，得到业务编码和请求内容参数。

服务端接收客户端发送的业务请求，并对其进行解析，从而得到业务编码和请求内容参数。在本发明的实施例中，所述请求内容参数由查询条件拼接而成，比如在快递查询的业务场景中，请求内容参数包括手机号和时间段，又比如在天气查询的业务场景中，请求内容参数包括城市名和时间段。

步骤102，根据所述业务编码和所述请求内容参数，从缓存中获取业务数据或者通过调用所述业务编码对应的接口逻辑以获取业务数据，并返回所述业务数据。

解析得到业务编码和请求内容参数之后，根据所述业务编码和所述请求内容参数从缓存中获取对应的业务数据，或者，通过调用业务编码对应的接口逻辑，从而获取对应的业务数据，然后将所述业务数据返回至客户端。

可选地，根据所述业务编码和所述请求内容参数，从缓存中获取业务数据或者通过调用所述业务编码对应的接口逻辑以获取业务数据，包括：根据所述业务编码和所述请求内容参数，生成业务请求标识；判断缓存中是否存在所述业务请求标识；若是，则从所述缓存中获取所述业务请求标识对应的业务数据；若否，则根据所述请求内容参数调用所述业务编码对应的接口逻辑，以获取业务数据。为了较快地获取业务数据，首先判断缓存中是否存在业务数据，如果存在，则直接从缓存中获取，如果不存在，则通过调用接口逻辑来获取业务数据。在缓存中，业务请求标识和业务数据以键值对方式存储，因此通过判断缓存中是否存在所述业务请求标识，就可以判断是否存在对应的业务数据。

可选地，根据所述业务编码和所述请求内容参数，生成业务请求标识，包括：将所述业务编码和所述请求内容参数拼接成业务请求信息；采用信息摘要算法计算所述业务请求信息的摘要值，将所述摘要值作为业务请求标识。为了生成唯一的业务请求标识(busi_key)，本发明实施例首先将所述业务编码和所述请求内容参数拼接成业务请求信息，然后采用信息摘要算法计算所述业务请求信息的摘要值(即业务请求标识)。由于采用信息摘要算法计算业务请求标识，不但能保证业务请求标识的唯一性，还能保证业务编码和请求内容相同的业务请求，其业务请求标识也会相同，以标识同一业务请求，方便后续步骤统计这些业务请求的请求量和/或平均处理时长。可选地，可以采用MD5(Message-DigestAlgorithm 5，信息-摘要算法5)计算业务请求标识，以标识同一业务请求。

可选地，将所述业务编码和所述请求内容参数拼接成业务请求信息，包括：获取所述业务编码对应的接口名，将所述接口名和所述请求内容参数拼接成业务请求信息。在该实施例中，将接口名和请求参数内容拼接成业务请求信息，然后采用信息摘要算法计算所述业务请求信息的摘要值，将所述摘要值作为业务请求标识。无论是业务编码还是接口名，本发明实施例对此不作限制。

步骤103，根据所述业务请求和所述业务请求的处理时长生成消息，通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长。

对于每个业务请求，将业务数据返回至客户端之后，服务端根据所述业务请求和所述业务请求的处理时长生成消息，然后通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长。

可选地，所述消息的内容包括所述业务编码、所述请求内容参数、所述业务请求标识、所述消息的生成时间戳和所述业务请求的处理时长。在本发明的实施例中，消息的内容可以包括业务编码、请求内容参数、业务请求标识、生成该消息的时间戳和业务请求的处理时长。需要指出的是，业务请求的处理时长既包括从缓存中获取业务数据的时长，也包括通过调用接口逻辑获取业务数据的时长。可选地，所述消息的内容还可以包括业务描述，用于指示业务请求对应的业务数据是从缓存中获取的，还是通过调用接口逻辑获取的。

可选地，通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长，包括：将所述消息发送至消息中间件；从所述消息中间件中获取消息，并消费所述消息；根据所述消息的生成时间戳，将所述消息放入对应的时间窗口中；当到达所述时间窗口的结束时间时，计算所述时间窗口内的所述业务请求标识对应的请求量和/或平均处理时长；将所述业务请求对应的所述业务请求标识、所述业务编码、所述请求内容参数、所述业务请求标识对应的请求量和/或平均处理时长写入索引表中。在本发明的实施例中，消息的生产者可以将消息发送至MQ消息中间件，流处理框架(比如Flink)从消息中间件中获取消息，并消费消息，并通过流处理框架实时计算每个业务请求在各个时间窗口内请求量和/或平均处理时长。

具体地，流处理框架消费消息，从而获得所述业务编码、所述请求内容参数、所述业务请求标识(busi_key)、所述消息的生成时间戳和所述业务请求的处理时长。接着，所述流处理框架根据消息的生成时间戳，将消息放入对应的时间窗口中。每当到达时间窗口的结束时间，计算该时间窗口内的各个busi_key对应的请求量和/或平均处理时长，也就是以busi_key为维度，统计每个busi_key在该时间窗内的请求量和/或平均处理时长。最后，所述流处理框架将各个业务请求对应的busi_key、业务编码、请求内容参数、该busi_key对应的请求量和/或平均处理时长写入存储引擎的索引表中。因此，索引表中以busi_key为维度，存储各个busi_key对应的业务编码、请求内容参数、请求量和/或平均处理时长。可选地，还可以存储各个busi_key对应的总处理时长。

以时间窗口1分钟为例，统计各个busi_key在该时间窗口内的业务编码、请求内容参数、总处理时长、请求量、平均处理时长。其中，总处理时长就是将相同的busi_key对应的业务请求的处理时长相加，平均处理时长就是将总处理时长除以请求量。例如，在某一个时间窗口内，某一个busi_key的请求量为50条，则将这50条业务请求的处理时长相加，作为总处理时长，将总处理时长除以50即为平均处理时长。

可选地，本发明实施例实时地将各个业务请求对应的busi_key、业务编码、请求内容参数、该busi_key对应的请求量和/或平均处理时长写入ElasticSearch的索引表中，ElasticSearch可以实现准实时的数据存取(秒级延时)，而且ElasticSearch对于十亿级数据可以实现秒级查询统计，性能较高。可选地，也可以使用doris、clickhouse等作为替代ElasticSearch的存储引擎。

步骤104，判断所述业务请求在预设时间窗口内的请求量和/或平均处理时长是否满足预设业务规则，若是，则执行步骤105，若否，则结束。

在本发明的实施例中，业务规则可以预先设定，比如请求量前100，或者，处理时长前100，或者，请求量大于10条/秒，或者，处理时长大于5秒，等等。

步骤105，异步调用所述业务编码对应的接口逻辑以获取业务数据，将所述业务数据存储到所述缓存中。

为了动态地实现缓存，本发明实施例基于业务请求在预设时间窗口内的请求量和/或平均处理时长来决定是否将该业务请求对应的业务数据存储到缓存中。由于业务请求在预设时间窗口内的请求量和/或平均处理时长是动态的，因此写入缓存的业务数据也是动态的。

经过一个时间窗的时间(可以按照小时或者分钟划分时间窗)后，以业务请求标识(busi_key)为维度，统计每个busi_key在该时间窗内的请求量和/或平均处理时长，对于每个busi_key，判断其该时间窗内的请求量和/或平均处理时长是否满足预设业务规则；若是，则异步调用对应的接口逻辑以获取业务数据，并将所述业务数据存储到所述缓存中。

可选地，判断所述业务请求在预设时间窗口内的请求量和/或平均处理时长是否满足预设业务规则；若是，则异步调用所述业务编码对应的接口逻辑以获取业务数据，并将所述业务数据存储到所述缓存中，包括：定时地从所述索引表中获取满足预设业务规则的所述业务请求；将所述请求内容参数拼接成调用任务，执行所述调用任务，以调用所述业务编码对应的接口逻辑，从而获取业务数据；将所述业务请求标识及其对应的所述业务数据存储到所述缓存中。可以通过定时任务定时地从(一般是10秒到1分钟执行一次，时间是可配置的)从所述索引表中获取满足预设业务规则的各个业务请求，针对获取的每个业务请求，将请求内容参数拼接成调用任务，然后执行调用任务，以调用各个业务编码对应的接口逻辑，从而获取各个业务请求标识对应的业务数据；最后将各个业务请求标识及其对应的业务数据序列化后存储到缓存中。

可选地，将所述业务请求标识及其对应的所述业务数据存储到所述缓存中，包括：根据所述业务请求标识生成对应的缓存标识；将所述缓存标识以及所述业务请求标识对应的所述业务数据存储到所述缓存中，并设置所述缓存标识的有效周期；其中，所述缓存标识的有效周期是定时周期的1-5倍。可选地，可以根据一定的规则生成业务请求标识busi_key对应的缓存标识redis_key，比如在busi_key前面和/或后面添加标识，一个busi_key对应一个redis_key，两者是一一对应关系。

为防止redis_key无法实时更新，本发明实施例对每个缓存标识设置有效周期。如果缓存标识的有效周期过短，会很容易穿透，过长又不能保证业务数据是最新的，可选地，缓存标识的有效周期是定时周期的1.5倍、2倍、2.5倍或者4倍等，这样既可以保证缓存不被穿透，又可以保证缓存中的业务数据是最新的。

redis_key可以在超过有效周期后自动失效，那么业务再次请求的时候还是通过调用接口查询实时数据，这样能够保证用户获取到的业务数据是最新的。比如某个busi_key之前是请求量前100，过了一会就不是了，这个时候定时任务就不会去更新这个redis_key对应的业务数据了，但是在redis一直存着这个redis_key，所以用户再次查到的就可能是很久之前的业务数据。如果设置了有效周期，这个redis_key就会自动失效，这样用户再次请求就会去调接口，从而获取最新的业务数据。

需要指出的是，如果缓存中存储的是redis_key及其对应的业务数据，那么在步骤102中查询缓存时，则需要将busi_key转换成redis_key，通过redis_key去查找对应业务数据。

根据上面所述的各种实施例，可以看出本发明实施例通过若业务请求在预设时间窗口内的请求量和/或平均处理时长满足预设业务规则，则调用业务编码对应的接口逻辑以获取业务数据，将业务数据存储到缓存中的技术手段，解决了现有技术中只能静态地实现缓存的技术问题。本发明实施例通过计算各个业务请求在预设时间窗口内的请求量和/或平均处理时长，判断是否对业务请求对应的业务数据进行缓存，从而动态地实现缓存，保证在高并发场景下满足业务需求。

图2是根据本发明一个可参考实施例的缓存数据的方法的主要流程的示意图。作为本发明的又一个实施例，如图2所示，所述缓存数据的方法可以包括：

步骤201，接收并解析业务请求，得到业务编码和请求内容参数。

步骤202，将所述业务编码和所述请求内容参数拼接成业务请求信息。

步骤203，采用信息摘要算法计算所述业务请求信息的摘要值，将所述摘要值作为业务请求标识。

由于采用信息摘要算法计算业务请求标识，不但能保证业务请求标识的唯一性，还能保证业务编码和请求内容相同的业务请求，其业务请求标识也会相同，以标识同一业务请求，方便后续步骤统计这些业务请求的请求量和/或平均处理时长。

步骤204，判断缓存中是否存在所述业务请求标识；若是，则执行步骤205；若否，则执行步骤206。

步骤205，从所述缓存中获取所述业务请求标识对应的业务数据。

步骤206，根据所述请求内容参数调用所述业务编码对应的接口逻辑，以获取业务数据。

为了较快地获取业务数据，首先判断缓存中是否存在业务数据，如果存在，则直接从缓存中获取，如果不存在，则通过调用接口逻辑来获取业务数据。在缓存中，业务请求标识和业务数据以键值对方式存储，因此通过判断缓存中是否存在所述业务请求标识，就可以判断是否存在对应的业务数据。

步骤207，根据所述业务请求和所述业务请求的处理时长生成消息。

对于每个业务请求，将业务数据返回至客户端之后，服务端根据所述业务请求和所述业务请求的处理时长生成消息，所述消息的内容包括所述业务编码、所述请求内容参数、所述业务请求标识、所述消息的生成时间戳和所述业务请求的处理时长。

步骤208，通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长。

流处理框架消费消息，从而获得所述业务编码、所述请求内容参数、所述业务请求标识(busi_key)、所述消息的生成时间戳和所述业务请求的处理时长，然后计算出在预设时间窗口内各个busi_key对应的请求量和/或平均处理时长。

步骤209，判断所述业务请求在预设时间窗口内的请求量和/或平均处理时长是否满足预设业务规则；若是，则执行步骤210；若否，则结束。

步骤210，调用所述业务编码对应的接口逻辑以获取业务数据，将所述业务数据存储到所述缓存中。

另外，在本发明一个可参考实施例中缓存数据的方法的具体实施内容，在上面所述缓存数据的方法中已经详细说明了，故在此重复内容不再说明。

图3是根据本发明另一个可参考实施例的缓存数据的方法的主要流程的示意图。作为本发明的另一个实施例，如图3所示，所述缓存数据的方法可以包括：

步骤301，接收并解析业务请求，得到业务编码和请求内容参数。

步骤302，根据所述业务编码和所述请求内容参数，生成业务请求标识。

步骤303，判断缓存中是否存在所述业务请求标识；若是，则执行步骤304；若否，则执行步骤305。

步骤304，从所述缓存中获取所述业务请求标识对应的业务数据。

步骤305，根据所述请求内容参数调用所述业务编码对应的接口逻辑，以获取业务数据。

步骤306，根据所述业务请求和所述业务请求的处理时长生成消息，并将所述消息发送至消息中间件。

对于每个业务请求，将业务数据返回至客户端之后，服务端根据所述业务请求和所述业务请求的处理时长生成消息，所述消息的内容包括所述业务编码、所述请求内容参数、所述业务请求标识、所述消息的生成时间戳和所述业务请求的处理时长。

步骤307，从所述消息中间件中获取消息，并消费所述消息。

流处理框架从所述消息中间件中获取消息并消费消息，从而获得所述业务编码、所述请求内容参数、所述业务请求标识(busi_key)、所述消息的生成时间戳和所述业务请求的处理时长。接着，所述流处理框架根据消息的生成时间戳，将消息放入对应的时间窗口中。

步骤308，根据所述消息的生成时间戳，将所述消息放入对应的时间窗口中。

流处理框架根据消息的生成时间戳，将消息放入对应的时间窗口中。

步骤309，当到达所述时间窗口的结束时间时，计算所述时间窗口内的所述业务请求标识对应的请求量和/或平均处理时长。

每当到达时间窗口的结束时间，流处理框架计算该时间窗口内的各个busi_key对应的请求量和/或平均处理时长，也就是以busi_key为维度，统计每个busi_key在该时间窗内的请求量和/或平均处理时长。其中，总处理时长就是将相同的busi_key对应的业务请求的处理时长相加，平均处理时长就是将总处理时长除以请求量。

步骤310，将所述业务请求对应的所述业务请求标识、所述业务编码、所述请求内容参数、所述业务请求标识对应的请求量和/或平均处理时长写入索引表中。

最后，所述流处理框架将各个业务请求对应的busi_key、业务编码、请求内容参数、该busi_key对应的请求量和/或平均处理时长写入存储引擎的索引表中。

步骤311，定时地从所述索引表中获取满足预设业务规则的所述业务请求。

定时任务定时地从所述索引表中获取满足预设业务规则的业务请求。

步骤312，将所述请求内容参数拼接成调用任务，执行所述调用任务，以调用所述业务编码对应的接口逻辑，从而获取业务数据。

针对获取的每个业务请求，将请求内容参数拼接成调用任务，然后执行调用任务，以调用各个业务编码对应的接口逻辑，从而获取各个业务请求标识对应的业务数据。

步骤313，将所述业务请求标识及其对应的所述业务数据存储到所述缓存中。

另外，在本发明另一个可参考实施例中缓存数据的方法的具体实施内容，在上面所述缓存数据的方法中已经详细说明了，故在此重复内容不再说明。

图4是根据本发明再一个可参考实施例的缓存数据的方法的主要流程的示意图。作为本发明的再一个实施例，如图4所示，所述缓存数据的方法可以包括：

接口服务端接收并解析客户端发送的业务请求，得到业务编码、请求内容参数和缓存描述(用于指示是否需要走缓存)；然后根据业务编码和请求内容参数生成唯一的业务请求标识busi_key。

接口服务端根据业务请求中携带的缓存描述确定是否需要走缓存；如果需要走缓存，则根据busi_key查询缓存中是否存在对应的业务数据；如果存在，则向客户端返回缓存中的业务数据；如果不存在，则调用业务编码对应的接口逻辑，以获取对应的业务数据，并向客户端返回所述业务数据。如果不需要走缓存，则直接调用业务编码对应的接口逻辑，以获取对应的业务数据，并向客户端返回所述业务数据。

向客户端返回业务数据之后，接口服务端将业务编码、请求内容参数、busi_key、消息的生成时间戳和业务请求的处理时长拼装成MQ消息，然后将该消息发送至MQ消息中间件。

MQ消息中间件接收接口服务端发送的消息，然后向Flink发送消息。

Flink接收并消费消息，以获取业务编码、请求内容参数、busi_key、消息的生成时间戳和业务请求的处理时长。Flink根据所述消息的生成时间戳，将所述消息放入对应的时间窗口中；当到达所述时间窗口的结束时间时，计算所述时间窗口内的所述业务请求标识对应的请求量和/或平均处理时长；然后将所述业务请求对应的所述业务请求标识、所述业务编码、所述请求内容参数、所述业务请求标识对应的请求量和/或平均处理时长写入ElasticSearch的索引表中。

定时任务定时地从所述索引表中获取满足预设业务规则的业务请求；将各个请求内容参数分别拼接成调用任务，执行所述调用任务，以异步调用各个业务编码对应的接口逻辑，从而获取各个busi_key对应的业务数据。

将各个busi_key及其对应的所述业务数据存储到所述缓存中。

另外，在本发明再一个可参考实施例中缓存数据的方法的具体实施内容，在上面所述缓存数据的方法中已经详细说明了，故在此重复内容不再说明。

图5是根据本发明实施例的缓存数据的装置的主要模块的示意图，如图5所示，所述缓存数据的装置500包括接收模块501、处理模块502、计算模块503和缓存模块504；其中，接收模块501用于接收并解析业务请求，得到业务编码和请求内容参数；处理模块502用于根据所述业务编码和所述请求内容参数，从缓存中获取业务数据或者通过调用所述业务编码对应的接口逻辑以获取业务数据，并返回所述业务数据；计算模块503用于根据所述业务请求和所述业务请求的处理时长生成消息，通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长；缓存模块503用于判断所述业务请求在预设时间窗口内的请求量和/或平均处理时长是否满足预设业务规则，若是，则异步调用所述业务编码对应的接口逻辑以获取业务数据，并将所述业务数据存储到所述缓存中。

可选地，所述处理模块502还用于：

根据所述业务编码和所述请求内容参数，生成业务请求标识；

判断缓存中是否存在所述业务请求标识；

若是，则从所述缓存中获取所述业务请求标识对应的业务数据；

若否，则根据所述请求内容参数调用所述业务编码对应的接口逻辑，以获取业务数据。

可选地，所述处理模块502还用于：

将所述业务编码和所述请求内容参数拼接成业务请求信息；

采用信息摘要算法计算所述业务请求信息的摘要值，将所述摘要值作为业务请求标识。

可选地，所述消息的内容包括所述业务编码、所述请求内容参数、所述业务请求标识、所述消息的生成时间戳和所述业务请求的处理时长。

可选地，所述计算模块503还用于：

将所述消息发送至消息中间件；

从所述消息中间件中获取消息，并消费所述消息；

根据所述消息的生成时间戳，将所述消息放入对应的时间窗口中；

当到达所述时间窗口的结束时间时，计算所述时间窗口内的所述业务请求标识对应的请求量和/或平均处理时长；

将所述业务请求对应的所述业务请求标识、所述业务编码、所述请求内容参数、所述业务请求标识对应的请求量和/或平均处理时长写入索引表中。

可选地，所述缓存模块504还用于：

定时地从所述索引表中获取满足预设业务规则的所述业务请求；

将所述请求内容参数拼接成调用任务，执行所述调用任务，以调用所述业务编码对应的接口逻辑，从而获取业务数据；

将所述业务请求标识及其对应的所述业务数据存储到所述缓存中。

可选地，所述缓存模块504还用于：

根据所述业务请求标识生成对应的缓存标识；

将所述缓存标识以及所述业务请求标识对应的所述业务数据存储到所述缓存中，并设置所述缓存标识的有效周期；其中，所述缓存标识的有效周期是定时周期的1-5倍。

根据上面所述的各种实施例，可以看出本发明实施例通过若业务请求在预设时间窗口内的请求量和/或平均处理时长满足预设业务规则，则调用业务编码对应的接口逻辑以获取业务数据，将业务数据存储到缓存中的技术手段，解决了现有技术中只能静态地实现缓存的技术问题。本发明实施例通过计算各个业务请求在预设时间窗口内的请求量和/或平均处理时长，判断是否对业务请求对应的业务数据进行缓存，从而动态地实现缓存，保证在高并发场景下满足业务需求。

需要说明的是，在本发明所述缓存数据的装置的具体实施内容，在上面所述缓存数据的方法中已经详细说明了，故在此重复内容不再说明。

图6示出了可以应用本发明实施例的缓存数据的方法或缓存数据的装置的示例性系统架构600。

如图6所示，系统架构600可以包括终端设备601、602、603，网络604和服务器605。网络604用以在终端设备601、602、603和服务器605之间提供通信链路的介质。网络604可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

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

终端设备601、602、603可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器605可以是提供各种服务的服务器，例如对用户利用终端设备601、602、603所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的物品信息查询请求等数据进行分析等处理，并将处理结果反馈给终端设备。

需要说明的是，本发明实施例所提供的缓存数据的方法一般由服务器605执行，相应地，所述缓存数据的装置一般设置在服务器605中。

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

下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，计算机系统700包括中央处理单元(CPU)701，其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。在RAM 703中，还存储有系统700操作所需的各种程序和数据。CPU 701、ROM 702以及RAM703通过总线704彼此相连。输入/输出(I/O)接口705也连接至总线704。

以下部件连接至I/O接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(CPU)701执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括接收模块、处理模块和缓存模块，其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，该设备实现如下方法：接收并解析业务请求，得到业务编码和请求内容参数；根据所述业务编码和所述请求内容参数，从缓存中获取业务数据或者通过调用所述业务编码对应的接口逻辑以获取业务数据，并返回所述业务数据；根据所述业务请求和所述业务请求的处理时长生成消息，通过消费所述消息获得所述业务请求在预设时间窗口内的请求量和/或平均处理时长；判断所述业务请求在预设时间窗口内的请求量和/或平均处理时长是否满足预设业务规则，若是，则异步调用所述业务编码对应的接口逻辑以获取业务数据，并将所述业务数据存储到所述缓存中。

根据本发明实施例的技术方案，因为采用若业务请求在预设时间窗口内的请求量和/或平均处理时长满足预设业务规则，则调用业务编码对应的接口逻辑以获取业务数据，将业务数据存储到缓存中的技术手段，所以克服了现有技术中只能静态地实现缓存的技术问题。本发明实施例通过计算各个业务请求在预设时间窗口内的请求量和/或平均处理时长，判断是否对业务请求对应的业务数据进行缓存，从而动态地实现缓存，保证在高并发场景下满足业务需求。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。