数据处理方法、装置、设备和可读存储介质

技术领域

本申请涉及互联网技术领域，尤其涉及一种数据处理方法、装置、设备和可读存储介质。

背景技术

随着互联网技术的发展，互联网用户越来越多，在一些高并发场景中，网站平台端可能会在短时间内收到大量的用户请求数据，需要网站平台端能够高效的完成这些数据的读写。

相关技术中，在对这些高并发的数据进行写入的时候，主要是先将数据写入至中间件进行削峰，之后再写入到数据库。

但是，相关技术的这种方式在网络抖动或宕机等情况的影响下中间件容易出现异常，使得数据无法正常写入中间件，最终造成数据库中的数据与中间件中的数据不一致，造成数据处理的正确性下降。

发明内容

本申请提供一种数据处理方法、装置、设备和可读存储介质，用于解决现有数据处理的正确性低的问题。

第一方面，本申请实施例提供一种数据处理方法，应用于分布式系统中的任一个服务器，所述分布式系统包括有至少一个服务器，所述方法包括：

将接收到的至少一个数据写入至缓存，获取每个数据的缓存结果，每个数据对应的缓存结果用于指示所述数据是否成功写入至所述缓存；

将所述至少一个数据传输至数据库进行存储；

在将每个数据存储至所述数据库时，根据所述数据的缓存结果，将未成功写入至所述缓存的数据补录至所述缓存中以使所述缓存中的数据与所述数据库中的数据相同。

在第一方面的一种可能设计中，所述将所述至少一个数据传输至数据库进行存储，包括：

将未成功写入至所述缓存的第一数据和成功写入至所述缓存的第二数据均写入至消息队列；

读取写入至所述消息队列的第一数据和第二数据，存储至所述数据库。

在第一方面的另一种可能设计中，所述消息队列为主消息队列或辅消息队列，所述将未成功写入至所述缓存的第一数据和成功写入至所述缓存的第二数据均写入至所述消息队列，包括：

当所述消息队列为所述主消息队列时，检测所述第一数据和第二数据中的至少一项在写入所述主消息队列时是否存在异常；

若存在异常，则将所述消息队列切换为辅消息队列，并将所述第一数据和第二数据重新写入至所述辅消息队列；

当所述消息队列为所述辅消息队列时，检测所述第一数据和第二数据中的至少一项在写入所述辅消息队列时是否存在异常；

若存在异常，则将所述消息队列切换为主消息队列，并将所述第一数据和第二数据重新写入至所述主消息队列。

在第一方面的再一种可能设计中，所述读取写入至所述消息队列的第一数据和第二数据，包括：

在读取写入至所述消息队列的第一数据和第二数据时，检测所述第一数据和第二数据当前是否存在读取异常；

若所述第一数据和第二数据当前存在读取异常，则获取截止当前所述读取异常发生的次数；

根据所述次数，确定下一次读取时间；

在下一次读取时间到来时，重新对写入至所述消息队列的第一数据和第二数据进行读取。

在第一方面的又一种可能设计中，所述根据所述数据的缓存结果，将未成功写入至所述缓存的数据补录至所述缓存中以使所述缓存中的数据与所述数据库中的数据相同之前，还包括：

将每个数据的缓存结果写入至所述消息队列；

在将每个数据存储至所述数据库时，从所述消息队列中读取所述缓存结果。

在第一方面的又一种可能设计中，所述方法还包括：

检测是否有未成功写入至所述缓存的未写入数据；

在检测到有所述未写入数据时，获取所述未写入数据的标识；

将所述标识添加至预设名单中；

将所述预设名单存储至所述服务器的本地内存中。

在第一方面的又一种可能设计中，所述方法还包括：

将所述预设名单备份至预设黑名单数据库中。

在第一方面的又一种可能设计中，所述方法还包括：

在所述未写入数据补录至所述缓存之后，将存储在所述服务器的本地内存中的预设名单中的所述标识移除；

将存储在所述预设黑名单数据库中的预设名单中的所述标识移除。

在第一方面的又一种可能设计中，所述将所述预设名单存储至所述服务器的本地存储中之后，还包括：

将所述预设名单广播至所述分布式系统的其它服务器以指示其它服务器将所述预设名单存储至所述其它服务器的本地内存中。

在第一方面的又一种可能设计中，所述方法还包括：

在所述未写入数据补录至所述缓存之后，将移除消息广播至所述分布式系统的其他服务器，所述移除消息用于指示其他服务器将所述第一数据的标识从其它服务器的本地内存中的预设名单中移除。

在第一方面的又一种可能设计中，所述方法还包括：

响应于目标数据的查询指令，确定所述目标数据是否为未成功写入至所述缓存的数据；

若所述目标数据为未成功写入至所述缓存的数据，则从所述数据库中查询得到所述目标数据；

若所述目标数据为成功写入至所述缓存的数据，则从所述缓存中查询得到所述目标数据。

第二方面，本申请实施例提供一种数据处理装置，包括：

结果获取模块，用于将接收到的至少一个数据写入至缓存，获取每个数据的缓存结果，每个数据对应的缓存结果用于指示所述数据是否成功写入至所述缓存；

数据传输模块，用于将所述至少一个数据传输至数据库进行存储；

数据补录模块，用于在将每个数据存储至所述数据库时，根据所述数据的缓存结果，将未成功写入至所述缓存的数据补录至所述缓存中以使所述缓存中的数据与所述数据库中的数据相同。

第三方面，本申请实施例提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现上述的方法。

第四方面，本申请实施例提供一种可读存储介质，所述可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现上述的方法。

第五方面，本申请实施例提供一种程序产品，包括计算机指令，该计算机指令被处理器执行时实现上所述的方法。

本申请实施例提供的数据处理方法、装置、设备和可读存储介质，通过对未成功写入到缓存中的数据进行补录，使得缓存中的数据与数据库中的数据保持一致，能够保证在突发高频流量时，保证数据的一致性，提高数据处理的正确率。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理；

图1为本申请实施例提供的数据处理方法的场景示意图；

图2为本申请实施例提供的数据处理方法实施例一的流程示意图；

图3为本申请实施例提供的数据处理方法的系统结构示意图；

图4为本申请实施例提供的数据写入过程的方法流程示意图；

图5为本申请实施例提供的数据处理方法实施例二的流程示意图；

图6为本申请实施例提供的数据处理装置的结构示意图；

图7为本申请实施例提供的电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

首先对本申请所涉及的名词进行解释：

MQ：消息队列(Message Queue，MQ)是基础数据结构中“先进先出”的一种数据结构。一般用来解决应用解耦，异步消息，流量削峰等问题，实现高性能，高可用，可伸缩和最终一致性架构。

中间件：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通讯，是连接两个独立应用程序或独立系统的软件。相连接的系统，即使它们具有不同的接口，但通过中间件相互之间仍能交换信息。

单播：单播是指一个单个的发送者和一个接受者之间通过网络进行的通信。

广播：广播是指一个发送者和多个接受者之间的通信。

图1为本申请实施例提供的数据处理方法的场景示意图，如图1所示，用户可以在终端设备上浏览网页并参与网站平台方提供的各种活动。其中，终端设备可以是计算机设备11、笔记本电脑12或者移动终端13。示例性的，用户可以浏览网站上发布的“抢红包活动”并发起抢红包，在完成抢红包活动之后用户可以查看抢到的红包金额并领取红包，服务器14在这个过程中需要进行数据的读写。这些活动通常会有大量的用户参与，数据存在流量大且高并发的特性，面对数据高并发的突发流入，服务器需要高效的完成数据的写入和读取，同时保证数据的正确性。

在相关技术中，面高频流量进入，服务器端通常会使用缓存来抗流量，在数据成功写入缓存之后再写入数据库，这种情况下数据库的连接池会被打满。而在进行数据读取时则直接通过缓存抗压，从缓存中读取数据，如果缓存失败则读取失败，数据无法获取，由此可能造成抢红包异常，例如无法显示抢到的红包金额。

针对上述问题，本申请实施例提供的数据处理方法、装置、设备和可读存储介质，通过缓存、消息队列等中间件对高并发大流量场景的数据进行抗压，当缓存异常而无法成功写入数据时，可以通过补录的方式来避免数据不一致的情况。同时通过设置消息队列为主备切换，也能够避免消息队列所产生的异常，提高整个系统的容错性，有效降低了整个系统的异常风险，保证在高并发大流量场景下用户请求的高效处理。

下面，通过具体实施例对本申请的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的数据处理方法实施例一的流程示意图，该方法可以应用于分布式系统的其中任一个服务器，如图2所示，该方法具体可以包括如下步骤：

S201、将接收到的至少一个数据写入至缓存，获取每个数据的缓存结果。

其中，每个数据对应的缓存结果用于指示数据是否成功写入至缓存。示例性的，缓存结果可以是缓存标签，例如设置一个标签cacheflag，当标签cacheflag＝0的时候，则表示该数据写入缓存失败，当标签cacheflag＝1的时候，则表示该数据成功写入缓存中。

在本实施例中，网站平台端在一些场景中会有大流量高并发数据涌入，例如现有的网站平台发布的“商品秒购活动”、“商品抢购活动”和“抢红包活动”等，以“抢红包活动”为例，在活动期间，用户可以点击终端设备的界面上显示的红包雨以抢红包，当红包雨结束之后，用户可以查看抢到的红包金额并领取。在这个过程中，用户抢到红包并领取可以简单的理解为相当于在网站下了一笔订单，通常这种活动都有很多用户参加，故而在活动期间内这个下单量非常大，服务器接收到的用户的数据通常不止一个。

其中，当服务器接收到这些数据之后，可以立刻将这些数据写入到缓存中，同时异步发送消息给数据库以将这些数据写入到数据库中。示例性的，当场景为“商品秒购活动”或者“商品抢购活动”时，服务器接收到的数据可以是订单信息。示例性的，缓存可以通过分布式系统的主从节点和动态扩容来保证高可用性。

S202、将至少一个数据传输至数据库进行存储。

在本实施例中，在高频流量数据涌入时，缓存用于抗压，这些数据会先写入到缓存中，同时缓存还可以用于数据的读取，当用户需要查询其用户数据时，可以从写入至缓存中的数据中查询用户数据，而对于未成功写入至缓存中的数据，则需要通过查询数据库来得到用户数据。可以理解，缓存只能够用于短期的数据存储与保存，数据库相当于缓存，能够实现用户数据的长期存储，保证用户数据的安全性。

在本实施例中，当流量瞬间峰值导致缓存写入失败或者网络抖动的时候，分布式系统可以通过异常捕获机制，捕获接收到的数据并保证让其正常传输到数据库。示例性的，数据可以先进入到消息队列中，然后通过消息队列来传输到数据库。其中，通过读取消息队列中的数据并写入到数据库中以进行存储。示例性的，消息队列中还可以增加上述标签cacheflag，代表缓存结果，在读取消息队列中的数据的同时可以读取该数据的标签cacheflag的取值，以确定其是否成功写入了缓存中。

S203、在将每个数据存储至数据库时，根据数据的缓存结果，将未成功写入至缓存的数据补录至缓存中以使缓存中的数据与数据库中的数据相同。

在本实施例中，对于未成功写入到缓存中的数据，可以在数据写入到数据库时进行补录。具体的，对于标签cacheflag＝0的数据，会被重新写入到缓存中。

示例性的，在将未成功写入到缓存中的数据补录到缓存中时，如果补录失败，可以继续重试直到补录成功，或者也可以设置阈值，当补录次数超过阈值时则不再进行重试。其中，造成补录失败的原因可能是缓存异常，例如缓存宕机或者网络抖动等，通过不断重试可以在缓存从异常恢复时实现数据的成功补录。

示例性的，当补录完成之后可以更新缓存结果，即该数据对应的标签cacheflag＝1。

本申请实施例在高并发大流量场景下，先通过缓存来抗流量，当缓存出现异常等情况导致数据未成功写入缓存，可以在后续数据存入数据库时对未成功写入至缓存的数据继续进行补录，确保不影响后续数据入库的同时也能够保证缓存中的数据与数据库中的数据的一致性，保证数据可以正常读取，最终提高活动参与成功率。

在一些实施例中，上述步骤S202具体可以通过如下步骤实现：

将未成功写入至缓存的第一数据和成功写入至缓存的第二数据均写入至消息队列；

读取写入至消息队列的第一数据和第二数据，存储至数据库。

示例性，消息队列可以是rabbitMQ消息队列或者kafka消息队列，其中，rabbitMQ消息队列用于实时的，对可靠性要求比较高的消息传递上。kafka消息队列用于处理活跃的流式数据，大数据量的处理上。其中，消息队列的数量可以是一个或多个，当消息队列为多个时，其中至少包括有一个主消息队列和一个辅消息队列，当主消息队列出现工作异常时，可以切换至辅消息队列继续执行当前工作，以保证高可用性。

本申请实施例通过将未成功写入至缓存的第一数据和成功写入至缓存的第二数据均写入至消息队列，通过消息队列实现异步消息写库，以应对高频流量写入，可以避免数据库的连接池被打满，提高数据处理效率。

示例性的，在上述实施例的基础上，在一些实施例中，上述步骤“将未成功写入至缓存的第一数据和成功写入至缓存的第二数据均写入至消息队列”，具体可以通过如下步骤实现：

当消息队列为主消息队列时，检测第一数据和第二数据中的至少一项在写入主消息队列时是否存在异常；

若存在异常，则将消息队列切换为辅消息队列，并将第一数据和第二数据重新写入至辅消息队列；

当消息队列为辅消息队列时，检测第一数据和第二数据中的至少一项在写入辅消息队列时是否存在异常；

若存在异常，则将消息队列切换为主消息队列，并将第一数据和第二数据重新写入至主消息队列。

在本实施例中，可以将rabbitMQ消息队列作为主消息队列，将kafka消息队列作为辅消息队列，当主消息队列出现消息写入异常时，可以切换至kafka消息队列继续进行数据写入。同理，当kafka消息队列出现异常时，可以切换为rabbitMQ消息队列继续进行数据写入。

本申请实施例通过设置主消息队列和辅消息队列，基于消息队列与缓存的差异，不涉及数据不一致的问题，当其中的一个消息队列出现异常时，可以切换至另一个消息队列继续工作，保证中间件的高可用性，实现高并发大流量场景下对数据的高效处理。

进一步的，在一些实施例中，上述步骤“读取写入至消息队列的第一数据和第二数据”，具体可以通过如下步骤实现：

在读取写入至消息队列的第一数据和第二数据时，检测第一数据和第二数据当前是否存在读取异常；若第一数据和第二数据当前存在读取异常，则获取截止当前读取异常发生的次数；根据次数，确定下一次读取时间；在下一次读取时间到来时，重新对写入至消息队列的第一数据和第二数据进行读取。

在本实施例中，读取第一数据和第二数据以写入至数据库时，如果读取不到第一数据和第二数据，则需要不断的重试，直到从消息队列读取出第一数据和第二数据。

示例性的，可以根据指数型重试策略来确定下一次读取时间，即下一次读取时间随重试次数递增延长。例如，在第一次读取消息队列中的第一数据和第二数据时，若存在读取异常，则确定下一次读取时间为2秒后，当经过2秒后再次对消息队列进行数据读取，若依然存在读取异常，则下下一次读取时间为4秒，当经过4秒后再次对消息队列进行数据读取，依次类推直到从消息队列读取得到第一数据和第二数据。

在一些实施例中，上述方法还可以包括如下步骤：将每个数据的缓存结果写入至消息队列；在将每个数据存储至数据库时，从消息队列中读取缓存结果。

在本实施例中，可以在消息队列中增加上述标签cacheFlag用以指示数据的缓存结果。对于未成功写入至缓存的数据，其标签cacheFlag＝0，而对于成功写入至缓存的数据，其标签cacheFlag＝1。在将消息队列中的数据存储至数据库的同时，可以根据该数据的标签来确定是否将其补录至缓存中。

本申请实施例通过将缓存结果写入至消息队列中，在数据存入数据库时可以直接参考缓存结果来确定是否需要对某些数据进行补录，能够有效保证缓存与数据库中数据的一致性。

在一些实施例中，上述方法还可以包括如下步骤：

检测是否有未成功写入至缓存的未写入数据；在检测到有未写入数据时，获取未写入数据的标识；将标识添加至预设名单中；将预设名单存储至服务器的本地内存中。

示例性的，可以将用户的ID作为标识，例如当用户参加“商品秒杀活动”时，未写入数据可以是订单信息等，订单信息中可以包括有用户的ID，进一步的，当用户参与多项活动时，还可以根据活动内容来进一步添加信息至标识中以区分不同的活动。例如当用户参加了“商品秒杀活动”和“抢红包活动”时，未写入数据对应的包括订单信息和红包信息，此时，订单信息的标识可以为用户ID+订单编号。

在本实施例中，当遇到缓存宕机或者瞬时网络抖动的情况时，可能造成用户的数据未成功写入到缓存中，此时会获取该用户的数据的标识并记录到预设名单中。

示例性的，如果用户发起了数据查询请求，例如查询抢到的红包金额或者订单信息，此时可以反馈“处理中”的消息给终端设备并在终端设备上显示，同时通过本地内存中存储的预设名单，判断该用户是否为预设名单中的用户，如果为预设名单中的用户，由于其数据为写入到缓存中，需要从数据库读取该用户的数据再反馈至终端设备进行显示，如果不为预设名单中的用户，则可以直接从缓存中查询该用户的数据再反馈至终端设备进行显示。

本申请实施例通过设置预设名单，将未成功写入至缓存的数据的标识添加至预设名单中并存储到本地内存。这样在用户查询数据时，可以根据预设名单确定出数据是否在缓存中，当不在缓存中时则可以从数据库查询数据，避免用户查询缓存时无数据。

进一步的，在一些实施例中，上述方法还包括步骤：

将预设名单备份至预设黑名单数据库中。

在本实施例中，当服务器本地内存中的预设名单丢失时(例如由于服务器重启导致的内存数据丢失)，可以从预设黑名单数据库中获取预设名单并加载到本地内存中，实现数据的恢复。示例性的，可以通过单播的方式将预设名单备份至预设黑名单数据库。

本申请实施例通过将预设名单备份至预设黑名单数据库，如果极端情况下服务器发生重启，造成本地内存数据丢失，则可以立刻请求预设黑名单数据库将预设名单加载到本地内存，保证系统的高可用性。

在一些实施例中，上述方法还可以包括如下步骤：

在未写入数据补录至缓存之后，将存储在服务器的本地内存中的预设名单中的标识移除；

将存储在预设黑名单数据库中的预设名单中的标识移除。

示例性的，用户A的数据未成功写入至缓存中时，用户A的ID会记录到预设名单中且预设名单会存储在本地内存，以及预设黑名单数据库中作为备份。当用户A的数据在写入数据库时，可以检测本地内存名单中是否包含有用户A的ID，若包含则将用户A的数据补录到缓存中，并将本地内存以及预设黑名单库中的预设名单中的用户ID移除，以避免发生数据重复补录。

其中，用户A的数据未成功补录到缓存中的原因可能是缓存出现宕机或者网络抖动。

示例性的，还可以使用中间件zookeeper来实现预设名单在各个服务器之间同步。

本申请实施例通过将补录成功之后的数据的标识从本地内存的预设名单以及预设黑名单数据库中的预设名单中移除，保证预设名单为最新名单，防止数据的重复补录以及避免在数据查询时频繁从数据库读取数据，增加数据库负载。

示例性的，在一些实施例中，上述方法还可以包括如下步骤：

将预设名单广播至分布式系统的其它服务器以指示其它服务器将预设名单存储至其它服务器的本地内存中。

在本实施例中，分布式系统通常由多个服务器同时部署，各个服务器之间需要保证数据一致性，通过广播的方式将预设名单广播至其它的服务器，能够保证各个服务器之间的数据一致性。

进一步的，在上述实施例的基础上，在一些实施例中，上述方法还可以包括如下步骤：

在未写入数据补录至缓存之后，将移除消息广播至分布式系统的其他服务器。

其中，移除消息用于指示其他服务器将第一数据的标识从其它服务器的本地内存中的预设名单中移除。

本申请实施例通过广播的形式通知各个服务器存储预设名单以及将对预设名单中的标识进行更新，保证各个服务器之间数据的一致性。

进一步的，在上述实施例的基础上，在一些实施例中，上述方法还可以包括如下步骤：

响应于目标数据的查询指令，确定目标数据是否为未成功写入至缓存的数据；若目标数据为未成功写入至缓存的数据，则从数据库中查询得到目标数据；若目标数据为成功写入至缓存的数据，则从缓存中查询得到目标数据。

在本实施例中，在将数据补录到缓存之前或补录过程中，用户可以发起数据查询请求，例如查询自己抢到的商品的订单信息、抢到的红包金额等。在缓存未出现异常的情况下，这些数据通常都会被写入到缓存中，此时可以直接从缓存中查询得到用户所需的目标数据。当缓存出现异常时则会导致数据未能成功写入到缓存中，此时则需要从数据库中查询得到目标数据。

其中，如果目标数据为成功写入到缓存的数据，则直接读取缓存并将写入至缓存中的目标数据反馈给终端设备并在终端设备的应用软件的页面上显示。如果目标数据为未成功写入到缓存的数据，则服务器会先反馈“处理中”的提示信息给终端设备并在终端设备的应用软件的页面上显示，此时如果用户继续操作并在应用软件上二级页面上继续请求查询目标数据时，则服务器直接从数据库查询该用户的目标数据，并反馈至终端设备应用软件上的二级页面上进行显示。

本申请实施例通过确定目标数据是否未成功写入至缓存中的数据，当目标数据为未成功写入至缓存中的数据时，可以在用户通过二级页面查询时从数据库查询得到目标数据以反馈给用户，避免查询缓存无数据的情况，同时也降低一级页面入口的并发访问量，改为二级页面查询数据库也能够降低数据库负载。

图3为本申请实施例提供的数据处理方法的系统结构示意图，如图3所示，在高频流量进入时，高频流量先写入到缓存31。无论数据是否成功写入至缓存31，都会通过消息队列传输到数据库34并存储到数据库34中。同时，消息队列也可以传输每一个数据的缓存结果，在数据存入到数据库34时，可以根据每个数据的缓存结果，将未成功写入到缓存31的数据补录到缓存31。同时，未成功写入至缓存31的数据的标识会被记录到黑名单35中，当补录完成之后再从黑名单35中移除。

在进行数据读取时，可以先查询黑名单35，如果黑名单35中有当前读取的目标数据的标识，则表示当前读取的这个数据没有被写入到缓存31中，需要从数据库34读取，而如果黑名单35中没有当前读取的目标数据的标识，则可以直接从缓存31中读取。

其中，消息队列包括有至少一个主消息队列32和一个辅消息队列33，当主消息队列32发生异常时则切换至备用的辅消息队列33以保证消息队列的高可用性。

图4为本申请实施例提供的数据写入过程的方法流程示意图，如图4所示，其包括有如下步骤：S400、开始。S401、高频流量写入。S402、缓存抗压。S403、判断是否缓存成功。S404、加入黑名单。S405、插入消息队列。S406、判断消息队列是否异常。S407、切换消息队列。S408、写入数据库。S409、判断是否需要补录。S410、补录缓存。S411、移除黑名单。S412、结束。

其中，在将数据插入至消息队列时，可以设置该数据的标签cachaflag。当该数据为写入缓存失败的数据时，该数据的标签cachaflag＝0，当该数据为写入缓存成功的数据时，该数据的标签cachaflag＝1。在判断是否需要补录时则可以直接根据数据的标签cachaflag的取值来确定是否需要将该数据补录至缓存中。

示例性的，消息队列可以包括有一个主消息队列和辅消息队列，在其中一个消息队列异常时可以切换至另外一个消息队列以保证高可用性。

图5为本申请实施例提供的数据处理方法实施例二的流程示意图，如图5所示，其包括如下步骤：

S501、高频流量写入。S502、缓存异常。S5031、广播消息。S5032、单播消息。S504、缓存补录成功。S505、数据入库。S5031、广播消息。S5032、单播消息。S506、数据查询。S507、查询黑名单。S508、确定是否命中黑名单。S509、读取缓存。S510、反馈处理中。S511、读取数据库。

在本实施例中，分布式系统可以包括N个服务器，N为不小于1的正整数。示例性的，如图5所示，分布式系统包括有4个服务器，每个服务器都具有各自的本地内存且互相同步。当缓存异常时，数据无法成功写入到缓存中，此时可以记录数据的标识至黑名单中并将黑名单广播给各个服务器以存储至其本地内存中。同时黑名单还会通过单播的方式存储到黑名单数据库中作为备份。

当数据成功补录至缓存中之后，将通过广播的方式通知各个服务器将本地内存的黑名单中记录的该数据的标识移除，同时通过单播的方式将黑名单数据库中该数据的标识移除。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图6为本申请实施例提供的数据处理装置的结构示意图，该数据处理装置可以应用于服务器中，也可以独立于服务器且与服务器协同实现本方案。如图6所示，该数据处理装置60包括结果获取模块61、数据传输模块62和数据补录模块63。

其中，结果获取模块61用于将接收到的至少一个数据写入至缓存，获取每个数据的缓存结果。数据传输模块62用于将至少一个数据传输至数据库进行存储。数据补录模块63用于在将每个数据存储至数据库时，根据数据的缓存结果，将未成功写入至缓存的数据补录至缓存中以使缓存中的数据与数据库中的数据相同。

其中，每个数据对应的缓存结果用于指示数据是否成功写入至缓存。

可选的，在一些实施例中，上述数据传输模块具体可以用于：

将未成功写入至缓存的第一数据和成功写入至缓存的第二数据均写入至消息队列；

读取写入至消息队列的第一数据和第二数据，存储至数据库。

可选的，在一些实施例中，若上述消息队列为主消息队列或辅消息队列，则上述数据传输模块具体可以用于：

当消息队列为主消息队列时，检测第一数据和第二数据中的至少一项在写入主消息队列时是否存在异常；

若存在异常，则将消息队列切换为辅消息队列，并将第一数据和第二数据重新写入至辅消息队列；

当消息队列为辅消息队列时，检测第一数据和第二数据中的至少一项在写入辅消息队列时是否存在异常；

若存在异常，则将消息队列切换为主消息队列，并将第一数据和第二数据重新写入至主消息队列。

可选的，在一些实施例中，上述数据传输模块具体还可以用于：

在读取写入至消息队列的第一数据和第二数据时，检测第一数据和第二数据当前是否存在读取异常；

若第一数据和第二数据当前存在读取异常，则获取截止当前读取异常发生的次数；

根据次数，确定下一次读取时间；

在下一次读取时间到来时，重新对写入至消息队列的第一数据和第二数据进行读取。

在一些实施例中，上述数据处理装置还可以包括结果写入模块，用于：

将每个数据的缓存结果写入至消息队列；

在将每个数据存储至数据库时，从消息队列中读取缓存结果。

在一些实施例中，上述数据处理装置还包括名单存储模块，用于：

检测是否有未成功写入至缓存的未写入数据；

在检测到有未写入数据时，获取未写入数据的标识；

将标识添加至预设名单中；

将预设名单存储至服务器的本地内存中。

在一些实施例中，上述数据处理装置还包括备份模块，用于将预设名单备份至预设黑名单数据库中。

在一些实施例中，上述数据处理装置还包括移除模块，用于：

在未写入数据补录至缓存之后，将存储在服务器的本地内存中的预设名单中的标识移除；

将存储在预设黑名单数据库中的预设名单中的标识移除。

在一些实施例中，上述数据处理装置还包括广播模块，用于将预设名单广播至分布式系统的其它服务器以指示其它服务器将预设名单存储至其它服务器的本地内存中。

在一些实施例中，上述数据处理装置还包括广播移除模块，用于在未写入数据补录至缓存之后，将移除消息广播至分布式系统的其他服务器。

其中，移除消息用于指示其他服务器将第一数据的标识从其它服务器的本地内存中的预设名单中移除。

在一些实施例中，上述数据处理装置还包括数据查询模块，用于：

响应于目标数据的查询指令，确定目标数据是否为未成功写入至缓存的数据；若目标数据为未成功写入至缓存的数据，则从数据库中查询得到目标数据；若目标数据为成功写入至缓存的数据，则从缓存中查询得到目标数据。

本申请实施例提供的装置，可用于执行上述实施例中的方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，数据传输模块可以为单独设立的处理元件，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上数据传输模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。

图7为本申请实施例提供的电子设备的结构示意图。如图7所示，该电子设备70包括：至少一个处理器71、存储器72、总线73及通信接口74。示例性的，电子设备可以是本地的计算机设备或者云端的服务器。

其中：处理器71、通信接口74以及存储器72通过总线73完成相互间的通信。

通信接口74用于与其它设备进行通信。该通信接口包括用于进行数据传输的通信接口等。处理器71，用于执行存储器72中存储的计算机执行指令，具体可以执行上述实施例中所描述的方法中的相关步骤。具体地，程序可以包括程序代码。

处理器71可能是中央处理器。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器72，用于存放计算机执行指令。存储器可能包含高速RAM存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。示例性的，存储器还可以用于存储上述的数据。

本实施例还提供一种可读存储介质，可读存储介质中存储有计算机指令，当电子设备的至少一个处理器执行该计算机指令时，电子设备执行上述的各种实施方式提供的数据处理方法。

本实施例还提供一种程序产品，该程序产品包括计算机指令，该计算机指令存储在可读存储介质中。电子设备的至少一个处理器可以从可读存储介质读取该计算机指令，至少一个处理器执行该计算机指令使得电子设备实施上述的各种实施方式提供的数据处理方法。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中，a，b，c可以是单个，也可以是多个。

可以理解的是，在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。