数据处理系统和再保危险单位数据生成方法与流程

本发明涉及信息处理技术领域，尤其涉及一种数据处理系统和再保危险单位数据生成方法。

背景技术：

危险单位是指保险标的发生一次灾害事故可能造成的最大损失范围。为了转移风险，保险公司将其承担的部分保险业务分出给其他保险人，因此保险公司直保端的承保、批改、理赔需要生成再保危险单位数据，以便后续再保分出业务的处理。

目前保险公司直保端可能存在多个系统平台，比如健康险系统、车险系统、团险系统等不同的系统平台，这些系统平台都有再保分出业务的需求，因此都需要生成危险单位数据。

为了实现直保端各个系统平台生成危险单位数据，相关技术中，为各个系统平台设置单独的生成危险单位的模块。此外，每一个系统平台新增再保危险单位模块多是通过复制另一个系统平台的代码实现的，代码重复率高，导致修改新增功能时需要修改多个直保端系统平台，维护成本高，扩展性差。

技术实现要素：

本发明旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本发明的第一个目的在于提出一种数据处理系统，通过在生产者中写入通用的各服务模板类，并在配置文件中预先写入实现类，通过读取实现类和类实例即可得到所需的服务类，从而使得直保端中新增系统平台扩展再保业务变得异常方便，提高可扩展性；消费者统一处理生成不同系统平台的再保危险单位数据，对消费者的修改不依赖于各个系统平台，降低维护成本，提高可维护性，解决现有技术中存在的维护成本高、扩展性差的技术问题。

本发明的第二个目的在于提出一种再保危险单位数据生成方法。

本发明的第三个目的在于提出另一种再保危险单位数据生成方法。

本发明的第四个目的在于提出一种计算机设备。

本发明的第五个目的在于提出一种非临时性计算机可读存储介质。

本发明的第六个目的在于提出另一种计算机设备。

本发明的第七个目的在于提出另一种非临时性计算机可读存储介质。

为达上述目的，本发明第一方面实施例提出了一种数据处理系统，包括：与各个直保端系统平台对应的多个生产者，以及通过消息中间件与多个生产者通信的消费者；

所述生产者，设置于对应直保端系统平台的服务器上，预先写入了通用的各服务模板类，以及在配置文件中预先写入了实现类，用于在运行时，读取实现类并采用反射技术获取类实例，以及获取通用的各服务模板类中所述实现类涉及的方法，得到所需服务类，以采用所述服务类对从对应直保端系统平台获取的待办任务和业务数据进行处理，生成并发送业务消息；

所述消费者，设置于再保端系统平台的服务器上，采用线程池为接收到的各业务消息分配对应的线程，采用多线程方式对业务消息进行业务处理。

本发明实施例的数据处理系统，通过为直保端各个系统平台设置对应的生产者以及通过消息中间件与多个生产者进行通信的消费者，在生产者中预先写入通用的各服务模板类，并在配置文件中预先写入实现类，在运行时，读取实现类并采用反射技术获取类实例，并获取通用的各服务模板类中实现类涉及的方法得到所需服务类，采用服务类对从对应的系统平台获取的待办任务和业务数据进行处理，生成并发送业务消息，再保端的消费者对接收到的各业务消息采用多线程方式进行业务处理。通过在生产者中写入通用的各服务模板类，并在配置文件中预先写入实现类，通过读取实现类和类实例即可得到所需的服务类，能够提高直保端中新增系统平台扩展再保业务的便捷性，提高了可扩展性；消费者统一处理生成不同系统平台的再保危险单位数据，对消费者的修改不依赖于各个系统平台，降低了维护成本，提高了可维护性，解决了现有技术中存在的维护成本高、扩展性差的技术问题。

为达上述目的，本发明第二方面实施例提出了一种再保危险单位数据生成方法，应用于第一方面实施例所述数据处理系统中的生产者，包括：

生产者采用定时任务从对应的直保端系统平台读取固定条数的待办任务；

所述生产者根据待办任务中记载的业务类型和业务号，查询对应直保端系统平台的业务数据，得到待处理的业务数据；

所述生产者根据所述待处理的业务数据，生成业务消息；

所述生产者向消费者发送所述业务消息，以使所述消费者对所述业务消息中的待处理的业务数据进行处理，生成再保危险单位数据。

本发明实施例的再保危险单位数据生成方法，生产者通过采用定时任务从对应的直保端系统平台读取固定条数的待办任务，根据待办任务中记载的业务类型和业务号，查询对应直保端系统平台的业务数据，得到待处理的业务数据，并根据待处理的业务数据，生成业务消息，将业务消息发送给消费者，以使消费者对业务消息中的待处理的业务数据进行处理，生成再保危险单位数据。一方面，当新增系统平台时，只需增加对应的生产者并写入对应的待办任务即可，提高了可扩展性；另一方面，利用统一的消费者生成再保危险单位数据，对消费者的修改不依赖于各个系统平台，提高了可维护性。

为达上述目的，本发明第三方面实施例提出了另一种再保危险单位数据生成方法，应用于第一方面实施例所述的数据处理系统中的消费者，包括：

消费者接收生产者发送的业务消息，其中，所述业务消息包含待处理的业务数据；

所述消费者查询处理日志，以确定所述处理日志中是否存在所述待处理的业务数据；

若所述处理日志中不存在所述待处理的业务数据，所述消费者对所述待处理的业务数据进行业务处理，得到再保危险单位数据，并在数据库中进行存储；

所述消费者将所述待处理的业务数据添加到所述处理日志中。

本发明实施例的再保危险单位数据生成方法，消费者通过接收生产者发送的包含待处理的业务数据的业务请求，查询处理日志确定处理日志中是否存在待处理的业务数据，并在处理日志中不存在待处理的业务数据时，对待处理的业务数据进行业务处理得到再保危险单位数据并在数据库中进行存储，将待处理的业务数据添加到处理日志中。通过在对业务数据进行处理之前先查看处理日志中是否已存在待处理的业务数据，并在未存在时才对待处理的业务数据进行处理，能够避免重复处理待处理的业务数据，节约处理资源，提高处理效率。

为达上述目的，本发明第四方面实施例提出了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如第二方面实施例所述的再保危险单位数据生成方法。

为达上述目的，本发明第五方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第二方面实施例所述的再保危险单位数据生成方法。

为达上述目的，本发明第六方面实施例提出了另一种计算机设备，存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如第三方面实施例所述的再保危险单位数据生成方法。

为达上述目的，本发明第七方面实施例提出了一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第三方面实施例所述的再保危险单位数据生成方法。

本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本发明实施例一所提供的数据处理系统的结构示意图；

图2为本发明实施例一所提供的再保危险单位数据生成方法的流程示意图；

图3为本发明实施例二所提供的再保危险单位数据生成方法的流程示意图；

图4为本发明实施例三所提供的再保危险单位数据生成方法的流程示意图；

图5为本发明一具体实施例的数据处理系统的架构示意图；

图6为本发明一实施例提出的一种计算机设备的结构示意图；以及

图7为本发明一实施例提出的另一种计算机设备的结构示意图。

具体实施方式

下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

下面参考附图描述本发明实施例的数据处理系统和再保危险单位数据生成方法。

图1为本发明实施例一所提供的数据处理系统的结构示意图。

如图1所示，该数据处理系统10包括：与各个直保端系统平台对应的多个生产者110，以及通过消息中间件120与多个生产者110通信的消费者130。其中，

生产者110设置于对应直保端系统平台的服务器上，预先写入了通用的各服务模板类，以及在配置文件中预先写入了实现类，用于在运行时，读取实现类并采用反射技术获取类实例，以及获取通用的各服务模板类中实现类涉及的方法，得到所需服务类，以采用服务类对从对应直保端系统平台获取的待办任务和业务数据进行处理，生成并发送业务消息。

消费者130设置于再保端系统平台的服务器上，采用线程池为接收到的各业务消息分配对应的线程，采用多线程方式对业务消息进行业务处理。

具体地，生产者110采用反射技术，根据从配置文件中读取的实现类和通用的各服务模板类，动态创建待办任务服务类和业务服务类，其中，待办任务服务类用于对待办任务进行处理，业务服务类用于对业务数据进行处理。

本实施例中，针对直保端中的每一个系统平台设置一个对应的生产者110，各个系统平台仅作为再保业务的数据来源方，写入待办任务，而不参与相关再保业务的处理过程。

直保端各个系统平台具有保存并管理待办任务、对待办任务进行归档、承保批改理赔业务数据的功能。当直保端各个系统平台进行承保、批改、理赔操作时，将待办任务写入待办任务表，比如，团险系统数据库对应mysql数据库，则写入待办任务表到对应的mysql数据库；车险系统数据库对应oracle数据库，则写入待办任务表到对应的oracle数据库。其中，待办任务的组成可以包括：业务类型(承保、批改、理赔)、业务号(对应保单号、批单号、赔案号)、来源平台(各个平台的标识)、发送次数、任务状态(未处理、正在处理、已处理、失败)、版本号(乐观锁使用)、创建人、创建时间、修改人、修改时间。处理成功的待办任务数据被归档到待办任务归档表中，待办任务归档表中的数据的结构与待办任务的组成结构相同。直保端的承保批改理赔业务数据存储在各个系统平台中。

生产者110作为一个过程部署在各个系统平台的服务器上，一个系统平台对应一个生产者110。生产者110的功能包括读取待办任务表、乐观锁更新待办任务表处理状态、查询承保批改理赔数据、发送消息、更新待办任务表并归档待办任务、超时补偿任务等。生产者110针对每个系统平台的差异化功能，通过模板模式、配置化和反射技术实现，不需要修改生产者110的通用代码，只需要扩展实现对应接口的实现类，即可支持一个新的系统平台的生产者功能。

例如，设置一个配置文件service.properties，定义两个实现类的完整类名分别为：

reinstaskservice＝com.taikang.reinsurance.service.reinstaskserviceimpl

reinsdataservice＝com.taikang.reinsurance.service.reinsdataserviceimpl

采用反射技术获得类的实例，value的值从配置文件中获得，比如value＝com.taikang.reinsurance.service.reinsdataserviceimpl；objectbean＝class.forname(value).newinstance()；

这两个服务类继承通用的服务模板类。由此，只需要重载差异化的方法实现类，通过配置文件动态获取类实例，调用对应的方法，即可实现一个具有差异化的新直保端系统平台的生产者。

生产者110从对应的系统平台中读取待办任务，并根据待办任务查询承保批改理赔数据。生产者110中预先写入了通用的各服务模板类，并在配置文件中预先写入了实现类，当生产者110需要对不同系统平台的待办任务和业务数据进行处理时，可以从配置文件中读取实现类，再结合反射技术从配置文件中读取的实现类和通用的各服务模板类，动态创建待办任务服务类和业务服务类，能够轻松实现在每个系统平台上部署对应的生产者，比如，在团险系统平台上部署团险对应的生产者，在车险系统平台上部署车险对应的生产者。进而，采用创建的待办任务服务类和业务服务类对从系统平台获取的待办任务和业务数据进行处理，生成并发送业务消息。

生产者110发送的业务消息经消息中间件120到达再保端系统平台的服务器上的消费者130，由消费者130对业务消息进行处理以生成再保危险单位数据。消费者130采用线程池为接收到的各业务消息分配对应的线程，每个线程处理一个业务消息，生成对应的再保危险单位数据，消费者130可以将生成的再保危险单位数据统一存储在再保端的数据库集群中。

本实施例的数据处理系统，通过为直保端各个系统平台设置对应的生产者以及通过消息中间件与多个生产者进行通信的消费者，在生产者中预先写入通用的各服务模板类，并在配置文件中预先写入实现类，在运行时，读取实现类并采用反射技术获取类实例，并获取通用的各服务模板类中实现类涉及的方法得到所需服务类，采用服务类对从对应的系统平台获取的待办任务和业务数据进行处理，生成并发送业务消息，再保端的消费者对接收到的各业务消息采用多线程方式进行业务处理。通过在生产者中写入通用的各服务模板类，并在配置文件中预先写入实现类，通过读取实现类和类实例即可得到所需的服务类，能够提高直保端中新增系统平台扩展再保业务的便捷性，提高了可扩展性；消费者统一处理生成不同系统平台的再保危险单位数据，对消费者的修改不依赖于各个系统平台，降低了维护成本，提高了可维护性，解决了现有技术中存在的维护成本高、扩展性差的技术问题。

为了实现上述实施例，本发明还提出一种再保危险单位数据生成方法。

图2为本发明实施例一所提供的再保危险单位数据生成方法的流程示意图，该方法应用于上述实施例所述的数据处理系统10中的生产者110。

如图2所示，该再保危险单位数据生成方法包括以下步骤：

步骤201，生产者采用定时任务从对应的直保端系统平台读取固定条数的待办任务。

其中，生产者从直保端系统平台读取待办任务的时间间隔可读取的待办任务的条数可以预先设定，本发明对时间间隔和条数的具体取值不作限制。

本实施例中，生产者可以启动一个定时任务线程，按照预设的时间间隔(比如30秒)，根据待办任务表中待办任务的创建时间的先后顺序，从待办任务表中一次读取固定条数(比如1000条)的待办任务。其中，一次读取待办任务的条数可以设置在配置文件中，生产者运行时从配置文件中获取条数取值。

步骤202，生产者根据待办任务中记载的业务类型和业务号，查询对应直保端系统平台的业务数据，得到待处理的业务数据。

生产者读取了待办任务之后，对待办任务进行分析，从中获取待办任务中记载的业务类型和业务号，并根据业务类型和业务号查询对应直保端系统平台的业务数据。比如，业务类型是投保类型，则查询生成保单危险单位需要的投保业务数据；业务类型是批改类型，则查询生成批单危险单位需要的批改业务数据；业务类型是理赔类型，则查询生成理赔未决危险单位、理赔已决危险单位需要的理赔业务数据。

步骤203，生产者根据待处理的业务数据，生成业务消息。

本实施例中，生产者获取了业务数据之后，可以根据待处理的业务数据生成业务消息。比如，生产者可以将获取的待处理的业务数据组装成数据传输对象(datatransferobject，dto)，将业务数据转化为业务消息。

步骤204，生产者向消费者发送业务消息，以使消费者对业务消息中的待处理的业务数据进行处理，生成再保危险单位数据。

生产者将生成的业务消息发送给消费者，以使消费者对业务消息中的待处理业务数据进行处理生成再保危险单位数据。

本实施例的再保危险单位数据生成方法，生产者通过采用定时任务从对应的直保端系统平台读取固定条数的待办任务，根据待办任务中记载的业务类型和业务号，查询对应直保端系统平台的业务数据，得到待处理的业务数据，并根据待处理的业务数据，生成业务消息，将业务消息发送给消费者，以使消费者对业务消息中的待处理的业务数据进行处理，生成再保危险单位数据。一方面，当新增系统平台时，只需增加对应的生产者并写入对应的待办任务即可，提高了可扩展性；另一方面，利用统一的消费者生成再保危险单位数据，对消费者的修改不依赖于各个系统平台，提高了可维护性。

图3为本发明实施例二所提供的再保危险单位数据生成方法的流程示意图。

如图3所示，该再保危险单位数据生成方法可以包括以下步骤：

步骤301，生产者采用定时任务从对应的直保端系统平台读取固定条数的待办任务。

需要说明的是，本实施例中对步骤301的描述可以参见前述实施例中对步骤201的描述，此处不再赘述。

步骤302，生产者修改对应直保端系统平台中的待办任务表，修改后的待办任务表中正在处理的待办任务的版本号相对修改前存在差异，以标记正在处理的待办任务。

本实施例中，生产者从对应的直保端系统平台读取出待办任务之后，可以对待办任务表进行修改，以使修改后的待办任务表有别于修改前的待办任务表。

具体地，生产者可以采用版本号加1的乐观锁机制，将读取的若干条待办任务的状态更新为正在处理，如果更新失败则退出当前待办任务的处理，继续处理下一条待办任务。

步骤303，生产者根据待办任务中记载的业务类型和业务号，查询对应直保端系统平台的业务数据，得到待处理的业务数据。

步骤304，生产者根据待处理的业务数据，生成业务消息。

需要说明的是，本实施例中对步骤303-步骤304的描述可以参见前述实施例中对步骤202-步骤203的描述，此处不再赘述。

步骤305，生产者向消费者发送业务消息，以使消费者对业务消息中的待处理的业务数据进行处理，生成再保危险单位数据。

本实施例中，生产者获得业务消息之后，即可向消费者发送业务消息。

可选地，在本发明实施例一种可能的实现方式中，生产者向消费者发送业务消息之后，还可以针对消费者已完成的待办任务，修改对应直保端系统平台中的待办任务表，以使修改后的待办任务表中，已完成处理的待办任务标记为已完成状态。同时，生产者将标记为已完成状态的待办任务归档至对应直保端系统平台的待办任务归档表中。本实施例中，生产者可以提供一个供消费者调用的归档待办任务接口，以在消费者处理完成待办任务时，更新待办任务表中待办任务的状态为已完成状态，并将其归档至待办任务归档表。

可选地，在本发明实施例一种可能的实现方式中，生产者向消费者发送业务消息之后，还可以对业务消息的发送结果进行监测，若业务消息发送失败，则生产者重新向消费者发送业务消息。如果重新发送业务消息的次数达到阈值次数(比如6次)，或者，业务消息发送成功，但发送成功后消费者的处理时长大于阈值时长(比如30分钟)，则确定存在异常，其中，存在异常可能是业务消息丢失，或者处理过程异常。当确定存在异常时，生产者重置待办任务的状态为未处理状态，以使定时任务线程能够再次读取待办任务。

本实施例的再保危险单位数据生成方法，通过在生产者采用定时任务从对应的直保端系统平台读取固定条数的待办任务之后，修改对应直保端系统平台中的待办任务表，使修改后的待办任务表中正在处理的待办任务的版本号相对修改前存在差异，以标记正在处理的待办任务，能够有效辨识待办任务表中正在处理的待办任务，避免待办任务被重复读取。通过获取待处理的业务数据，并根据待处理的业务数据，生成业务消息，将业务消息发送给消费者，以使消费者对业务消息中的待处理的业务数据进行处理，生成再保危险单位数据，能够提高系统的可扩展性和可维护性。

为了实现上述实施例，本发明还提出另一种再保危险单位数据生成方法。

图4为本发明实施例三所提供的再保危险单位数据生成方法的流程示意图，该方法应用于前述实施例所述的数据处理系统10的消费者130。

如图4所示，该再保危险单位数据生成方法包括以下步骤：

步骤401，消费者接收生产者发送的业务消息，其中，业务消息包含待处理的业务数据。

本实施例中，生产者生成业务消息之后，将业务消息发送给消费者。消费者接收生产者发送的业务消息。消费者可以对接收到的业务消息进行分析，从中提取出待处理的业务数据。

步骤402，消费者查询处理日志，以确定处理日志中是否存在待处理的业务数据。

消费者对业务消息中包含的待处理的业务数据进行处理之前，可以先查询处理日志，以确定处理日志中是否已存在待处理的业务数据。当处理日志中已经存在待处理的业务数据时，则认为该待处理的业务数据已被处理过，放弃此次对待处理的业务数据的处理。

本实施例中，消费者可以根据待处理的业务数据的业务类型和业务号来判断处理日志中是否存在对应的业务数据，并在存在时放弃此次处理，在未存在时才处理待处理的业务数据。

步骤403，若处理日志中不存在待处理的业务数据，消费者对待处理的业务数据进行业务处理，得到再保危险单位数据，并在数据库中进行存储。

当消费者通过查询处理日志确定处理日志中不存在待处理的业务数据时，则消费者对待处理的业务数据进行业务处理，得到与待处理的业务数据的业务类型匹配的再保危险单位数据，并将再保危险单位数据存储在再保端的数据库中。

可选地，在本发明实施例一种可能的实现方式中，消费者对待处理的业务数据进行处理得到再保危险单位数据之后，消费者还可以根据业务消息中携带的接口地址，调用发送业务消息的生产者的接口，以使生产者修改对应直保端系统平台中的待办任务表，修改后的待办任务表中，已完成处理的待办任务标记为已完成状态，并将标记为已完成状态的待办任务归档至对应直保端系统平台中的待办任务归档表。当生产者完成对标记为已完成状态的待办任务归档时，消费者将待办任务归档至消费日志。

可选地，在本发明实施例一种可能的实现方式中，如果消费者对待处理的业务数据进行业务处理失败，消费者还可以记录错误信息到错误日志中，以便于后期维护时查看。

步骤404，消费者将待处理的业务数据添加到处理日志中。

对于处理成功的待处理的业务数据，消费者可以将待处理的业务数据添加至处理日志中。

作为一种示例，可以为添加至处理日志中的待处理的业务数据设置对应的失效时间(比如2小时)，失效时间可以预先写入配置文件中，当需要时从配置文件中读取。当添加至处理日志中的待处理的业务数据存储在处理日志中的时长达到失效时间时，清除待处理的业务数据，或者达到失效时间的待处理的业务数据仍保留在处理日志中，但消费者在后续处理新的待处理的业务数据之前，不再查询处理日志中存储的已经达到失效时间的待处理的业务数据。

本实施例的再保危险单位数据生成方法，消费者通过接收生产者发送的包含待处理的业务数据的业务请求，查询处理日志确定处理日志中是否存在待处理的业务数据，并在处理日志中不存在待处理的业务数据时，对待处理的业务数据进行业务处理得到再保危险单位数据并在数据库中进行存储，将待处理的业务数据添加到处理日志中。通过在对业务数据进行处理之前先查看处理日志中是否已存在待处理的业务数据，并在未存在时才对待处理的业务数据进行处理，能够避免重复处理待处理的业务数据，节约处理资源，提高处理效率。

图5为本发明一具体实施例的数据处理系统的架构示意图，该数据处理系统通过执行上述的再保危险单位数据生成方法，来达到直保端系统平台对应的生产者的快速扩展，以及消费者统一生成再保危险单位数据的目的。图5所示的数据处理系统仅以包括一个直保端系统平台以及对应的一个生产者、一个消费者作为示例，但基于前述实施例的描述应当理解，数据处理系统可以包括多个直保端系统平台，且每个直保端系统平台对应一个生产者，多个生产者对应同一个消费者。

如图5所示，直保端系统平台包括待办任务表、保批赔数据和待办任务归档表，待办任务表中记录待办任务，待办任务归档表中记录已完成处理的待办任务。生产者运行时，从对应的直保端系统平台读取待办任务表，从中读取待办任务，并采用乐观锁机制更新待办任务表的处理状态，并根据待办任务查询保批赔数据，生成业务消息并经kafka消息中间件将业务消息发送给消费者。消费者接收业务消息并对业务消息进行幂等校验，以确定处理日志中是否存在待处理的业务数据，并在未存在时对待处理的业务数据进行业务处理生成保批赔危险单位数据，并将危险单位数据记录在消费日志中，同时将对应的待处理的业务数据记录在处理日志中。消费者还采用定时任务归档消费日志和待办任务表，以使生产者更新直保端系统平台的待办任务归档表。

需要说明的是，上述示例中数据处理系统中的生产者和消费者的具体工作过程可以参见前述实施例对再保危险单位数据生成方法的描述，此处不再赘述。

本实施例的数据处理系统具有较好的可扩展性和可维护性，一方面，当新增系统平台时，只需增加对应的生产者并写入对应的待办任务即可，提高了可扩展性；另一方面，利用统一的消费者生成再保危险单位数据，对消费者的修改不依赖于各个系统平台，提高了可维护性。

为了实现上述实施例，本发明还提出一种计算机设备。

图6为本发明一实施例提出的一种计算机设备的结构示意图。如图6所示，该计算机设备60包括：存储器601、处理器602及存储在存储器601上并可在处理器602上运行的计算机程序603，处理器602执行所述程序时，实现如前述实施例所述的再保危险单位数据生成方法，该方法应用于数据处理系统中的生产者。

为了实现上述实施例，本发明还提出一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如前述实施例所述的再保危险单位数据生成方法，该方法应用于数据处理系统中的生产者。

为了实现上述实施例，本发明还提出另一种计算机设备。

图7为本发明一实施例提出的另一种计算机设备的结构示意图。如图7所示，该计算机设备70包括：存储器701、处理器702及存储在存储器701上并可在处理器702上运行的计算机程序703，处理器702执行所述程序时，实现如前述实施例所述的再保危险单位数据生成方法，该方法应用于数据处理系统中的消费者。

为了实现上述实施例，本发明还提出另一种非临时性计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如前述实施例所述的再保危险单位数据生成方法，该方法应用于数据处理系统中的消费者。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(ram)，只读存储器(rom)，可擦除可编辑只读存储器(eprom或闪速存储器)，光纤装置，以及便携式光盘只读存储器(cdrom)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。