CN110019359A - 一种防止缓存击穿的方法、装置及系统 - Google Patents

Abstract

本申请提供了一种防止缓存击穿的方法、装置及系统，在本申请中，直播应用服务器为观众客户端提供直播数据支持，其在访问数据库服务器之前，先将用于请求相同数据的直播数据请求进行合并，合并成一个直播数据请求，以在数据库服务器前端，有效控制数据加载请求的访问逻辑，减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

Description

一种防止缓存击穿的方法、装置及系统

技术领域

本申请涉及数据存取技术领域，特别涉及一种防止缓存击穿的方法、装置及系统。

背景技术

目前，大部分支持数据读取的设备都会用到缓存，缓存就是数据交换的缓冲区，称作Cache；当设备读取数据时，首先会从缓存中查看需要的数据，如果存在直接返回数据，如果不存在就直接查询数据库然后再缓存查询结果。

在实际应用中，数据库DB与应用QPS(query pre second,每秒查询率)通常是不匹配的，为了支持应用的高QPS的业务需求，系统通常采用缓存机制，缓存能缓解DB的访问压力。

发明内容

发明人发现目前的高QPS的应用容易出现缓存击穿，缓存击穿是指由于缓存故障或者缓存过期导致大量请求并发穿透缓存到数据库，从而对数据库造成巨大冲击，导致数据库连接池耗尽，频繁出错，甚至导致雪崩现象。

为了解决目前缓存容易出现缓存击穿的问题，本申请提供了一种防止缓存击穿的方法，通过有效控制数据加载请求的访问逻辑，减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

本申请还提供了一种防止缓存击穿的装置和系统，用以保证上述方法在实际中的实现及应用。

在本申请第一方面提供了一种防止缓存击穿的系统，其特征在于，包括：

数据库服务器，用于接收主播客户端发送的直播数据，在数据库中存储所述直播数据；接收直播数据请求，将用于请求相同直播数据的多个直播数据请求合并成一个访问请求，通过所述一个访问请求访问数据库得到对应的直播数据，利用访问得到的直播数据响应所述多个直播数据请求；

直播应用服务器，用于接收观众客户端发送的直播数据请求；若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求，向数据库服务器发送所述一个直播数据请求，接收直播数据，利用所述直播数据响应所述观众客户端。

本申请第二方面提供了一种防止缓存击穿的方法，应用于数据库服务器中，包括：

接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

接收直播数据请求；

将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

通过所述一个访问请求访问所述数据库得到对应的直播数据；

利用访问得到的直播数据响应所述多个直播数据请求。

本申请第三方面提供了一种防止缓存击穿的装置，应用于数据库服务器中，包括：

存储模块，用于接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

请求接收模块，用于接收直播数据请求；

请求合并模块，用于将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

访问模块，用于通过所述一个访问请求访问所述数据库得到对应的直播数据；

请求响应模块，用于利用访问得到的直播数据响应所述多个直播数据请求。

本申请第四方面提供了一种防止缓存击穿的方法，应用于直播应用服务器中，包括：

接收观众客户端发送的直播数据请求；

若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求；

向数据库服务器发送所述一个直播数据请求；

接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。

本申请第五方面提供了一种防止缓存击穿的装置，应用于直播应用服务器中，包括：

请求接收模块，用于接收观众客户端发送的直播数据请求；

请求合并模块，用于若未从缓存中访问到对应的直播数据，则将用于访问相同数据的多个直播数据请求合并成一个直播数据请求；

请求发送模块，用于向数据库服务器发送所述一个直播数据请求；

响应模块，用于接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。

与现有技术相比，本申请具有以下优点：

在本申请中，数据库服务器在数据库中存储直播数据，为直播提供数据支持，在处理直播应用服务器发送的直播数据请求时，为了防止大量请求并发访问数据库，对数据库造成冲击，数据库服务器在接收到并发的请求时，先对请求相同数据的多个请求进行合并，合并成一个访问请求，则利用这一个访问请求替代这多个请求来访问数据库，有效减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

在本申请中，直播应用服务器为观众客户端提供直播数据支持，其在访问数据库服务器之前，先将用于请求相同数据的直播数据请求进行合并，合并成一个直播数据请求，以在数据库服务器前端，有效控制数据加载请求的访问逻辑，减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

附图说明

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

图1是本申请在实际中的应用场景示意图；

图2是本申请实施例提供的一种防止缓存击穿的系统的结构图；

图3是本申请实施例提供的一种防止缓存击穿的方法的流程图；

图4是本申请实施例提供的另一种防止缓存击穿的方法的流程图；

图5是本申请实施例提供的一种防止缓存击穿的装置的结构图；

图6是本申请实施例提供的另一种防止缓存击穿的装置的结构图。

图7是本申请实施例提供的另一种防止缓存击穿的装置模块示意图。”

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在实际应用中，网络直播业务经常会出现高并发的数据加载请求，大量的数据加载请求极有可能并发穿透缓存达到数据库，瞬间对数据库造成巨大冲击，严重时还会导致数据库雪崩，进而导致业务瘫痪。

例如：在天猫双11晚会的网络直播中，在开始直播时会有几十万人甚至几百万、几千万人同时进入直播间观看直播，由于在直播活动开始时，直播应用服务器并没有缓存该直播活动的相关数据，则这百万级、千万级的直播数据请求就会直接到达数据库服务器，从数据库服务器中加载数据，这就容易导致数据库雪崩，导致直播无法正常进行。

基于此，本申请提供的关于防止缓存击穿的方法、装置及系统，为了便于理解本申请，下面先对本申请在实际应用中的场景进行介绍。

参见图1，图1为本申请在实际中的应用场景图。本申请在实际中的应用场景为，主播利用个人终端装载主播客户端，通过主播客户端发布直播，则终端向数据库服务器发送该直播数据，数据库服务器在数据库中存储管理直播数据，为观众客户端提供直播数据支持，从而实现大量观众同步观看直播。

如图1所示，主播A通过终端A中安装的主播客户端发布直播，终端A将直播数据发送至数据库服务器101，数据库服务器101将直播数据存储在数据库中；主播B通过终端B中安装的主播客户端发布直播，终端B将直播数据发送至数据库服务器101，数据库服务器101将直播数据存储在数据库中；如图1所示，数据库服务器101中存储有主播A的直播间ID为1234对应的直播数据以及主播B的直播间ID为1235对应的直播数据。

观众C通过终端C中安装的观众客户端观看直播间ID为1234的直播，终端C向直播应用服务器102发送直播数据请求1，在同一时间点，观众 D通过终端D中安装的观众客户端观看直播间ID为1234的直播，终端D 向直播应用服务器102发送直播数据请求2，以及，观众E通过终端E中安装的观众客户端观看直播间ID为1234的直播，终端E向直播应用服务器102发送直播数据请求3。

而与此同时，观众F和观众G同时观看直播间ID为1234的直播，同理，终端F和终端G分别向直播应用服务器103发送直播数据请求4和直播数据请求5。

直播应用服务器接收到直播数据请求后，先在缓存中访问对应的直播数据，如果未访问到，则从数据库服务器中访问对应的直播数据，但在访问之前，直播应用服务器先对大量的直播数据请求作合并处理，以减少对数据库的访问量，将用于请求相同数据的多个直播数据请求合并成一个直播数据请求，仅向数据库服务器101发送合并后该直播数据请求。如图1所示，直播应用服务器102将直播数据请求1,2,3合并成一个直播数据请求1，仅向数据库服务器发送该直播数据请求1。同理，直播应用服务器103将直播数据请求4和5合并成一个直播数据请求4，仅向数据库服务器发送该直播数据请求4。

对于数据库服务器而言，对于同一时间接收到的大量的直播数据请求，并不是直接响应处理，而是先作合并处理，将用于请求相同数据的多个直播数据请求合并成一个访问请求，仅利用该访问请求来访问数据库，如图1所示，数据库服务器接收到直播数据请求1和直播数据请求4，这两个请求均是请求直播间ID为1234的直播数据，因此，数据库服务器将直播数据请求1和直播数据请求4合并成一个访问请求，如合并成直播数据请求1，即，仅通过该直播数据请求1访问数据库，读取对应的直播数据，再利用读取到的直播数据一并响应这两个请求。

直播应用服务器102和直播应用服务器103接收到访问的直播数据，根据上述合并情况，再向各个用户终端反馈对应的直播数据。

此处需要说明的是，上述终端个数、直播应用服务器个数、数据库服务器个数、直播数据请求个数以及直播数据个数均是为了方便解释说明，本申请对此并不做具体限制，在实际直播场景中，直播数据请求的并发量非常大，常常达到几千万甚至上亿的数量级，而直播应用服务器和数据库服务器也是依据实际的业务需求而部署的。

在上述应用场景的基础上，本申请提供了一种防止缓存击穿的系统，该系统能够有效控制在直播场景中，直播数据请求对数据库的访问逻辑，在保证对直播数据请求的实时响应的前提下，减少对数据库的读取次数，避免出现对数据库的集中访问，以有效避免缓存击穿导致的数据库雪崩的问题。

参见图2，图2为本申请实施例提供的一种防止缓存击穿的系统的结构图，如图2该系统包括：

数据库服务器201，用于接收主播客户端发送的直播数据，在数据库中存储所述直播数据；接收直播数据请求，将用于请求相同直播数据的多个直播数据请求合并成一个访问请求，通过所述一个访问请求访问数据库得到对应的直播数据，利用访问得到的直播数据响应所述多个直播数据请求；可选地，数据库服务器201的处理过程可参见下文图3所示方法实施例的描述。

直播应用服务器202，用于接收观众客户端发送的直播数据请求；若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求，向数据库服务器发送所述一个直播数据请求，接收直播数据，利用所述直播数据响应所述观众客户端。可选地，直播应用服务器202的处理过程可参见下文图4所示方法实施例的描述。

在实际应用中，直播应用服务器可以内置有缓存，称为本地缓存，则直播应用服务器在工作时，先从本地缓存中访问对应的直播数据；当然，该系统还可以采用多级缓存机制，即该系统还可以包括：集中缓存服务器，用于缓存直播数据。在该多级缓存机制下，直播应用服务器先从本地缓存中访问对应的直播数据，若未访问到，则再从集中缓存服务器中访问对应的数据，若仍旧未访问到，再从数据库服务器中访问对应的直播数据。

其中，集中缓存服务器作为直播业务的集中缓存环节，其需要缓存的数据量会非常庞大，因此，在具体实现时，缓存服务器可以采用分布式构架进行部署，即分布式缓存，例如：该分布式缓存可以采用Memcached，Memcached 采用集中式缓存集群管理方式，也被称为互不通信的分布式构架方式，缓存部署在一组专门的服务器上。而直播应用服务器通过一致性HASH等路由算法选择集中缓存服务器远程访问缓存直播数据。

下面从直播业务实现角度对该系统的实现过程进行介绍。

本申请实施例提供的系统，在实际应用中，直播应用服务器作为网络直播平台的入口，其承担大量的直播数据请求，因此，可以利用直播应用服务器集群来分担大量的请求，在直播应用服务器前端还可以部署负责均衡服务器，用于调度用户的直播数据请求，根据分发策略将直播数据请求路由分发至对应的直播应用服务器中。

为了支持海量直播数据的存储管理，数据库服务器可采用服务器集群方式进行部署，以适配电子商务网站的海量数据的可伸缩需求。当然，本申请实施例在实现时，也可以仅部署一个数据库服务器以满足业务数据量小的存储需求。

为了支持海量客户端的直播业务需求，直播应用服务器可采用服务器集群方式进行部署，可以针对不同地理区域来部署直播应用服务器，也可以采用其他方式来部署直播应用服务器。

利用本申请实施例提供的系统，直播应用服务器在访问数据库前端对直播数据请求作合并处理，以减少对数据库的无效访问，另外，数据库服务器接收到大量的数据直播请求后，先对直播数据请求作合并处理，将用于请求相同数据的多个直播数据请求合并成一个访问请求，利用这一个访问请求替代这多个请求来访问数据库，有效减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而缓解数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

接下来，对本申请实施例提供的一种防止缓存击穿的方法进行介绍。

参见图3，图3为本申请实施例提供的一种防止缓存击穿的方法流程图，该方法应用于数据库服务器中，如图3所示，该方法包括以下步骤：

301：数据库服务器接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

在实际应用中，数据库服务器以直播间ID为关键字建立索引，在数据库中存储直播间ID与直播数据之间的对应关系。该索引用以关联直播数据在数据库中的存储路径，这样，数据库服务器通过直播间ID能够快速的确定出该直播间唯一对应的直播数据。

其中，直播数据是指直播业务所需要的相关数据，例如，直播数据包括：直播界面需要的静态信息和视频流地址，该静态信息可包括：主播个人信息、直播初始界面的背景图片、直播中待介绍的商品信息，等等。

302，数据库服务器接收直播数据请求；

303，数据库服务器将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

在实际应用中，数据库服务器为多个直播应用服务器同时提供数据支持，则数据库服务器会接收到不同的直播应用服务器发送的直播数据请求。为了缓解对数据库的访问量，则通过步骤303合并操作以减小对数据库的无效访问。

一种可选的实现方式，包括：

将用于请求相同直播数据的多个直播数据请求中的任意一个请求作为一个访问请求。

举例说明，参见图1的场景示例图，数据库服务器102接收到直播应用服务器103发送的直播数据请求1，同时，数据库服务器102接收到直播应用服务器104发送的直播数据请求4，直播数据请求1和直播数据请求4均是用于请求直播间ID为1234的直播数据，两者为相同的请求，则数据库服务器102将这两个请求合并成一个访问请问，例如，合并成直播数据请求1，该合并操作的本质是，从用于请求相同数据的多个直播数据请求中任意选择一个请求作为访问请求，该访问请求代替这多个直播数据请求去访问数据库，读取对应的直播数据。

在一种可选的实现方式中，数据库服务器可以通过以下方式管理高并发的直播数据请求：

数据库服务器在执行合并操作后，将合并后的所述一个访问请求存储在第一数据表中，所述第一数据表用于存储服务器当前正在处理的直播数据请求；

将所述多个直播数据请求中的除去所述一个访问请求之外的其余请求存储在第二数据表中，所述第二数据表用于存储服务器接收的但还未处理的直播数据请求。

举例说明，仍旧以上述示例为基础，则数据库服务器在执行合并操作后，利用该访问请求，即直播数据请求1去访问数据库，读取对应的直播数据，将直播数据请求1存储在第一数据表中，同时将直播数据请求4 存储在第二数据表中。

在本申请实施例中，数据库服务器维护两张表的目的是为了管理高并发的直播数据请求，以保证在同一时间点对数据库中的一个直播数据仅作一次读取操作，同时，保证对直播数据请求的实时响应，满足直播业务的高实时性要求。在实际应用中，数据库服务器根据实时处理的直播数据请求而实时更新第一数据表和第二数据表。

在本申请实施例中，数据库服务器在维护两张表后，数据库服务器在接收到大量的数据加载请求时，也可以先查看第一数据表中是否存在与当前接收到的数据加载请求用于请求相同数据的请求，若存在，数据库服务器则将当前接收到的数据加载请求添加到第二数据表中，而无需再访问数据库，避免对数据库造成无效访问，减小对数据库的访问压力。

304，数据库服务器通过所述一个访问请求访问所述数据库得到对应的直播数据；

305，数据库服务器利用访问得到的直播数据响应所述多个直播数据请求。

举例说明，仍旧以上述示例基础，数据库服务器合并后的访问请求，即直播数据请求1，利用该访问请求访问数据库，读取到对应的直播数据，数据库服务器在第二数据表中还存储有合并操作所涉及的直播请求数据的关联关系，例如，存储有直播数据请求4和直播数据请求1的关联关系，一旦利用直播数据请求1从数据库中读取到对应的直播数据时，则数据库服务器进而利用该关联关系，并行响应直播数据请求1和直播数据请求4。

在实际应用中，有时，数据库服务器接收到的直播数据请求中并没有相同请求，不同的直播数据请求分别用于访问不同的直播数据，在这种情况下，数据库服务器也可以根据第一数据表中记录的正在处理的直播数据请求的情况，来决定是否直接处理当前接收到的直播数据请求。

在一种可选的实现方式中，若当前仅接收到一个直播数据请求，记为第一直播数据请求，则所述方法还包括：

判断所述第一数据表中是否存在与所述第一直播数据请求请求相同数据的第二直播数据请求；

若是，则将所述第一直播数据请求添加到所述第二数据表中，利用所述第二直播数据请求访问得到的直播数据响应所述第一直播数据请求。

若否，则利用所述第一直播数据请求访问所述数据库得到对应的直播数据，利用所述直播数据响应所述第一直播数据请求。

举例说明，仍旧以上述场景为例，若第一数据表中记录有直播数据请求1，此时，数据库服务器接收到另一直播数据请求7，其与直播数据请求1请求相同的直播数据，则，数据库服务器先判断第一数据表中是否记载有与直播数据请求7相同的请求，若有，则将该直播数据请求7 添加到第二数据表中，等待利用直播数据请求1从数据库中读取到对应的直播数据时，再一并响应第二数据表中记录的与直播数据请求1相同的直播数据请求7。

但如果数据库服务器接收到另一个直播数据请求8时，该第一数据表中并未记载与该直播数据请求8相同的请求，此时，直接利用该直播数据请求8访问数据库，读取对应的直播数据。

利用本申请实施例提供的方法，数据库服务器在数据库中存储直播数据，为直播提供数据支持，在处理直播应用服务器发送的直播数据请求时，为了防止大量请求并发访问数据库，对数据库造成冲击，数据库服务器在接收到并发的请求时，先对请求相同数据的多个请求进行合并，合并成一个访问请求，则利用这一个访问请求替代这多个请求来访问数据库，有效减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

在实际应用中，一些热门直播的发布时间和播放时长很相近，因此，大量用户会在同时观看不同直播，还会同时结束观看直播，因此，在实际直播场景中，数据加载请求会出现周期性突增突减的现象，这种现象会造成数据库出现锯齿状访问现象，无法有效利用数据库资源，并且严重时会导致数据库崩溃。

基于此，本申请实施例还提供了另一种方法，参见图4所示的流程图，该方法包括：

401，接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

402，接收直播数据请求；

403，将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

404，通过所述一个访问请求访问所述数据库得到对应的直播数据；

405，为所述数据库中的不同的直播数据分配不同的动态超时时间，将所述直播数据与各自对应的动态超时时间绑定关联；

在本申请实施例中，数据库服务器可以采用随机超时时间机制，为不同的直播数据分配不同的动态超时时间；数据库服务器也可以根据不同直播业务类型来分配直播数据对应的动态超时时间；数据库服务器还可以根据直播数据的优先级来分配不同的动态超时时间，直播数据的优先级可以由直播业务方自定义，在直播数据中携带有优先级等级标识。

406，利用访问得到的直播数据和与直播数据对应的动态超时时间响应所述多个直播数据请求。

上述步骤401-403与图3所示方法步骤301-303相同，可参照上文描述的内容，此处不再赘述。

利用本申请实施例提供的方法，数据库服务器引入了动态超时时间机制，为不同的直播数据分配不同的动态超时时间，从而控制直播应用服务器在接收到直播数据时，同时接收刅动态超时时间，根据缓存的静态超时时间和该动态超时时间对直播数据进行缓存，从而缓解在实际直播场景中，直播数据请求周期性突增突减的现象，避免对造成数据库造成锯齿状访问现象，以提高数据库资源利用率。

在实际应用中，由于客户端BUG、数据过期、数据库恶意访问等因素，造成从数据库中无法加载到实际数据，这些请求都会直接击穿所有缓存到达数据库中，由于数据库中没有对应的数据，缓存自然也没有可缓存的数据，因此，这些直播数据请求还会重复去数据库中加载数据。

基于此，本申请实施例还提供了对应的解决方法，该方法是在数据库服务器中预先注入一个空值并生成一个空值标识；当所述数据库服务器中未存储有与直播数据请求对应的直播数据时，则在上述图3或者图4 所示方法的基础上还可以增加如下步骤：

若所述第一访问请求访问得到空值时，根据所述空值标识响应所述多个直播数据请求。

通过这种在数据库中预置空值以及空值标识的方式，将空值分发给直播应用服务器，以实现对空值的缓存，从而有效避免重复去数据库中加载空值，以减小无效访问对数据库服务器造成的访问压力。

以上是对本申请实施例提供的数据库服务器侧的方法，下面对直播应用服务器侧的方法进行介绍。

参见图5，图5为本申请实施例提供的一种防止缓存击穿的方法流程图，该方法应用于直播应用服务器中，如图5所示，该方法包括以下步骤：

501，接收观众客户端发送的直播数据请求；

在本申请实施例中，直播应用服务器为多个客户端提供直播数据支持，以满足直播业务的实时性需求；因此，对于直播应用服务器而言，其同时会接收到多个观众客户端发送的直播数据请求，其中，直播数据请求中至少包括直播间ID和数据类型；其中，观众客户端可以是直播浏览器、直播应用、或者具有直播功能模块的综合性应用等。用户可通过终端运行观众客户端，进入直播间观看直播。则观众客户端通过终端向直播应用服务器发送直播数据请求，以请求直播数据，观众客户端最后根据直播应用服务器反馈的直播数据渲染直播页面。

对于直播应用服务器而言，在接收到观众客户端发送的直播数据请求时，先从缓存中读取对应的直播数据，这里的缓存可以是直播应用服务器的本地缓存，当然缓存还可以包括集中缓存服务器提供的缓存；直播应用服务器先从本地缓存中访问对应的直播数据，若访问取到，则再从集中缓存服务器中访问对应的直播数据，若还未访问到，则再执行502。

502，若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求；

503，向数据库服务器发送所述一个直播数据请求；

直播应用服务器在同一时间点会接收到大量的直播数据请求，当从缓存中未访问到对应的直播数据，此时直播应用服务器需要从数据库中访问直播数据，但直播应用服务器若直接将直播数据请求发送至数据库服务器，则会造成缓存击穿，更严重时就会造成数据库雪崩。正是为了解决该问题，在本申请实施例中，直播应用服务器在访问数据库服务器之前，先对直播数据请求作合并处理，将用于请求相同数据的多个直播数据请求合并成一个直播数据请求，利用该一个直播数据请求来代替这多个直播数据请求去访问数据库服务器。

举例说明，仍旧参见图1，直播应用服务器102接收到不同观众客户端通过终端发送的不同直播数据请求，如直播数据请求1,2,3，这三个请求用于请求相同的直播数据，在这种情况下，直播应用服务器102将直播数据请求1,2,3合并成一个直播数据请求1，仅向数据库服务器发送该直播数据请求1。即，由直播数据请求1代替这三个直播数据请求去访问数据库服务器。504，接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。

直播应用服务器在执行合并处理后，仅通过一个直播数据请求代替多个直播数据请求去访问数据库服务器，在接收到数据库服务器反馈的直播数据后，直播应用服务器利用该直播数据并行响应上述多个直播数据请求，即向对应的观众客户端反馈对应的直播数据。

举例说明，仍旧参见图1，直播应用服务器接收到数据库服务器针对直播数据请求1反馈的直播数据时，则直播应用服务器并行响应直播数据请求1,2,3，向这三个请求各自对应的请求方，反馈对应的直播数据。

利用本申请实施例提供的方法，直播应用服务器为观众客户端提供直播数据支持，其在访问数据库服务器之前，先将用于请求相同数据的直播数据请求进行合并，合并成一个直播数据请求，以在数据库服务器前端，有效控制数据加载请求的访问逻辑，减小对数据库的无效访问，避免同一时间对同一直播数据的重复加载，从而减小数据库的访问压力，能够有效减小缓存击穿导致的数据库雪崩的现象。

与上述图4所示方法相对应的，为了缓解在实际直播场景中，数据加载请求会出现周期性突增突减的现象，为了提高数据库资源利用率，本申请实施例还提供的应用于直播应用服务器中的方法，该方法具体在上述图5所示方法的基础上，还可以包括如下步骤：

接收与所述直播数据绑定关联的动态超时时间；

将所述动态超时时间和缓存的静态超时时间的和值作为所述直播数据对应的超时时间；

按照所述超时时间缓存所述直播数据。

在本申请实施例中，直播应用服务器根据该动态缓存时间来缓存直播数据，具体的，直播应用服务器在本地缓存中缓存该直播数据，另外，直播应用服务器还可以将该直播数据和对应的动态超时时间发送至集中缓存服务器，则集中缓存服务器根据自身缓存的静态超时时间和该直播数据的动态超时时间，计算该直播数据对应的超时时间，进而按照该超时时间缓存该直播数据。这样，不同的直播数据在缓存中会被缓存不同的时长。

下面结合表1对上述方法的实现效果进行说明。

表1 现有缓存机制和本申请动态缓存机制效果的对比表

如表1所示，现有缓存机制对不同的直播数据不作区分，所有的主播数据均采用缓存自身的静态超时时间进行缓存管理。而在本申请实施例的方法中，不对原有缓存机制作更改，而是针对不同直播数据设置不同的动态超时时间，从而使得该直播数据在缓存时，在缓存自身的静态超时时间上增加直播数据的动态超时时间，从而使得不同数据在缓存中享受不同的超时时间。

如表1所示，数据A,B,C是直播应用服务器同一时间从数据库中加载到的不同直播数据，直播应用服务器的本地缓存自身的静态超时时间为 30秒，则在现有技术中，这三个直播数据A,B,C会在同一时间缓存，并且在缓存30秒后，这三个直播数据会同时失效，若应用服务器在30秒后，还需要加载直播数据A,B,C时，则需要再次从数据库服务器中加载。可见，由不同直播数据采用相同的静态超时时间，因此，这三个直播数据A,B,C同时缓存，也必然同时失效。这就造成对数据库服务器进行锯齿状访问，影响数据库的性能。

如表1所示，利用本申请实施例的方法，直播数据A对应的动态超时时间为40秒，数据B对应的动态超时时间为30秒，数据C对应的动态超时时间为50秒，因此，应用服务器在本地缓存这三个数据时，分别在自身缓存的静态超时时间30秒的基础上增加各个直播数据对应的动态超时时间，即数据A在本地缓存的超时时间为70秒，数据B在本地缓存的超时时间为60秒，数据C在本地缓存的超时时间为80秒。可见：虽然这三个直播数据在缓存中被同时缓存，但并不会同时失效，这样就能够将直播数据请求打散，能够有效避免直播数据请求的突增突减少，避免出现锯齿状访问现象。

通过本申请实施例的方法，使得直播应用服务器根据控制不同直播数据在缓存中享有不同的超时时间，从而在直播应用服务器端有效打散直播数据请求，避免出现对数据库服务器的锯齿状访问现象。

在实际应用中，由于客户端BUG、数据过期、数据库恶意访问等因素，造成从数据库中无法加载到实际数据，这些请求都会直接击穿所有缓存到达数据库中，由于数据库中没有对应的数据，缓存自然也没有可缓存的数据，因此，这些直播数据请求还会重复去数据库中加载数据。

为了避免这种无效访问对数据库造成多大的访问压力，本申请实施例还提供了应用于直播应用服务器中的方法，具体的，在上述图5所示方法的基础上，还可以包括如下步骤：

当所述直播数据为空时，所述方法还包括：

根据所述多个直播数据请求缓存用于标识空值的空值标识。

在本申请实施例中，直播应用服务器在本地缓存中缓存与直播数据请求对应的空值标识，另外，该直播应用服务器还可以将该空值标识分发至集中缓存服务器中，以使集中缓存服务器缓存与直播数据请求对应的空值标识，从而避免因为空值访问对数据库造成的访问压力，在一定程度上减少对数据库的访问量。

上文详述了本申请提供的系统和方法的技术方案，与方法对应的，本申请还提供了装置，参见图6，为本申请实施例提供的一种防止缓存击穿的装置，该装置应用于数据库服务器中，该装置包括：

存储模块601，用于接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

请求接收模块602，用于接收直播数据请求；

请求合并模块603，用于将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

访问模块604，用于通过所述一个访问请求访问所述数据库得到对应的直播数据；

请求响应模块605，用于利用访问得到的直播数据响应所述多个直播数据请求。

在本申请实施例中，图6所示装置的各个功能模块的实现可参见上文图3所示方法实施例的实现，此处不再赘述。

参见图7，为本申请实施例提供的另一种防止缓存击穿的装置，该装置应用于直播应用服务器中，该装置包括：

请求接收模块701，用于接收观众客户端发送的直播数据请求；

请求合并模块702，用于若未从缓存中访问到对应的直播数据，则将用于访问相同数据的多个直播数据请求合并成一个直播数据请求；

请求发送模块703，用于向数据库服务器发送所述一个直播数据请求；

响应模块704，用于接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。

在本申请实施例中，图7所示装置的各个功能模块的实现可参见上文图5所示方法实施例的实现，此处不再赘述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的一种防止缓存击穿的方法、装置及系统进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

1.一种防止缓存击穿的系统，其特征在于，包括：

数据库服务器，用于接收主播客户端发送的直播数据，在数据库中存储所述直播数据；接收直播数据请求，将用于请求相同直播数据的多个直播数据请求合并成一个访问请求，通过所述一个访问请求访问数据库得到对应的直播数据，利用访问得到的直播数据响应所述多个直播数据请求；

直播应用服务器，用于接收观众客户端发送的直播数据请求；若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求，向数据库服务器发送所述一个直播数据请求，接收直播数据，利用所述直播数据响应所述观众客户端。

2.一种防止缓存击穿的方法，其特征在于，包括：

接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

接收直播数据请求；

将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

通过所述一个访问请求访问所述数据库得到对应的直播数据；

利用访问得到的直播数据响应所述多个直播数据请求。

3.根据权利要求2所述的方法，其特征在于，所述将请求相同直播数据的多个直播数据请求合并成一个访问请求，包括：

将用于请求相同直播数据的多个直播数据请求中的任意一个请求作为一个访问请求。

4.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：

将所述一个访问请求存储在第一数据表中，所述第一数据表用于存储服务器当前正在处理的直播数据请求；

将所述多个直播数据请求中的除去所述一个访问请求之外的其余请求存储在第二数据表中，所述第二数据表用于存储服务器接收的但还未处理的直播数据请求。

5.根据权利要求4所述的方法，其特征在于，若当前仅接收到一个直播数据请求，记为第一直播数据请求，则所述方法还包括：

判断所述第一数据表中是否存在与所述第一直播数据请求请求相同数据的第二直播数据请求；

若是，则将所述第一直播数据请求添加到所述第二数据表中，利用所述第二直播数据请求访问得到的直播数据响应所述第一直播数据请求。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

若否，则利用所述第一直播数据请求访问所述数据库得到对应的直播数据，利用所述直播数据响应所述第一直播数据请求。

7.根据权利要求2所述的方法，其特征在于，所述方法还包括：

为所述数据库中的不同的直播数据分配不同的动态超时时间，将所述直播数据与各自对应的动态超时时间绑定关联；

则在响应直播数据请求，反馈直播数据时，一并反馈与直播数据对应的动态超时时间。

8.根据权利要求2所述的方法，其特征在于，所述数据库采用数据行级锁控制数据。

9.根据权利要求2所述的方法，其特征在于，所述数据库中预先内置有空值以及空值标识；

则所述方法还包括：

若所述第一访问请求访问得到空值时，根据所述空值标识响应所述多个直播数据请求。

10.一种防止缓存击穿的装置，其特征在于，包括：

存储模块，用于接收主播客户端发送的直播数据，将所述直播数据存储在数据库中；

请求接收模块，用于接收直播数据请求；

请求合并模块，用于将用于请求相同直播数据的多个直播数据请求合并成一个访问请求；

访问模块，用于通过所述一个访问请求访问所述数据库得到对应的直播数据；

请求响应模块，用于利用访问得到的直播数据响应所述多个直播数据请求。

11.一种防止缓存击穿的方法，其特征在于，包括

接收观众客户端发送的直播数据请求；

若未从缓存中访问到对应的直播数据，则将用于请求相同数据的多个直播数据请求合并成一个直播数据请求；

向数据库服务器发送所述一个直播数据请求；

接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

接收与所述直播数据绑定关联的动态超时时间；

将所述动态超时时间和缓存的静态超时时间的和值作为所述直播数据对应的超时时间；

按照所述超时时间缓存所述直播数据。

13.根据权利要求11所述的方法，其特征在于，当所述直播数据为空时，所述方法还包括：

根据所述多个直播数据请求缓存用于标识空值的空值标识。

14.一种防止缓存击穿的装置，其特征在于，包括：

请求接收模块，用于接收观众客户端发送的直播数据请求；

请求合并模块，用于若未从缓存中访问到对应的直播数据，则将用于访问相同数据的多个直播数据请求合并成一个直播数据请求；

请求发送模块，用于向数据库服务器发送所述一个直播数据请求；

响应模块，用于接收所述数据库服务器反馈的直播数据，利用所述直播数据响应所述观众客户端。