CN108076098A - 一种业务处理方法及系统 - Google Patents

Abstract

本发明公开了一种业务处理方法及系统，方法包括：二进制日志文件抽取服务器获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；分布式任务处理服务器集群中的任一分布式任务处理服务器监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。采用本发明能够解决现有技术任务处理服务器单点故障的问题。

Description

一种业务处理方法及系统

技术领域

本发明涉及数据处理技术领域，特别涉及一种业务处理方法及系统。

背景技术

如今，随着互联网行业的快速发展，大数据、高并发几乎是所有系统面临的共同的挑战。现有业务处理系统中的任务处理一般都是由多台任务处理服务器构成，其中一台任务处理服务器为主服务器，其他任务处理服务器为从服务器。主任务处理服务器定时扫描数据库中的任务记录，根据任务记录的任务类型进行相应的任务处理。如果主任务处理服务器出现故障，则重新选择主任务处理服务器进行业务处理。

由上述可以看出，现有技术中一个任务只能在任务处理服务器的单机、单进程中执行，会存在很多问题：

一、一旦发生任务处理服务器异常宕机，将无法确保任务的正常处理。

二、由于任务处理单机，在并发高、待处理任务数据量大的时候，会存在服务资源(CPU、内存等)过载，可能导致服务不可用，任务处理存在性能瓶颈，必将导致待处理任务积压，可能会严重影响生产流程。

三、现有技术中只有主任务处理服务器进行任务处理，未能将所有的任务处理服务器都利用起来处理任务，造成了部分任务处理服务器资源的闲置、浪费，未能合理利用任务处理服务器资源。

发明内容

本发明的目的在于提供一种业务处理方法及系统，能够解决现有技术任务处理服务器单点故障的问题。

为实现上述发明目的，本发明提供了一种业务处理方法，该方法包括：

二进制日志文件抽取服务器获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型；

分布式任务处理服务器集群中的任一分布式任务处理服务器监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

为实现上述发明目的，本发明还提供了一种业务处理系统，该系统包括：

二进制日志文件抽取服务器，用于获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型；

消息队列子系统，用于为消息体提供消息队列，以使分布式任务处理服务器监听到消息队列中的消息体；

分布式任务处理服务器，为分布式任务处理服务器集群中的任一服务器，用于监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

综上所述，本发明提供的业务处理方法及系统，与现有技术相比，通过在整个业务处理系统中，增加二进制日志文件抽取服务器和消息队列子系统，并且采用分布式任务处理服务器，如此，当数据库任务记录有更改时，二进制日志文件抽取服务器获取数据库二进制日志文件，进行数据解析，并组装成消息体发送到消息队列子系统的消息队列中；消息队列子系统作为消息中间件，创建消息队列，以使分布式任务处理服务器监听到消息队列中的消息体；分布式任务处理服务器集群中的各个分布式任务处理服务器之间相互独立，主动监听拉取消息队列中的消息体，进行任务处理。而现有技术中，主任务处理服务器定时扫描数据库中的任务记录，根据任务记录的任务类型进行相应的任务处理。如果主任务处理服务器出现故障，则重新选择主任务处理服务器进行业务处理。因此，本发明的方案基于数据库二进制日志文件解析技术，及消息中间件MQ机制，通过分布式任务处理服务器主动监听拉取消息队列中的消息体，进行任务处理，与现有技术相比，本发明中分布式任务处理服务器集群中的各个分布式任务处理服务器没有主从之分，采取谁监听到谁消费处理的原则，所有任务处理服务器都能处理任务，从而避免了现有技术单点故障的问题。

附图说明

图1为本发明业务处理方法的流程示意图。

图2为本发明业务处理系统的结构示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明所述方案作进一步地详细说明。

本发明的方案基于数据库二进制日志文件解析技术，及消息中间件MQ机制，通过分布式任务处理服务器主动监听拉取消息队列中的消息体，进行任务处理。本发明数据库可以采用MySQL数据库，MySQL数据库有各种不同类型的日志文件：错误日志、二进制日志、查询日志、慢查询日志、redo日志等，根据这些日志可以查询MySQL数据库执行的操作以及状态等信息，对于MySQL数据库的管理和维护来说，这些日志文件都是不可或缺的。其中，二进制日志(binlog)，记录了对MySQL数据库中任务记录的更改操作，例如：插入操作(insert)、更新操作(update)、删除操作(delete)等操作类型，每个更改操作都以一条记录的形式写入二进制日志文件中，每条记录中都包含了当前记录更新的时间戳、该记录在当前二进制日志文件中的位置(即：偏移量)以及与数据库更改操作相关的其他信息。

本发明业务处理方法流程示意图如图1所示：

步骤11、二进制日志文件抽取服务器获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型。

如果消息体发送异常，则二进制日志文件抽取服务器将所述消息体保存到本地数据库；定时扫描本地数据库发送异常的消息记录，并再次向消息队列子系统发送该消息体，直至消息体发送成功。

步骤12、分布式任务处理服务器集群中的任一分布式任务处理服务器监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

分布式任务处理服务器在验证消息体的有效性时，如果验证消息体无效，则向消息队列子系统报异常。

如果任务处理正常结束，则更新数据库中任务记录的任务状态为执行完成，并响应消息队列子系统任务处理成功；

如果任务处理异常结束，则更新数据库中任务记录的任务执行失败次数，并响应消息队列子系统任务处理异常，以使消息队列子系统保存所述消息体，定时扫描本地数据库处理异常的消息记录，并再次向分布式任务处理服务器发送该消息体，直至消息体对应的任务处理成功。

至此，完成了本发明的业务处理方法。

进一步地，优选地，即使二进制日志文件抽取服务器或者消息队列子系统发生故障时，业务处理系统可以通过降级的方式，依然能够实现任务处理服务器的高可用，具体实现为：当二进制日志文件抽取服务器或者消息队列子系统发生故障时，分布式任务处理服务器定时扫描数据库中的任务记录，根据任务记录的任务类型路由相应的任务处理逻辑。

基于同样的发明构思，本发明还提供了一种业务处理系统，结构示意图如图2所示，该系统包括：

二进制日志文件抽取服务器201，用于获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型；

消息队列子系统202，用于为消息体提供消息队列，以使分布式任务处理服务器监听到消息队列中的消息体；

分布式任务处理服务器203，为分布式任务处理服务器集群中的任一服务器，用于监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

如果消息体发送异常，则二进制日志文件抽取服务器201，还用于将所述消息体保存到本地数据库；定时扫描本地数据库发送异常的消息记录，并再次向消息队列子系统发送该消息体，直至消息体发送成功。

分布式任务处理服务器203进行相应的任务处理之后，还用于，

如果任务处理正常结束，则更新数据库中任务记录的任务状态为执行完成，并响应消息队列子系统任务处理成功；

如果任务处理异常结束，则更新数据库中任务记录的任务执行失败次数，并响应消息队列子系统任务处理异常，以使消息队列子系统保存所述消息体，定时扫描本地数据库处理异常的消息记录，并再次向分布式任务处理服务器发送该消息体，直至消息体对应的任务处理成功。

分布式任务处理服务器203，在验证消息体的有效性时，如果验证消息体无效，则向消息队列子系统报异常。

当二进制日志文件抽取服务器201或者消息队列子系统202发生故障时，分布式任务处理服务器203，还用于定时扫描数据库中的任务记录，根据任务记录的任务类型路由相应的任务处理逻辑。

实施例一

为清楚说明本发明，下面列举具体应用场景进行说明。本实施例中：业务处理系统包括：业务应用子系统、二进制日志文件抽取服务器、消息队列子系统、分布式任务处理服务器集群。

1)在手机充值业务中，在用户支付成功后，业务应用子系统在MySQL数据库中插入一条充值任务记录，包括：任务ID、任务类型、任务状态、任务执行失败次数，还可以包括业务关联ID、业务附加信息等字段。

其中，任务类型为充值，任务状态分为等待执行、执行中、执行失败、执行完成四种状态。本实施例中此时是等待分布式任务处理服务器将用户支付的金额充值到手机上，因此任务状态为等待执行。业务关联ID本实施例中可以是用户支付成功后给出的订单号信息，当充值任务执行的时候，可以根据业务关联ID确定具体是哪条订单号信息。由于具体任务执行的时候所需要的参数不一样，所以任务记录中可以有业务附加信息包含与该任务相关的其他信息，业务附加信息一般会存储一个json串。

2)MySQL数据库开启二进制日志文件写入功能，当业务应用子系统在MySQL数据库中插入一条充值任务记录时，形成二进制日志文件，该二进制日志文件记录了对数据库中任务记录的更改操作。

3)二进制日志文件抽取服务器监听抽取上述二进制日志文件，对抽取到的二进制日志文件进行解析，然后通过筛选过滤等操作获取到任务记录变更的至少三个字段信息，包括：字段一、数据库名称，用于表示从哪个数据库插入了充值任务记录；字段二、任务ID，用于查找任务；字段三、更改数据库任务记录的具体操作类型，本实施例中操作类型为“insert”。然后将上述任务记录变更的至少三个字段信息通过程序拼接成json字符串或xml对象通过MQ发送到消息队列子系统的消息队列中。也就是说，通过筛选过滤以及格式制作而组装成的消息体范例可以是：

{“database”：“db1”，“task ID”：“1200000000001”，“optype”：“insert”}

其中，消息队列(MQ)是一种应用程序对应用程序的通信方法。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。本发明消息队列子系统作为消息中间件，创建消息队列，以使二进制日志文件抽取服务器将消息体放到消息队列中，然后分布式任务处理服务器从消息队列拉取消息体。

如果二进制日志文件抽取服务器发送消息体异常，则写入二进制日志文件抽取服务器本地数据库，保证消息体不丢失；然后，定时扫描二进制日志文件抽取服务器本地数据库发送异常的消息记录，并再次向消息队列子系统发送该消息体，直至消息体发送成功。

4)本发明采用分布式任务处理服务器集群，该集群中包括多个分布式任务处理服务器，没有主从之分，采取谁监听到谁消费处理的原则，所有服务器都能处理任务。本实施例中分布式任务处理服务器用于根据任务记录将用户支付的金额充值到手机上。

分布式任务处理服务器集群中的任一分布式任务处理服务器监听到消息队列子系统消息队列中的消息体后解析所述消息体，验证消息体的有效性，如果无效，则向消息队列子系统报异常。如果有效，则根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

也就是说，当查询到任务状态为等待执行或者是执行失败时，则根据任务类型为充值类型，确定相应的任务处理的线程池，然后将该任务交给线程池处理相关逻辑。

如果任务处理正常结束，则分布式任务处理服务器更新数据库中任务记录的任务状态为执行完成，并响应消息队列子系统任务处理成功。

如果任务处理异常结束，则分布式任务处理服务器更新数据库中任务记录的任务执行失败次数，将失败次数加一，并响应消息队列子系统任务处理异常。消息队列子系统将记录消息处理异常状态保证消息不丢失，并通过MQ的重试机制继续投递该异常消息，直至任务最终处理完成。

由上述实施例可以看出，通过上述方案，任务可以由分布式任务处理服务器集群中的任一分布式任务处理服务器进行处理，分布式任务处理服务器主动监听拉取消息队列中的消息体，进行任务处理。而现有技术中，在主任务处理服务器不发生故障的情况下，一直是主任务处理服务器进行任务处理。与现有技术相比，本发明中分布式任务处理服务器集群中的各个分布式任务处理服务器没有主从之分，采取谁监听到谁消费处理的原则，所有任务处理服务器都能处理任务，从而避免了现有技术单点故障的问题。

需要说明的是，MySQL数据库的binlog日志解析需要一定开发量，可采用canal工具或其他框架。另外，消息队列子系统可以采用主流技术框架ActiveMQ、kafka等消息中间件，以保证实时性和准确性。

实施例二

在实施例一中基于数据库二进制日志文件解析技术，及消息中间件MQ机制，通过分布式任务处理服务器主动监听拉取消息队列中的消息，进行任务处理。当二进制日志文件抽取服务器或消息队列子系统，一方存在故障的情况下会影响任务处理的及时性，为了保障任务处理服务的高可用，本发明业务处理系统提供降级方案：

步骤21、分布式任务处理服务器定时扫描数据库中的任务记录，

步骤22、分布式任务处理服务器根据任务记录的任务类型进行相应的任务处理。

由此可以看出，通过降级处理，不使用二进制日志文件抽取服务器和消息队列子系统，可以像现有技术那样选择一个任务处理服务器作为主处理服务器，直接对任务记录进行扫描并进行任务处理。保障了任务处理服务器的高可用，进一步提高了系统的容错性。

本发明的业务处理方法，会带来如下好处：

一、本发明的方案基于数据库二进制日志文件解析技术，及消息中间件MQ机制，通过分布式任务处理服务器集群中的分布式任务处理服务器主动监听拉取消息队列中的消息体，进行任务处理，解决了单点故障的问题。不需要像现有技术那样一个任务只能在任务处理服务器的单机、单进程中执行。

二、通过数据库binlog解析技术，能够快速提取到任务的更改操作，因此，二进制日志文件抽取服务器主要用于监听数据库binlog变化并提取任务记录的变更，然后通过消息队列子系统将任务记录的变更发送至消息队列。二进制日志文件抽取服务器几乎能够同步感知到任务记录的变更，具有低延时的特性；分布式任务处理服务器通过主动监听消息队列的消息来驱动任务的处理，实现了任务处理的分布式，在系统并发高、任务数据量大的情况即使出现任务处理服务器性能瓶颈，任务处理系统可以很容易通过水平扩容等方式来解决这个问题。

三、本发明分布式任务处理服务器集群中的任务处理服务器是没有主从之分，相互独立的，而且每台任务处理服务器的资源都能得到合理的利用，有效避免了资源浪费。本方案在流量洪峰时扩容简单方便；在流量平稳的时候也能很容易对任务处理服务器进行缩容。

四、任务处理分布式、任务处理服务器不区分主从，所有任务处理服务器都能处理任务，若任务处理服务器集群中的任务处理服务器出现部分不可用的情况，整体任务处理基本不受影响。

五、即使二进制日志文件抽取服务器或消息队列子系统出现故障，任务处理系统通过降级依然能够实现任务处理服务器服务的高可用。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种业务处理方法，其特征在于，该方法包括：

二进制日志文件抽取服务器获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型；

分布式任务处理服务器集群中的任一分布式任务处理服务器监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

2.如权利要求1所述的方法，其特征在于，该方法进一步包括：如果消息体发送异常，则二进制日志文件抽取服务器将所述消息体保存到本地数据库；定时扫描本地数据库发送异常的消息记录，并再次向消息队列子系统发送该消息体，直至消息体发送成功。

3.如权利要求1所述的方法，其特征在于，分布式任务处理服务器进行相应的任务处理之后，该方法进一步包括：

如果任务处理正常结束，则更新数据库中任务记录的任务状态为执行完成，并响应消息队列子系统任务处理成功；

如果任务处理异常结束，则更新数据库中任务记录的任务执行失败次数，并响应消息队列子系统任务处理异常，以使消息队列子系统保存所述消息体，定时扫描本地数据库处理异常的消息记录，并再次向分布式任务处理服务器发送该消息体，直至消息体对应的任务处理成功。

4.如权利要求1所述的方法，其特征在于，分布式任务处理服务器在验证消息体的有效性时，如果验证消息体无效，则向消息队列子系统报异常。

5.如权利要求1所述的方法，其特征在于，当二进制日志文件抽取服务器或者消息队列子系统发生故障时，分布式任务处理服务器定时扫描数据库中的任务记录，根据任务记录的任务类型路由相应的任务处理逻辑。

6.一种业务处理系统，其特征在于，该系统包括：

二进制日志文件抽取服务器，用于获取更改数据库任务记录时形成的二进制日志文件，对所述二进制日志文件进行解析并组装成消息体发送到消息队列子系统的消息队列中；所述任务记录包括任务ID、任务类型、任务状态、任务执行失败次数；所述二进制日志文件记录了对数据库中任务记录的更改操作，所述组装成的消息体包括字段：数据库名称、任务ID、更改操作的具体类型；

消息队列子系统，用于为消息体提供消息队列，以使分布式任务处理服务器监听到消息队列中的消息体；

分布式任务处理服务器，为分布式任务处理服务器集群中的任一服务器，用于监听到消息队列子系统消息队列中的消息体后解析所述消息体，在验证所述消息体的有效性之后，根据消息体中数据库名称确定任务记录所在的数据库，根据消息体中任务ID确定该数据库中相应的任务记录，根据任务记录中的任务状态，判断任务是否已成功执行；如果否，则根据任务记录中的任务类型进行相应的任务处理。

7.如权利要求6所述的系统，其特征在于，如果消息体发送异常，则二进制日志文件抽取服务器，还用于将所述消息体保存到本地数据库；定时扫描本地数据库发送异常的消息记录，并再次向消息队列子系统发送该消息体，直至消息体发送成功。

8.如权利要求6所述的系统，其特征在于，分布式任务处理服务器进行相应的任务处理之后，还用于，

如果任务处理正常结束，则更新数据库中任务记录的任务状态为执行完成，并响应消息队列子系统任务处理成功；

如果任务处理异常结束，则更新数据库中任务记录的任务执行失败次数，并响应消息队列子系统任务处理异常，以使消息队列子系统保存所述消息体，定时扫描本地数据库处理异常的消息记录，并再次向分布式任务处理服务器发送该消息体，直至消息体对应的任务处理成功。

9.如权利要求6所述的系统，其特征在于，分布式任务处理服务器，在验证消息体的有效性时，如果验证消息体无效，则向消息队列子系统报异常。

10.如权利要求6所述的系统，其特征在于，当二进制日志文件抽取服务器或者消息队列子系统发生故障时，分布式任务处理服务器，还用于定时扫描数据库中的任务记录，根据任务记录的任务类型路由相应的任务处理逻辑。