保险业务数据处理方法、装置、电子设备及存储介质

技术领域

本申请涉及保险数据处理技术领域，具体涉及一种保险业务数据处理方法及装置、电子设备以及计算机可读存储介质。

背景技术

随着经济与社会的发展，人们的保险意识越来越强，越来越多的用户开始通过网络购买保险服务。

目前，网络上的保险服务出单系统都是采用微服务架构，账户充值、消费、够买保单等业务服务都是独立部署，通过调用相应接口来进行业务服务，各接口都是采用远程过程调用，业务服务间数据很难保证正确性和一致性。因此，如何保证用户购买保险服务过程中的数据一致性是本领域亟需解决的技术问题。

发明内容

本申请的目的是提供一种保险业务数据处理方法及装置、一种电子设备以及一种计算机可读存储介质。

本申请第一方面提供一种保险业务数据处理方法，包括：

接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号；

响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；

基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。

在一种可能的实现方式中，所述基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，包括：

调用订单服务生成订单，向所述用户端发送表示出单中的第一订单信息，同时保存订单服务的本次操作记录为Try阶段；

调用账户服务判断所述账户金额是否大于等于所述保费金额并根据所述全局事务标识进行幂等校验；

若所述账户金额大于等于所述保费金额且幂等校验成功，则从所述账户金额中冻结所述保费金额，同时保存账户服务的本次操作记录为Try阶段；

若所述账户金额小于所述保费金额或幂等校验失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存账户服务的本次操作记录为Cancel阶段；

若订单服务和账户服务的本次操作记录均为Try阶段，则进行Confirm阶段的操作。

在一种可能的实现方式中，所述若订单服务和账户服务的本次操作记录均为Try阶段，则进行Confirm阶段的操作，包括：

调用订单服务进行保司出单的操作；

若保司出单成功，则调用账户服务从所述账户金额中扣除所述保费金额，同时保存订单服务和账户服务的本次操作记录为Confirm阶段；

若保司出单失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存订单服务和账户服务的本次操作记录为Cancel阶段。

在一种可能的实现方式中，所述方法还包括：

若保司出单成功，则向所述用户端发送表示出单成功的第二订单信息。

在一种可能的实现方式中，所述方法还包括：

若保司出单失败，则向所述用户端发送表示出单失败的第三订单信息。

在一种可能的实现方式中，所述方法还包括：

当所述用户账户号对应的账户金额小于所述业务号对应的保费金额时，暂停保险业务办理并向所述用户端发送账户金额不足的提示信息。

本申请第二方面提供一种保险业务数据处理装置，包括：

接收模块，用于接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号；

响应模块，用于响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；

处理模块，用于基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。

在一种可能的实现方式中，所述处理模块，具体用于：

调用订单服务生成订单，向所述用户端发送表示出单中的第一订单信息，同时保存订单服务的本次操作记录为Try阶段；

调用账户服务判断所述账户金额是否大于等于所述保费金额并根据所述全局事务标识进行幂等校验；

若所述账户金额大于等于所述保费金额且幂等校验成功，则从所述账户金额中冻结所述保费金额，同时保存账户服务的本次操作记录为Try阶段；

若所述账户金额小于所述保费金额或幂等校验失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存账户服务的本次操作记录为Cancel阶段；

若订单服务和账户服务的本次操作记录均为Try阶段，则进行Confirm阶段的操作。

在一种可能的实现方式中，所述处理模块，具体用于：

调用订单服务进行保司出单的操作；

若保司出单成功，则调用账户服务从所述账户金额中扣除所述保费金额，同时保存订单服务和账户服务的本次操作记录为Confirm阶段；

若保司出单失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存订单服务和账户服务的本次操作记录为Cancel阶段。

在一种可能的实现方式中，所述处理模块，还用于：

若保司出单成功，则向所述用户端发送表示出单成功的第二订单信息。

在一种可能的实现方式中，所述处理模块，还用于：

若保司出单失败，则向所述用户端发送表示出单失败的第三订单信息。

在一种可能的实现方式中，所述响应模块，还用于：

当所述用户账户号对应的账户金额小于所述业务号对应的保费金额时，暂停保险业务办理并向所述用户端发送账户金额不足的提示信息。

本申请第三方面提供一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行以实现本申请第一方面所述的保险业务数据处理方法。

本申请第四方面提供一种计算机可读存储介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现本申请第一方面所述的保险业务数据处理方法。

本申请提供的保险业务数据处理方法、装置、电子设备及存储介质，接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号；响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。相较于现有技术，本申请基于TCC分布式事务处理方法办理保险业务，可以保证保险服务过程中数据的一致性，避免出错给用户带来不必要的麻烦，从而提升用户体验。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请所提供的一种保险业务数据处理方法的流程示意图；

图2示出了本申请所提供的一种TCC分布式事务处理过程的示意图；

图3示出了本申请所提供的一种保险业务数据处理装置的结构示意图；

图4示出了本申请所提供的一种电子设备的结构示意图；

图5示出了本申请所提供的一种计算机可读存储介质的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施方式。虽然附图中显示了本公开的示例性实施方式，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

另外，术语“第一”和“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例提供一种保险业务数据处理方法及装置、一种电子设备以及计算机可读存储介质，下面结合附图进行说明。

图1示出了本申请实施例提供的一种保险业务数据处理方法的流程示意图，如图1所示，具体包括以下步骤：

S101、接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号。

本实施例的执行主体可以为保险业务办理平台(以下简称“平台”)，用户通过用户端可以在平台上购买各个保险公司的各种类型保单，例如用户在保险业务办理平台上开设账户，账户内储值有一定数量的金额，用户通过用户端购买某保司保单时扣除相应的账户金额。

本实施例中，用户需要购买保单时，通过用户端向平台发送保险业务办理请求，该请求中携带有用户账户号和目标保险业务的业务号。平台通过账户号可以找到对应的账户并且获得账户金额，通过业务号可以找到对应的目标保险业务并获得目标保险业务的保费金额。

S102、响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；

本实施例中，平台首先判断用户账户号对应的账户金额是否大于等于业务号对应的保费金额，也就是说，平台首先判断用户的账户金额是否足够支付目标保险业务，如果够则会进一步调用订单服务和账户服务来完成目标保险业务办理。

本实施例中，当所述用户账户号对应的账户金额小于所述业务号对应的保费金额时，平台可以暂停保险业务办理并向所述用户端发送账户金额不足的提示信息，以提示用户储值后再继续购买。

由于现有技术中，在调用订单服务和账户服务办理保险业务时，常常会出现两个服务数据不一致的情况，在出错后进行补救则会给用户带来不必要的麻烦，因此本实施例中采用TCC协议进行分布式事务处理。订单服务和账户服务作为分布式事务，首先平台会调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识，后续订单服务和账户服务会根据全局事务标识进行TCC协议的各个阶段。

其中，TCC中的“T”具体是指Try方法、TCC中的第一个“C”具体是指Confirm方法、TCC中的第二个“C”具体是指Cancel方法，该3个方法均由业务编码实现。其中Try操作可以作为一阶段，负责资源的检查和预留，Confirm操作可以作为二阶段提交操作，执行真正的业务，Cancel是预留资源的取消。

S103、基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。

下面对本实施例中TCC分布式事务处理过程进行具体介绍。

本实施例中，步骤S103具体包括：

调用订单服务生成订单，向所述用户端发送表示出单中的第一订单信息，同时保存订单服务的本次操作记录为Try阶段；

调用账户服务判断所述账户金额是否大于等于所述保费金额并根据所述全局事务标识进行幂等校验；

若所述账户金额大于等于所述保费金额且幂等校验成功，则从所述账户金额中冻结所述保费金额，同时保存账户服务的本次操作记录为Try阶段；

若所述账户金额小于所述保费金额或幂等校验失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存账户服务的本次操作记录为Cancel阶段；

若订单服务和账户服务的本次操作记录均为Try阶段，则进行Confirm阶段的操作。

具体的，若操作记录均为Try阶段，则说明订单服务和账户服务的第一阶段Try操作都执行成功，可以进行第二阶段Confirm操作，将账户服务本单冻结的金额减掉，表示为消费成功。当第一阶段有一方出现异常，事务管理器会同时调用回滚操作，将账户冻结金额加回到余额中，过程中需判断是否已经执行过回滚操作、第一阶段是否执行成功校验。

第二阶段Confirm操作包括：

调用订单服务进行保司出单的操作；保司出单可以通过订单服务调用相应的保司出单服务。

若保司出单成功，则调用账户服务从所述账户金额中扣除所述保费金额，向所述用户端发送表示出单成功的第二订单信息，同时保存订单服务和账户服务的本次操作记录为Confirm阶段；修改订单状态，向用户端发送表示出单成功的第二订单信息；

若保司出单失败，则根据所述全局事务标识触发全局事务回滚操作，向所述用户端发送表示出单失败的第三订单信息，同时保存订单服务和账户服务的本次操作记录为Cancel阶段；修改订单状态，向所述用户端发送表示出单失败的第三订单信息。

本实施例中，保司出单服务组装报文并调用保险公司出单，结果有两种(出单成功、出单失败)，账户服务所有的扣款动作都是围绕保司的出单结果确定，如成功则执行第二阶段Confirm操作，如失败则执行第三阶段Cancel操作。

为了便于理解上述过程，本申请提供了如图2所示的TCC分布式事务处理过程的示意图。图2中的一阶段校验和二阶段校验是指校验相应阶段是否执行成功。

本实施例中，通过上述TCC分布式事务处理过程可以保证保险业务办理过程中数据的正确性和一致性。

本实施例提供的保险业务数据处理方法，接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号；响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。相较于现有技术，本申请基于TCC分布式事务处理方法办理保险业务，可以保证保险服务过程中数据的一致性，避免出错给用户带来不必要的麻烦，从而提升用户体验。

在上述的实施例中，提供了一种保险业务数据处理方法，与之相对应的，本申请还提供一种保险业务数据处理装置。本申请实施例提供的保险业务数据处理装置可以实施上述保险业务数据处理方法，该保险业务数据处理装置可以通过软件、硬件或软硬结合的方式来实现。例如，该保险业务数据处理装置可以包括集成的或分开的功能模块或单元来执行上述各方法中的对应步骤。请参考图3，其示出了本申请实施例提供的一种保险业务数据处理装置的示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。

如图3所示，所述保险业务数据处理装置10，可以包括：

接收模块101，用于接收用户端发送的保险业务办理请求，所述保险业务办理请求中携带有用户账户号和目标保险业务的业务号；

响应模块102，用于响应于所述保险业务办理请求，当所述用户账户号对应的账户金额大于等于所述业务号对应的保费金额时，调用事务管理器生成所述保险业务办理请求对应的唯一全局事务标识；

处理模块103，用于基于所述全局事务标识对办理所述目标保险业务的订单服务和账户服务进行TCC分布式事务处理，直至完成所述目标保险业务办理。

在一种可能的实现方式中，所述处理模块103，具体用于：

调用订单服务生成订单，向所述用户端发送表示出单中的第一订单信息，同时保存订单服务的本次操作记录为Try阶段；

调用账户服务判断所述账户金额是否大于等于所述保费金额并根据所述全局事务标识进行幂等校验；

若所述账户金额大于等于所述保费金额且幂等校验成功，则从所述账户金额中冻结所述保费金额，同时保存账户服务的本次操作记录为Try阶段；

若所述账户金额小于所述保费金额或幂等校验失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存账户服务的本次操作记录为Cancel阶段；

若订单服务和账户服务的本次操作记录均为Try阶段，则进行Confirm阶段的操作。

在一种可能的实现方式中，所述处理模块103，具体用于：

调用订单服务进行保司出单的操作；

若保司出单成功，则调用账户服务从所述账户金额中扣除所述保费金额，同时保存订单服务和账户服务的本次操作记录为Confirm阶段；

若保司出单失败，则根据所述全局事务标识触发全局事务回滚操作，同时保存订单服务和账户服务的本次操作记录为Cancel阶段。

在一种可能的实现方式中，所述处理模块103，还用于：

若保司出单成功，则向所述用户端发送表示出单成功的第二订单信息。

在一种可能的实现方式中，所述处理模块103，还用于：

若保司出单失败，则向所述用户端发送表示出单失败的第三订单信息。

在一种可能的实现方式中，所述响应模块102，还用于：

当所述用户账户号对应的账户金额小于所述业务号对应的保费金额时，暂停保险业务办理并向所述用户端发送账户金额不足的提示信息。

本申请实施例提供的保险业务数据处理装置与本申请实施例提供的保险业务数据处理方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的保险业务数据处理方法对应的电子设备，所述电子设备可以是手机、笔记本电脑、平板电脑、台式机电脑等，以执行上述保险业务数据处理方法。

请参考图4，其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图4所示，所述电子设备20包括：处理器200，存储器201，总线202和通信接口203，所述处理器200、通信接口203和存储器201通过总线202连接；所述存储器201中存储有可在所述处理器200上运行的计算机程序，所述处理器200运行所述计算机程序时执行本申请前述任一实施方式所提供的保险业务数据处理方法。

其中，存储器201可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口203(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线202可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器201用于存储程序，所述处理器200在接收到执行指令后，执行所述程序，前述本申请实施例任一实施方式揭示的所述保险业务数据处理方法可以应用于处理器200中，或者由处理器200实现。

处理器200可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器200中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器200可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器201，处理器200读取存储器201中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例提供的保险业务数据处理方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的保险业务数据处理方法对应的计算机可读存储介质，请参考图5，其示出的计算机可读存储介质为光盘30，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的保险业务数据处理方法。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的保险业务数据处理方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

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