CN113220730B - 业务数据的处理系统 - Google Patents

Abstract

本申请提供一种业务数据的处理系统，包括：至少一个接收设备、至少一个处理设备以及缓存数据库，接收设备接收第一业务数据，并将第一业务数据存储至缓存数据库，以及向处理设备发送第一业务数据，处理设备对接收到的第一业务数据进行处理，并在缓存数据库中删除第一业务数据；这样，接收设备可以在缓存数据库中获取未处理的第二业务数据，并向处理设备发送第二业务数据。从而，实现了利用缓存数据库来避免业务数据在转发过程中发生丢失，从而保证业务数据的完整性。

Description

业务数据的处理系统

技术领域

本申请涉及数据处理技术领域，尤其涉及一种业务数据的处理系统。

背景技术

通常，业务数据的处理系统需要从业务数据的生产系统接收业务数据，并对接收到的业务数据进行实时地加工处理。例如，需要在每秒内将接收到的业务数据处理完成。

而实际应用中，一些应用场景的业务数据并发性较高，因此，业务数据的处理系统每秒内接收到的数据量很大。当业务数据的加工处理逻辑较为复杂时，业务数据的处理系统处理每个业务数据的耗时较长，因此，经常会出现接收到的业务数据无法及时加工处理完成的情况，使得业务数据的实时性无法保证。

为了保证业务数据的实时性，可以采用分层处理的方式。具体的，将业务数据的处理系统分为两层。第一层包括至少一个接收设备，第二层包括至少一个处理设备。其中，第一层中的接收设备负责接收业务数据并将业务数据转发到第二层。第二层中的处理设备用于接收转发过来的业务数据，并对业务数据进行加工处理。然而，上述的转发过程可能会丢失业务数据，无法保证业务数据的完整性。

发明内容

本申请提供一种业务数据的处理系统，用以同时保证业务数据的实时性和完整性。

本申请提供的业务数据的处理系统，包括：至少一个接收设备、至少一个处理设备以及缓存数据库，其中，

所述接收设备用于，接收第一业务数据，将所述第一业务数据存储至所述缓存数据库，以及向所述处理设备发送所述第一业务数据；

所述处理设备用于，对接收到的所述第一业务数据进行处理，并在所述缓存数据库中删除所述第一业务数据；

所述接收设备还用于，在所述缓存数据库中获取未处理的第二业务数据，并向所述处理设备发送所述第二业务数据，所述第二业务数据在所述缓存数据库中的存储时长大于或等于预设时长。

一种可能的实现方式中，在所述缓存数据库中获取未处理的第二业务数据，包括：

确定所述缓存数据库中各业务数据的存储时刻；

根据所述缓存数据库中各业务数据的存储时刻和当前时刻，确定所述缓存数据库中各业务数据的存储时长；

根据所述缓存数据库中各业务数据的存储时长，在所述缓存数据库中获取未处理的第二业务数据。

一种可能的实现方式中，所述系统还包括负载均衡设备；向所述处理设备发送所述第一业务数据，包括：

向所述负载均衡设备发送所述第一业务数据；

所述负载均衡设备用于，接收所述接收设备发送的所述第一业务数据，根据所述至少一个处理设备中各处理设备的负载，在所述至少一个处理设备中确定目标处理设备，并向所述目标处理设备发送所述第一业务数据。

一种可能的实现方式中，向所述负载均衡设备发送所述第一业务数据，包括：

在连接池中确定目标连接，所述连接池中包括多个预先建立的连接，所述连接用于连接至所述负载均衡设备；

通过所述目标连接向所述负载均衡设备发送所述第一业务数据。

一种可能的实现方式中，在连接池中确定目标连接，包括：

确定所述连接池中各连接的连接状态，所述连接状态为占用状态或者非占用状态；

将所述连接池中非占用状态的一个连接确定为所述目标连接。

一种可能的实现方式中，所述接收设备还用于：

在连接池中确定目标连接之后，将所述目标连接的状态设置为占用状态。

一种可能的实现方式中，所述接收设备还用于：

在通过所述目标连接向所述负载均衡设备发送所述第一业务数据之后，将所述目标连接的状态设置为非占用状态。

一种可能的实现方式中，所述连接池中的连接为无确认的超文本传输协议HTTP连接。

一种可能的实现方式中，向所述目标处理设备发送所述第一业务数据，包括：

根据所述第一业务数据的业务类型，在所述目标处理设备的多个处理接口中确定目标处理接口；

向所述目标处理设备的所述目标处理接口发送所述第一业务数据。

一种可能的实现方式中，所述系统还包括消息总线；接收第一业务数据，包括：

从所述消息总线接收待处理消息，所述待处理消息中包括多个业务数据；

对所述待处理消息进行解析处理，得到多个业务数据；

在所述多个业务数据中获取所述第一业务数据。

本申请提供的业务数据的处理系统，包括：至少一个接收设备、至少一个处理设备以及缓存数据库，接收设备接收第一业务数据，并将第一业务数据存储至缓存数据库，以及向处理设备发送第一业务数据，处理设备对接收到的第一业务数据进行处理，并在缓存数据库中删除第一业务数据；这样，接收设备可以在缓存数据库中获取未处理的第二业务数据，并向处理设备发送第二业务数据。这样，实现了利用缓存数据库来避免业务数据在转发过程中发生丢失，从而保证业务数据的完整性。

附图说明

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

图1为本申请实施例提供的一种系统架构的示意图；

图2为本申请实施例提供的一种业务数据的处理系统的示意图；

图3为本申请实施例提供的另一种业务数据的处理系统的示意图；

图4为本申请实施例提供的又一种业务数据的处理系统的示意图；

图5为本申请实施例提供的一种业务数据的处理过程的示意图；

图6为本申请实施例提供的另一种业务数据的处理过程的示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，对本申请实施例中涉及的概念或者术语进行解释。

远程字典服务(Remote Dictionary Server，Redis)数据库：是一个键值对(key-value)存储系统。它是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的应用程序接口(ApplicationProgramming Interface，API)。它通常被称为数据结构服务器，因为值(value)可以是字符串(String),哈希(Hash),列表(list),集合(sets)和有序集合(sorted sets)等类型。其性能极高，Redis能读的速度是110000次/s,写的速度是81000次/s。

Kafka：一个分布式流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

传输控制协议(Transmission Control Protocol，TCP)：是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP旨在适应支持多网络应用的分层协议层次结构。连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。

超文本传输协议(HyperText Transfer Protocol，HTTP)协议：因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。HTTP基于TCP/IP通信协议来传递数据(例如，超文本标记语言(Hyper Text Markup Language，HTML)文件、图片文件、查询结果等)。

事务：事务主要用于处理操作量大，复杂度高的数据。一般来说，事务是必须满足4个条件：：原子性(Atomicity，或称不可分割性)、一致性(Consistency)、隔离性(Isolation，又称独立性)、持久性(Durability)。

负载均衡：是一种计算机技术，用来在多个计算机(计算机集群)、网络连接、中央处理器(Central Processing Unit，CPU)、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

下面，结合图1对本申请实施例所涉及的系统架构进行介绍。

图1为本申请实施例提供的一种系统架构的示意图。如图1所示，该系统架构包括：业务数据的生产系统、业务数据的处理系统以及消息总线。业务数据的生产系统可以产生业务数据，并将业务数据发送至消息总线。业务数据的处理系统可以从消息总线获取业务数据，并对业务数据进行处理。

可选的，如图1所示，该系统架构还可以包括业务数据库。业务数据的处理系统对业务数据处理完成后，将处理完成的业务数据存储至业务数据库中。

可选的，上述消息总线可以为kafka消息总线。

一些示例中，业务数据的生产系统可以包括一个或者多个终端设备。也就是说，由终端设备产生业务数据。另一些示例中，业务数据的生产系统可以包括一个或者多个业务服务器。也就是说，可以由业务服务器产生业务数据。业务数据的处理系统可以包括一个或者多个具有数据处理能力的电子设备。

需要说明的是，图1所示的系统架构可以应用于多种业务场景中，包括但不限于：银行业务场景、电商业务场景、社交业务场景、金融业务场景、保险业务场景等。本实施例对于具体的业务场景不作限定。应理解的是，当应用于不同业务场景中时，所对应的业务数据的内容可能不同，但是对业务数据的处理过程是类似的。为了便于理解，后续涉及举例时，均以银行业务场景为例进行举例说明。

举例而言。银行业务场景中，一种业务数据为收支明细数据。用户数量较多，每天产生数亿条的收支明细数据，平均每秒钟产生的收支明细数据的数量达到数千条。一些场景下(比如购物节等)产生的收支明细数据的数量更大。并且，银行业务系统要求对每条收支明细数据进行实时处理。其中，每条收支明细数据的加工逻辑复杂且加工维度多。例如，需要将每条收支明细数据转换成预设格式，还需要根据每条收支明细数据对用户的日汇总、月汇总、年汇总收入支出进行更新，还需要根据每条收支明细数据对当月最高的若干笔收入支出进行更新，等等，使得对每条收支明细数据的加工处理耗时较长。

为了保证业务数据的实时性，业务数据的处理系统在每秒接收到的业务数据必须在每秒内加工处理完成，否则会形成业务数据的堆积。以Kafka消息总线为例，Kafka消息总线最多支持18个节点，也就是说，最多能有18台机器并发地从kafka消息总线接收业务数据，如果只是单纯的从Kafka消息总线接收业务系统的话，18台机器完全能够胜任。但是如果每台机器还要对接收到的业务数据进行加工处理的话，由于业务数据接收速度很快，但每条业务数据的加工处理却非常耗时，因此会导致接收到的业务数据发生堆积，从而影响业务数据的实时性。

另外，当业务数据堆积的时长较长时，例如在预设时长(例如10秒)内没有加工处理完成，Kafka消息总线会认为该业务数据发生丢失，因此会重发该条业务数据。这样随着时间的累积，堆积的业务数据会越来越多，Kafka消息总线重发的业务数据也会越来越多，进一步影响了业务数据的实时性。

一种可能的实现方式中，为了提高业务数据的实时性，在业务数据的处理系统内部采用分层的方式。下面结合图2进行描述。

图2为本申请实施例提供的一种业务数据的处理系统的示意图。如图2所示，将业务数据的处理系统分为两层。第一层包括至少一个接收设备，第二层包括至少一个处理设备。其中，第一层中的接收设备用于从Kafka消息总线接收业务数据，并且将业务数据转发到第二层，然后再进行下一个业务数据的接收与转发。第二层中的处理设备用于接收转发过来的业务数据，并对业务数据进行加工处理。

这样，第一层中的接收设备只负责接收和转发，因此速度很快，不会造成业务数据的堆积。第二层中的处理设备负责对业务数据进行加工处理，可以通过增加处理设备的数量，来保证业务数据的处理实时性。例如，处理设备的数量大于接收设备的数量。

然而，图2所示的业务数据的处理系统中，由于涉及到第一层和第二层之间的通信，第一层中的接收设备在向第二层中的处理设备转发业务数据的过程中，可能会发生业务数据的丢失，影响业务数据的完整性。

为了避免业务数据在转发过程中丢失，第一层中的接收设备需要通过可靠的连接将业务数据转发给第二层中的处理设备。其中，可靠的连接是指需要返回确认的连接，例如，基于HTTP或者TCP协议的连接。

具体的，在接收设备与处理设备之间新建可靠的连接。参见图2，接收设备通过该连接将业务数据发送给处理设备。处理设备接收到业务数据，并对业务数据进行加工处理后，向接收设备返回成功确认。若接收设备在预设时长内未接收到成功，则说明该业务数据发生丢失，接收设备会对该业务数据进行重发。上述通信方式是可靠的，能够保证业务数据不丢失，从而保证业务数据的完整性。

然而，基于上述可靠的连接，在处理设备对业务数据进行加工处理期间，接收设备和处理设备之间的连接需要一直保持，只有在接收设备接收到成功后，才可以释放连接。这样，在业务数据高并发的场景下，第一层和第二层之间会保持大量的连接，使得后续的业务数据必须排队等待连接释放，一方面导致了实时性大大降低，无法满足业务实时性的要求，另一方面由于接收设备需要对大量的连接进行维护，使得接收设备的负载过大。

如果采用不可靠的连接的话(即，接收设备向处理设备转发业务数据后，不要求处理设备向接收设备发送成功确认)，接收设备在发送完业务数据后可以立即释放连接，以将连接给后续业务数据使用，这样实时性能够保证，但是这样又会存在业务数据丢失的问题，使得业务数据的完整性无法保证。可见，业务数据的实时性和完整性是个此消彼长的问题。

另外，若某个处理设备在加工数据的过程中发生崩溃或者重启，该处理设备正在加工处理的业务数据也会发生丢失。

为了解决上述技术问题中的至少一个，本申请提供一种业务数据的处理系统，可以不用采用可靠的连接来保证业务数据的不丢失，而是通过在业务数据的处理系统中增加缓存数据库，利用缓存数据库来避免业务数据在转发过程中发生丢失，从而保证业务数据的完整性。

进一步的，由于无需采用可靠的连接，因此，接收设备向处理设备转发业务数据后，可以立即释放连接，使得连接可用于传输后续的业务数据，从而保证业务数据的实时性。可见，本申请提供的业务数据的处理系统，可以同时保证业务数据的实时性和完整性。

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

图3为本申请实施例提供的另一种业务数据的处理系统的示意图。如图3所示，本实施例提供的业务数据的处理系统包括：至少一个接收设备、至少一个处理设备以及缓存数据库。

其中，接收设备用于接收第一业务数据，并将所述第一业务数据存储至所述缓存数据库中，以及向处理设备发送所述第一业务数据。处理设备用于对接收到的第一业务数据进行处理，并在所述缓存数据库中删除所述第一业务数据。

本实施例中，当接收设备的数量为多个时，多个接收设备可以组成接收设备集群。当处理设备的数量为多个时，多个处理设备可以组成处理设备集群。

可选的，在业务数据的加工处理逻辑较为复杂的场景下，由于接收设备接收业务数据并向处理设备转发业务数据的耗时较少，而处理设备对业务数据进行加工处理的耗时较长，为了避免业务数据的堆积，处理设备的数量可以多于接收设备的数量。

本实施例在图2所示实施例的基础上，增加了缓存数据库。接收设备接收到第一业务数据后，将第一业务数据存储至缓存数据库中，以及向处理设备发送第一业务数据。当处理设备对接收到的第一业务数据进行处理后，将缓存数据库中的第一业务数据删除。可见，缓存数据库中存储的是：接收设备已向处理设备转发、而处理设备还未处理完成的业务数据。这样，接收设备可以根据缓存数据库，确定出哪些业务数据发生丢失，进而可以对这些业务数据进行重新转发，以保证业务数据的完整性。

具体而言，接收设备还用于，在缓存数据库中获取未处理的第二业务数据，并向所述处理设备发送所述第二业务数据，所述第二业务数据在所述缓存数据库中的存储时长大于或者等于预设时长。

应理解，第二业务数据是接收设备曾经转发过的业务数据，由于第二业务数据在缓存数据库中的存储时长大于或者等于预设时长(即，第二业务数据在预设时长内没有被处理设备删除)，因此，可以认为第二业务数据在转发过程中发生丢失。接收设备可以向处理设备重发第二业务数据。

一种可能的实现方式中，接收设备可以采用如下方式在缓存数据库中获取未处理的第二业务数据：接收设备确定缓存数据库中各业务数据的存储时刻，根据缓存数据库中各业务数据的存储时刻和当前时刻，确定缓存数据库中各业务数据的存储时长，进而，根据缓存数据库中各业务数据的存储时长，在缓存数据库中获取未处理的第二业务数据。示例性的，将缓存数据库中存储时长大于或者等于预设时长的业务数据，作为第二业务数据。

可选的，上述的缓存数据库可以为redis数据库。redis数据库为基于内存的数据库，读写性能佳，能够保证业务数据的实时性。

本实施例提供的业务数据的处理系统，包括：至少一个接收设备、至少一个处理设备以及缓存数据库，接收设备接收第一业务数据，并将第一业务数据存储至缓存数据库，以及向处理设备发送第一业务数据，处理设备对接收到的第一业务数据进行处理，并在缓存数据库中删除第一业务数据；这样，接收设备可以在缓存数据库中获取未处理的第二业务数据，并向处理设备发送第二业务数据。这样，实现了利用缓存数据库来避免业务数据在转发过程中发生丢失，从而保证业务数据的完整性。

进一步的，在通过缓存数据库保证业务数据的完整性的基础上，接收设备可以通过不可靠的连接向处理设备发送业务数据。也就是说，接收设备向处理设备发送业务数据后，可以立即释放连接，而无需等待接收到处理设备的成功确认后再释放。这样，一方面可以提高业务数据的实时性，另一方面，接收设备不再需要对大量的连接进行维护，降低了接收设备的负载。可见，本实施例的业务数据的处理系统可以同时保证业务数据的完整性和实时性。

图4为本申请实施例提供的又一种业务数据的处理系统的示意图。在图3所示实施例的基础上，本实施例提供的业务数据的处理系统中还包括负载均衡设备，负载均衡设备负责实现所述至少一个处理设备的负载均衡。

如图4所示，接收设备接收到第一业务数据后，将第一业务数据存储至所述缓存数据库，并向负载均衡设备发送第一业务数据。负载均衡设备用于，接收所述接收设备发送的所述第一业务数据，根据所述至少一个处理设备中各处理设备的负载，在所述至少一个处理设备中确定目标处理设备，并向所述目标处理设备发送所述第一业务数据。

通过对各处理设备的负载进行均衡，能够提高业务数据的处理效率，进而提高业务数据的实时性。

可选的，如图4所示，本实施例的接收集群中还可以设置有连接池。连接池中包括多个预先建立的连接，所述连接用于连接至负载均衡设备。在接收设备向负载均衡发送第一业务数据时，可以在连接池中确定目标连接，通过目标连接向负载均衡设备发送第一业务数据。

其中，连接池是维护着一定数量长连接的集合。接收设备接收到业务数据时，从资源池获取一个长连接，如果有处于非占用状态的长连接，就获取到这个长连接，并把这个长连接的状态置为占用状态。如果所有长连接都处于占用状态，且所有长连接的数量小于配置的预设数据(即连接池中长连接的最大数量)，则新建一个长连接，如果所有长连接的数量不小于配置的预设数量，则将当前业务数据加入到等待队列去。当存在某个长连接处于非占用状态后，就使用该长连接来传输等待队列中的业务数据。

本实施例中，连接池中的连接可以为HTTP连接。HTTP是建立在TCP协议之上的应用层协议。TCP协议建立连接时要经过三次握手进行连接确认，在释放连接时需要经过四次挥手进行连接释放，而真正数据传输的时间却很短，所以大部分时间都消耗在连接确认和释放连接上了，因此本实施例中通过使用连接池能够减少创建连接和释放连接的开销，增加数据传输速率，增强系统负载。

进一步的，所述连接池中的连接为无确认的HTTP连接。即，接收设备通过目标连接向处理设备转发业务数据之后，无需处理设备向接收设备发送确认消息，可以直接释放该目标连接，使得目标连接可用于发送后续的业务数据，从而提高业务数据的实时性。

示例性的，接收设备可以确定出连接池中各连接的连接状态，每个连接的连接状态为占用状态或者非占用状态。接收设备将所述连接池中非占用状态的一个连接确定为所述目标连接。

可选的，接收设备在连接池中确定出目标连接之后，将目标连接的状态设置为占用状态。

可选的，接收设备在通过目标连接向负载均衡设备发送第一业务数据之后，将目标连接的状态设置为非占用状态。这样，该目标连接可用于传输后续的业务数据。

下面，结合一个具体的示例，对图4所示的业务数据的处理系统对业务数据的处理过程进行举例说明。

图5为本申请实施例提供的一种业务数据的处理过程的示意图。如图5所示，本实施例提供的业务数据的处理过程，包括：

S501：接收设备从消息总线接收第一业务数据。

可选的，上述消息总线可以为Kafka消息总线。

接收设备从Kafka消息总线接收待处理消息，待处理消息中包括多个业务数据。接收设备对待处理消息进行解析处理，得到多个业务数据。在多个业务数据中每个业务数据依次作为第一业务数据，并针对第一业务数据进行后续的处理。

一个示例中，接收设备从Kafka消息总线接收到待处理消息后，对待处理消息进行如下两方面的处理：

(1)对待处理消息进行拆分。当业务数据的生产系统生产了业务数据后，将业务数据发送至Kafka消息总线。Kafka消息总线将多条业务数据放在一个消息中，以消息为单位传递至业务数据的处理系统。这样能够有效减少Kafka消息总线与业务数据的处理系统之间的连接的数量，增加业务数据的处理系统的负荷能力，增强业务数据传输的实时性。接收设备每次从Kafka消息总线接收到待处理消息后，从待处理消息中解析得到多个业务数据，并针对每个业务数据进行分别处理。

(2)确定每个业务数据的业务类型。Kafka消息总线以主题(topic)的形式存储业务数据。接收设备接收的不同消息是按照topic进行分类的。例如，以银行业务场景为例，用户收支明细数据包括两种业务类型：借记卡明细类型和信用卡明细类型。这两种明细类型的加工处理逻辑是有区别的。所以接收设备需要确定出每个业务数据的业务类型，使得处理设备可以根据业务数据的业务类型，进行相应的加工处理逻辑。

本实施例中，使用kafka消息总线发送消息，使用接收设备集群接收消息，确保接收设备集群接收消息的速率大于kafka消息总线的发送速率，保证kafka消息总线中的消息不堆积。另外，即使是在极端情况下，接收设备集群发生故障，导致无法接收业务数据，由于kafka消息总线会对业务数据保留5天，也不会丢失业务数据。

S502：接收设备将第一业务数据存储至缓存数据库中。

举例而言，缓存数据库可以为Redis数据库。Redis数据库根据键值对存储业务数据。接收设备对待处理消息进行拆分和分类后，可以确定出第一业务数据的业务类型。进而可以根据业务数据的类型生成业务数据的key。例如，key的模式可以采用业务类型+主键(tablename:primarykey)的形式。业务类型(tablename)可以为借记卡明细类型(debitcard)或者信用卡明细类型(creditcard)。假设卡号、日期和流水号确定唯一一条收支明细数据，那么主键(primarykey)可以为卡号、日期和流水号的拼接。例如，某笔收支明细数据的卡号为622848888888888888，日期为20200101，流水号为123456789，那么该条收支明细数据的主键(primarykey)为：62284888888888888820200101123456789。假设第一业务数据为信用卡收支明细数据，则这条业务数据存入Redis数据库的key为：creditcard:62284888888888888820200101123456789，存入Redis数据库的value类型为字符串，与Kafka传送过来的第一业务数据的内容相同。

S503：接收设备从连接池中确定目标连接，将目标连接的连接状态置为占用状态。

S504：接收设备通过目标连接向负载均衡设备发送第一业务数据。

S505：接收设备将目标连接的状态置为非占用状态。

接收设备将第一业务数据存储至缓存数据库后，接收设备向负载均衡设备转发第一业务数据。为了提升业务数据转发的效率，接收设备集群中设置了HTTP连接池。当接收设备需要转发第一业务数据时，在连接池中查找非占用状态的目标连接，将目标连接置为占用状态，并通过目标连接向负载均衡设备转发第一业务数据。在转发第一业务数据后，不需要断开目标连接，而是释放该目标连接(将目标连接置为非占用状态)，以供后续业务数据使用。因为处理设备对业务数据的处理过程耗时较长，本实施例中，为了减少处理设备在对业务数据进行加工处理时，连接闲置的问题，接收设备在转发业务数据后，立刻释放目标连接，提高了接收设备的转发效率。

S506：负载均衡设备根据所述至少一个处理设备中各处理设备的负载，在所述至少一个处理设备中确定目标处理设备。

S507：负载均衡设备向目标处理设备发送第一业务数据。

本实施例中，各处理设备由负载均衡设备进行管理。负载均衡设备定义了一个服务访问的入口。对业务数据的加工处理逻辑运行在各处理设备上，各处理设备上运行的程序完全相同。接收设备不可直接访问处理设备，必须通过负载均衡设备的转发。当负载均衡设备接收到接收设备发送的业务数据后，负载均衡设备会按照预设的策略将业务数据分发给某个处理设备。

在处理设备中，不同业务类型对应的不同的处理接口。这样，不同业务类型的业务数据可以分发至对应的处理接口。示例性的，负载均衡设备可以根据第一业务数据的业务类型，在目标处理设备的多个处理接口中确定目标处理接口，向目标处理设备的目标处理接口发送第一业务数据。

示例性的，可以使用http协议，访问同一个根目录相下不同路径的URL。例如，借记卡明细发送到http://process:8080/debitcard，信用卡明细发送到http://process:8080/creditcard，其中，process:8080是处理设备的根目录，/debitcard和/creditcard是不同业务类型对应的路径。这样，处理设备可以根据业务数据的业务类型，确定采用哪种加工处理逻辑进行处理。

通过设置负载均衡设备，使得接收设备不必关心业务数据的具体去向，而只需要将业务数据转发至负载均衡设备即可。负载均衡设备可以按照平均策略向各处理设备分发业务数据，避免某台处理设备的负载过大，使得各业务数据均能最快速的处理完成。

S508：目标处理设备对第一业务数据进行处理。

S509：目标处理设备将第一业务数据的处理结果写入业务数据库中。

S510：目标处理设备在缓存数据库中删除第一业务数据。

目标处理设备接收到第一业务数据后，目标处理设备会启动一个事务，该事务包含以下操作：

(1)对第一业务数据进行加工处理，此部分为程序的主体，处理复杂，耗时长。

(2)对第一业务数据加工处理完成后，将加工处理后的第一业务数据存储至业务数据库中。

(3)根据第一业务数据的业务类型和主键，在Redis数据库中删除第一业务数据。

上述3项操作全部完成后关闭事务，否则回滚。

本实施例中，使用事务是为了保证业务数据加工处理时的一致性，防止加工处理时发生异常，导致部分业务数据录入业务数据库，或者，业务数据成功录入业务数据库，却没有删除Redis数据库中的对应记录。使用事务后，上述任意一项操作异常均会回滚，保证回到该业务数据未被加工且不删除Redis数据库中对应记录，直至等待接收设备重发该业务数据。

本实施例描述了第一业务数据的正常处理流程。下面结合图6所示实施例描述如何利用缓存数据库保证业务数据的完整性。

图6为本申请实施例提供的另一种业务数据的处理过程的示意图。本实施例的方法可以定时触发执行。如图6所示，本实施例的业务数据的处理过程，可以包括：

S601：接收设备确定缓存数据库中各业务数据的存储时刻。

S602：接收设备根据缓存数据库中各业务数据的存储时刻和当前时刻，确定缓存数据库中各业务数据的存储时长。

S603：接收设备根据缓存数据库中各业务数据的存储时长，在缓存数据库中获取未处理的第二业务数据，第二业务数据的存储时长大于或等于预设时长。

S604：若第二业务数据的重复发送次数小于或者等于预设次数，则接收设备向负载均衡设备发送第二业务数据。

应理解的是，接收设备向负载均衡设备发送第二业务数据的过程，其实是对第二业务数据的重发过程。该重发过程与上述实施例中接收设备向负载均衡设备发送第一业务数据的过程是类似的，此处不作赘述。

若第二业务数据的重复发送次数大于预设次数，则说明该第二业务数据存在问题，或者业务数据的处理系统可能存在问题，需要人工介入分析，可以向用户输出提示信息。

需要说明的是，本实施例对于预设时长以及预设次数的取值不做限定，可以根据实际应用场景进行合理取值。示例性的，预设时长可以为2分钟，预设次数可以为6次。

本申请实施例中，通过采用缓存数据库能够保证业务数据的完整性。下面分析在接收设备或者处理设备发生故障崩溃的情况下，业务数据的处理系统是如何保证业务数据不丢失的。

针对某个接收设备崩溃的情况。接收设备崩溃时其正在处理的业务数据会丢失，但是这部分业务数据因为没有对Kafka消息总线返回正确接收，所以超过预设时长(例如10秒)后，Kafka消息总线会重发这部分业务数据，该部分业务数据会被其他正常运行的接收设备接收。因此，在接收设备崩溃的情况下，不会丢失业务数据。

针对接收设备集群整体崩溃的情况，或者，因为网络原因接收设备集群无法接收到Kafka消息总线发送的业务数据的情况。该情况下，Kafka消息总线会对业务数据存储5天。只要在5天内解决接收设备集群崩溃的问题，就可以保证不丢失业务数据。

针对某个处理设备崩溃的情况。处理设备崩溃时其正在处理的业务数据会丢失。但是接收设备会定时扫描Redis数据库，并对这些丢失的业务数据进行重发。进而，这些丢失的业务数据会被负载均衡设备分发到其他正常运行的处理设备上进行加工处理。因此，在处理设备崩溃的情况下，也不会丢失业务数据。

可见，本申请实施例提供的业务数据的处理系统，能够保证发生崩溃问题时业务数据不丢失。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (8)

1.一种业务数据的处理系统，其特征在于，包括：至少一个接收设备、至少一个处理设备以及缓存数据库，其中，

所述接收设备用于，接收第一业务数据，将所述第一业务数据存储至所述缓存数据库，以及向所述处理设备发送所述第一业务数据；

所述处理设备用于，对接收到的所述第一业务数据进行处理，并在所述缓存数据库中删除所述第一业务数据；

所述接收设备还用于，在所述缓存数据库中获取未处理的第二业务数据，并向所述处理设备发送所述第二业务数据，所述第二业务数据在所述缓存数据库中的存储时长大于或等于预设时长；

所述系统还包括负载均衡设备；向所述处理设备发送所述第一业务数据，包括：

向所述负载均衡设备发送所述第一业务数据；

所述负载均衡设备用于，接收所述接收设备发送的所述第一业务数据，根据所述至少一个处理设备中各处理设备的负载，在所述至少一个处理设备中确定目标处理设备，并向所述目标处理设备发送所述第一业务数据；

向所述负载均衡设备发送所述第一业务数据，包括：

在连接池中确定目标连接，所述连接池中包括多个预先建立的连接，所述连接用于连接至所述负载均衡设备；

通过所述目标连接向所述负载均衡设备发送所述第一业务数据。

2.根据权利要求1所述的系统，其特征在于，在所述缓存数据库中获取未处理的第二业务数据，包括：

确定所述缓存数据库中各业务数据的存储时刻；

根据所述缓存数据库中各业务数据的存储时刻和当前时刻，确定所述缓存数据库中各业务数据的存储时长；

根据所述缓存数据库中各业务数据的存储时长，在所述缓存数据库中获取未处理的第二业务数据。

3.根据权利要求1所述的系统，其特征在于，在连接池中确定目标连接，包括：

确定所述连接池中各连接的连接状态，所述连接状态为占用状态或者非占用状态；

将所述连接池中非占用状态的一个连接确定为所述目标连接。

4.根据权利要求3所述的系统，其特征在于，所述接收设备还用于：

在连接池中确定目标连接之后，将所述目标连接的状态设置为占用状态。

5.根据权利要求4所述的系统，其特征在于，所述接收设备还用于：

在通过所述目标连接向所述负载均衡设备发送所述第一业务数据之后，将所述目标连接的状态设置为非占用状态。

6.根据权利要求1至5任一项所述的系统，其特征在于，所述连接池中的连接为无确认的超文本传输协议HTTP连接。

7.根据权利要求1所述的系统，其特征在于，向所述目标处理设备发送所述第一业务数据，包括：

根据所述第一业务数据的业务类型，在所述目标处理设备的多个处理接口中确定目标处理接口；

向所述目标处理设备的所述目标处理接口发送所述第一业务数据。

8.根据权利要求1至7任一项所述的系统，其特征在于，所述系统还包括消息总线；接收第一业务数据，包括：

从所述消息总线接收待处理消息，所述待处理消息中包括多个业务数据；

对所述待处理消息进行解析处理，得到多个业务数据；

在所述多个业务数据中获取所述第一业务数据。