CN111309749A - 一种保单信息的处理方法及装置、设备、介质 - Google Patents

Abstract

本申请实施例提供了一种保单信息的处理方法及装置、设备、介质，所述方法包括：在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端。通过本申请实施例，实现了在保单回溯时采用增量存储的轨迹信息进行回溯，提高了保单回溯时的查询效率，且通过在版本更新时增量存储轨迹信息，避免了保存保单的全量信息，减少了数据库压力及对数据库资源的消耗。

Description

一种保单信息的处理方法及装置、设备、介质

技术领域

本申请涉及数据处理领域，特别是涉及一种保单信息的处理方法及装置、设备、介质。

背景技术

保险单(简称保单)是保险人与投保人签订保险合同的书面证明。保单信息管理过程中，当发生保单变更交易，可通过保单管理系统针对保单变更交易进行记录。

在现有技术中，通常是采用保存保单全量信息的方式，以针对变更交易进行记录。而一张保单一年发生的交易次数可能几十或上百次，一张长险保单全周期的交易次数可能是上万次甚至更多。保单管理系统管理着上亿张保单，其数据量可想而知，因而需要定期将记录信息归档才能减少数据库的压力，对数据库资源造成很大的消耗，且当用户查询变更交易记录时，将直接调用保存的保单全量信息，以展示给用户。

发明内容

鉴于上述问题，提出了以便提供克服上述问题或者至少部分地解决上述问题的一种保单信息的处理方法及装置、设备、介质，包括：

一种保单信息的处理方法，所述方法包括：

在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端；

其中，所述根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息的步骤包括：

将所述轨迹信息集合划分为一个或多个轨迹信息组；

分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息。

可选地，所述将所述轨迹信息集合划分为一个或多个轨迹信息组的步骤包括：

获取预设的分组处理数；

采用所述分组处理数，对所述轨迹信息集合进行分组，得到一个或多个轨迹信息组。

可选地，所述采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息的步骤包括：

获取预置保单信息；

采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成整合轨迹信息；

结合所述整合轨迹信息和所述预置保单信息，生成针对所述保单回溯请求的目标保单信息。

可选地，所述确定与所述保单回溯请求关联的版本标识集合的步骤包括：

在所述保单回溯请求中，确定第一版本标识；

确定与所述第一版本标识关联的一个或多个第二版本标识，并将所述第一版本标识和所述一个或多个第二版本标识组织成与所述保单回溯请求关联的版本标识集合。

可选地，所述方法还包括：

在版本更新时，增量存储轨迹信息；其中，所述轨迹信息存储于非关系型数据库中。

可选地，所述在版本更新时，增量存储轨迹信息的步骤包括：

在版本更新时，获取所述版本更新前的保单信息与所述版本更新后的保单信息之间的保单增量信息；

将所述保单增量信息作为轨迹信息，进行存储。

可选地，在所述在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合的步骤之前，所述方法还包括：

接收客户端发送的版本信息查询请求；

采用所述版本信息查询请求，确定一个或多个候选版本信息，并返回至客户端；其中，所述客户端用于在接收到所述一个或多个候选版本信息后，发送保单回溯请求。

一种保单信息的处理装置，包括：

保单回溯请求接收模块，用于在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

轨迹信息集合确定模块，用于确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

目标保单信息生成模块，用于根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端；

其中，所述目标保单信息生成模块包括：

轨迹信息集合划分子模块，用于将所述轨迹信息集合划分为一个或多个轨迹信息组；

组内轨迹信息生成子模块，用于分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

目标保单信息生成子模块，用于采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息。

一种电子设备，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的保单信息的处理方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上所述的保单信息的处理方法的步骤。

本申请实施例具有以下优点：

在本申请实施例中，通过在接收到客户端发送的保单回溯请求时，确定与保单回溯请求关联的版本标识集合，然后确定版本标识集合对应的轨迹信息集合，每个版本标识对应一轨迹信息，轨迹信息为在版本更新时增量存储的信息，根据轨迹信息集合，生成针对保单回溯请求的目标保单信息，并返回至所述客户端，实现了在保单回溯时采用增量存储的轨迹信息进行回溯，提高了保单回溯时的查询效率，且通过在版本更新时增量存储轨迹信息，避免了保存保单的全量信息，减少了数据库压力及对数据库资源的消耗。

附图说明

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

图1是本申请一实施例提供的一种保单信息的处理方法的步骤流程图；

图2是本申请一实施例提供的一种保单轨迹信息保存流程的示意图；

图3是本申请一实施例提供的另一种保单信息的处理方法的步骤流程图；

图4是本申请一实施例提供的另一种保单信息的处理方法的步骤流程图；

图5是本申请一实施例提供的一种保单轨迹信息查询流程的示意图；

图6是本申请一实施例提供的一种保单信息回溯流程的示意图；

图7是本申请一实施例提供的一种保单信息的处理装置的结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参照图1，示出了本申请一实施例提供的一种保单信息的处理方法的步骤流程图，具体可以包括如下步骤：

步骤101，在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

其中，保单回溯请求可以为由业务人员或用户选择待回溯的目标版本保单信息的请求。版本标识可以包括保单的版本号，版本标识集合可以为针对保单目标版本进行回溯所关联的保单版本号集合。

在具体实现中，在接收到客户端发送的保单回溯请求时，可以从保单回溯请求中获取待回溯的目标版本标识，然后可以根据该目标版本标识确定保单回溯所关联的保单版本标识集合。

步骤102，确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

作为一示例，轨迹信息可以为针对当前保单的版本更新时增量存储的信息，每次版本更新可以对应一轨迹信息，即每个版本号可以对应一轨迹信息。

在确定版本标识集合后，可以采用版本标识集合中的版本标识，查询每个版本标识对应的轨迹信息，然后可以将各版本标识对应的各轨迹信息组织成轨迹信息集合。

步骤103，根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端。

其中，目标保单信息可以为保单回溯请求中待回溯目标版本的保单信息。

在确定轨迹信息集合后，可以采用轨迹信息集合中的轨迹信息，进行回溯处理，进而可以生成针对保单回溯请求的目标保单信息，然后可以将目标保单信息返回至客户端向用户进行展示。

在本申请一实施例中，该方法还可以包括：

在版本更新时，增量存储轨迹信息。其中，轨迹信息可以存储于非关系型数据库。

作为一示例，版本更新可以为保单信息变更交易后，针对当前保单的版本更新。

在具体实现中，可以在保单信息发生变更交易后，针对当前保单的版本进行更新，并将轨迹信息增量存储于非关系型数据库。通过在版本更新时增量存储轨迹信息，采用非关系型数据库仅针对更新数据进行保存，避免了保存保单全量信息导致的保单轨迹数据量大，减少了数据库压力。

在本申请一实施例中，所述在版本更新时，增量存储轨迹信息的步骤可以包括如下子步骤：

在版本更新时，获取所述版本更新前的保单信息与所述版本更新后的保单信息之间的保单增量信息；将所述保单增量信息作为轨迹信息，进行存储。

作为一示例，保单增量信息可以为版本更新时，版本更新前的保单信息与版本更新后的保单信息之间发生变更的保单信息的历史值。例如，版本更新时，保单中改变字段的历史值。

在保单信息变更交易后，针对当前保单进行版本更新时，可以将发生变更的保单信息的历史值作为轨迹信息，存储至非关系型数据库的当前保单轨迹表中。

例如，轨迹信息中保存的可以为保单信息变更之前的信息，如轨迹信息[a2,d1,e1,v2]，v2为轨迹信息对应的版本号，该轨迹信息可以为由版本号2的保单发生保单信息变更交易，变更为版本号3的保单时所保存的轨迹信息。其中，a2、d1、e1分别为版本号2的保单中a、d、e三个字段的值，通过保单信息变更交易变更为版本号3的保单的过程中，需要将保单表中a、d、e三个字段值修改为a3、d2、e2，在修改保单数据后，可以将a2、d1、e1(改变字段的历史值)保存到轨迹表中。

在一示例中，在保单信息变更交易后，可以针对当前保单修改保单数据以更新保单信息，并针对当前保单更新版本号，进而可以生成更新后版本的保单信息，该更新后版本的保单信息可以为全量保单信息。

例如，发生保单信息变更交易后，更新后版本的保单表里可以保存变更后的全量保单数据，保单轨迹表中则可以保存中发生变化的字段进行变更前的值。

在又一示例中，当发生保单信息变更交易时，用户在变更完保单信息后需要取消变更，可以针对用户的取消变更请求恢复为当前保单的保单信息，并针对取消变更生成对应的轨迹信息。

在实际应用中，如图2所示，当保单信息发生变更后，可以在更新保单信息时修改保单数据，并更新修改日期及在当前版本号的基础上增加1作为更新后的版本号。同时可以将当前版本号、交易日期、交易代码，以及变更前的保单信息字段值域增量保存到当前保单的轨迹表中。

具体的，可以采用非关系型数据库来保存保单轨迹信息，例如可以选择使用Mongodb数据库，该Mongodb数据库为key-value的存储方式，key为字段名，value为字段值域。在Mongodb数据库中，所有轨迹信息可以保存在一条记录文档里，即每一个版本的轨迹信息可以通过内嵌文档的形式保存在同一个文档中。在现有技术中，保单管理系统保存保单变更轨迹信息，通常是采用关系型数据库保存保单的全量信息，而Mongodb数据库中的文档存储的是json格式的数据，其与mysql数据的存储结构(关系型数据库)最大的区别就是可以保存内嵌文档。

在本申请实施例中，通过在接收到客户端发送的保单回溯请求时，确定与保单回溯请求关联的版本标识集合，然后确定版本标识集合对应的轨迹信息集合，每个版本标识对应一轨迹信息，轨迹信息为在版本更新时增量存储的信息，根据轨迹信息集合，生成针对保单回溯请求的目标保单信息，并返回至所述客户端，通过将所有的轨迹信息以内嵌文档的形式保存在同一个文档中，提高了轨迹信息的查询效率，且通过在版本更新时增量存储轨迹信息，避免了保存保单的全量信息，减少了数据库压力及对数据库资源的消耗。

参照图3，示出了本申请一实施例提供的另一种保单信息的处理方法的步骤流程图，具体可以包括如下步骤：

步骤301，在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

在本申请一实施例中，步骤301可以包括如下子步骤：

子步骤11，在所述保单回溯请求中，确定第一版本标识；

在接收到保单回溯请求后，可以从保单回溯请求中获取待回溯目标版本标识，确定为第一版本标识。

子步骤12，确定与所述第一版本标识关联的一个或多个第二版本标识，并将所述第一版本标识和所述一个或多个第二版本标识组织成与所述保单回溯请求关联的版本标识集合。

在确定第一版本标识后，可以查询与第一版本标识关联的一个或多个第二版本标识，并将第一版本标识和一个或多个第二版本标识组织成与保单回溯请求关联的版本标识集合。

在实际应用中，由业务人员或用户选择需要追溯的保单目标版本后，可以确定目标版本号，然后可以将版本号大于或等于目标版本号的一个或多个版本号组织成版本标识集合。

步骤302，确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

在确定版本标识集合后，可以采用版本标识集合中的版本标识，查询每个版本标识对应的轨迹信息，然后可以将各版本标识对应的各轨迹信息组织成轨迹信息集合。

步骤303，将所述轨迹信息集合划分为一个或多个轨迹信息组；

其中，每个轨迹信息组可以包括待回溯处理的一个或多个轨迹信息。

在确定轨迹信息集合后，可以采用轨迹信息集合中的轨迹信息，进行回溯处理，进而可以生成针对保单回溯请求的目标保单信息，然后可以将目标保单信息返回至客户端向用户进行展示。

在本申请一实施例中，步骤303可以包括如下子步骤：

获取预设的分组处理数；采用所述分组处理数，对所述轨迹信息集合进行分组，得到一个或多个轨迹信息组。

在确定轨迹信息集合后，可以通过获取系统预设的分组处理数，对轨迹信息集合进行分组，进而可以将轨迹信息集合划分得到一个或多个轨迹信息组。通过对待处理数据进行分组，使得每一分组之间可以同时处理，提升了数据的处理效率，达到了以多线程的方式并行追溯轨迹的效果。

在实际应用中，可以根据待回溯的目标版本号，查询出关联的一个或多个版本号及其对应的轨迹信息，然后可以将查询得到的一个或多个轨迹信息组织成轨迹信息集合，通过获取系统预设的并行处理数作为分组处理数，可以对轨迹信息集合进行分组处理，得到一个或多个轨迹信息组。例如，轨迹信息集合中有m个轨迹信息，根据系统预设的并行处理数n，可以将m个轨迹信息分成n组，即可以将轨迹信息集合划分为n个轨迹信息组。

步骤304，分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

其中，组内轨迹信息可以为针对一轨迹信息组，采用该轨迹信息组中的轨迹信息进行赋值处理后得到的轨迹信息。

在得到一个或多个轨迹信息组后，可以针对各轨迹信息组进行赋值处理，分别生成一个或多个轨迹信息组对应的组内轨迹信息。

在实际应用中，可以针对各轨迹信息组采取相同的赋值处理方式，具体可以采用如下方式进行赋值处理：

在轨迹信息组中可以按版本号进行排序，然后可以由低版本开始，依次向上比较版本号对应的轨迹信息，进而可以将低版本轨迹信息中的字段赋值给高版本轨迹信息中的字段。若低版本轨迹信息中的字段值域为null(无)，则跳过不赋值。即当低版本中的字段信息与高版本中的字段信息相同时，可以将低版中的字段信息赋值给高版本；当低版本中的字段信息与高版本中的字段信息不相同时，可以取两个版本的并集。

针对轨迹信息组中的全部版本赋值完成后，可以得到组内轨迹信息，组内轨迹信息中的版本号可以为当前分组中最低版本的版本号，字段可以包括当前分组全部版本的轨迹信息中的全量字段，字段值域可以为包含该字段的版本中最低版本的轨迹信息中的字段值域。

例如，一轨迹信息组中包含3条轨迹信息，其对应的版本号为1至3，该3条轨迹信息分别为:

[a1,b1,c1,v1]，[a2,d1,e1,v2]，[b2,c2,f1,v3]。

可以先将版本号为1的轨迹信息赋值给版本号为2的轨迹信息，得到赋值后的轨迹信息为[a1,b1,c1,d1,e1,v1]，再赋值给版本号为3的轨迹信息，得到赋值后的轨迹信息为[a1,b1,c1,d1,e1,f1,v1]，进而可以将[a1,b1,c1,d1,e1,f1,v1]作为得到的组内轨迹信息。

步骤305，采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端。

在本申请一实施例中，步骤305可以包括如下子步骤：

子步骤21，获取预置保单信息；

作为一示例，预置保单信息可以为当前版本的保单信息。

子步骤22，采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成整合轨迹信息；

其中，整合轨迹信息可以为采用一个或多个组内轨迹信息进行赋值处理后得到的轨迹信息。

在生成组内轨迹信息后，可以针对一个或多个组内轨迹信息进行赋值处理，进而可以得到整合轨迹信息。

在实际应用中，针对轨迹信息集合的全部分组，即一个或多个轨迹信息组均进行赋值处理后，可以得到各轨迹信息组对应的组内轨迹信息，然后将得到的一个或多个组内轨迹信息组织成一个新的分组，进而可以采取相同的赋值处理方式针对新分组进行赋值处理，得到最终的轨迹信息(整合轨迹信息)。

子步骤23，结合所述整合轨迹信息和所述预置保单信息，生成针对所述保单回溯请求的目标保单信息。

在具体实现中，可以将整合轨迹信息赋值给预置保单信息，进而可以得到针对保单回溯请求的目标保单信息。例如，可以将回溯得到的最终轨迹信息(整合轨迹信息)赋值给当前版本的保单信息，赋值完成后的保单信息即为待回溯的目标版本的保单信息。

在本申请实施例中，通过在接收到客户端发送的保单回溯请求时，确定与保单回溯请求关联的版本标识集合，然后确定版本标识集合对应的轨迹信息集合，每个版本标识对应一轨迹信息，轨迹信息为在版本更新时增量存储的信息，根据轨迹信息集合，生成针对保单回溯请求的目标保单信息，并返回至所述客户端，实现了在保单回溯时采用增量存储的轨迹信息进行回溯，提高了保单回溯时的查询效率，同时，通过多线程的方式并行追溯轨迹，增加了数据处理效率。

参照图4，示出了本申请一实施例提供的另一种保单信息的处理方法的步骤流程图，具体可以包括如下步骤：

步骤401，接收客户端发送的版本信息查询请求；

作为一示例，版本信息查询请求可以为针对待回溯保单的版本信息的查询请求，版本信息查询请求可以包括待回溯保单的保单号，针对版本信息查询请求的查询结果可以为待回溯保单的多条版本信息的记录展示。

在具体实现中，可以通过客户端发送针对待回溯保单的版本信息查询请求。

步骤402，采用所述版本信息查询请求，确定一个或多个候选版本信息，并返回至客户端；其中，所述客户端用于在接收到所述一个或多个候选版本信息后，发送保单回溯请求；

在接收到版本信息查询请求后，可以从版本信息查询请求中获取待回溯保单的保单号，进而可以根据保单号确定待回溯保单的一个或多个版本信息作为候选版本信息，并返回至客户端，以供业务人员或用户选择待回溯的目标版本信息。

在保单信息管理过程中，经常出现业务人员或客户需要查询某日期前或某交易发生前的保单信息，如图5所示，当业务人员或客户需要追溯的目标版本保单信息时，可以根据保单号、保单信息变更交易代码(非必须)、保单信息变更交易日期(非必须)查询保单轨迹信息。查询结果可以为一条或多条记录，每条记录可以展示一交易轨迹变更前后的字段值域以及对应的版本号，例如，字段名称为a，变更前字段值域为a1，变更后字段值域为a2，当前版本为v2。若记录为多条，则可以由业务人员或客户选择需要追溯的保单目标版本。

步骤403，在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

在具体实现中，在接收到客户端发送的保单回溯请求时，可以从保单回溯请求中获取待回溯的目标版本标识，然后可以根据该目标版本标识确定保单回溯所关联的保单版本标识集合。

步骤404，确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

在确定版本标识集合后，可以采用版本标识集合中的版本标识，查询每个版本标识对应的轨迹信息，然后可以将各版本标识对应的各轨迹信息组织成轨迹信息集合。

步骤405，根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端。

在确定轨迹信息集合后，可以采用轨迹信息集合中的轨迹信息，进行回溯处理，进而可以生成针对保单回溯请求的目标保单信息，然后可以将目标保单信息返回至客户端向用户进行展示。

在本申请实施例中，通过在接收到客户端发送的保单回溯请求时，确定与保单回溯请求关联的版本标识集合，然后确定版本标识集合对应的轨迹信息集合，每个版本标识对应一轨迹信息，轨迹信息为在版本更新时增量存储的信息，根据轨迹信息集合，生成针对保单回溯请求的目标保单信息，并返回至所述客户端，实现了在保单回溯时采用增量存储的轨迹信息进行回溯，提高了保单回溯时的查询效率，且通过在版本更新时增量存储轨迹信息，避免了保存保单的全量信息，减少了数据库压力及对数据库资源的消耗。

为了使本领域技术人员能够更好地理解上述步骤，通过以下例子对本申请实施例加以示例性说明，但应当理解的是，本申请实施例并不限于此。

例如，在针对保单信息回溯到目标版本时，假设版本号为1的保单信息具有十个业务字段(如保单号、保单状态、投保人邮箱等)，分别为a1,b1,c1,d1,e1,f1,g1,h1,i1,j1，在经过5次信息变更后，保单信息变为a5,b4,c4,d3,e3,f3,g2,h2,i1,j1，版本号变为6。针对5次信息变更所记录的轨迹信息分别为:

[a1,b1,c1,v1]，[a2,d1,e1,v2]，[b2,c2,f1,v3]，

[a3,b3,g1,f2,v4]，[a4,c3,d2,e2,h1,v5]。

当需要通过版本号为6的保单信息追溯版本号为1的保单信息时，如图5所示，可以根据保单号查询出版本号6的保单信息，并可以根据版本号查询对应的轨迹信息，然后可以取出版本号大于或等于回溯的目标版本(图6中入参版本)的轨迹信息。

根据系统预设的并行处理数2，可以将5条轨迹信息分为2组以并行处理，处理组1中可以包括v1、v2版本，处理组2中可以包括v3、v4、v5版本。

针对处理组1，可以将v1版本向v2版本进行赋值，在赋值完成后可以得到处理组1的组内轨迹信息为[a1,b1,c1,d1,e1,v1]。

针对处理组2，可以先将v3版本向v4版本进行赋值，得到v3版本向v4版本赋值后的轨迹信息为[a3,b2,c2,f1,g1,v3]，再将v3版本向v4版本赋值后的轨迹信息，向v5版本进行赋值，得到处理组2的组内轨迹信息为[a3,b2,c2,d2,e2,f1,g1,h1,v3]。

在两组全部赋值处理完成后，可以得到两个新版本的轨迹信息v1和v3，然后可以将新的v1版本向新的v3版本进行赋值，得到整合轨迹信息(图6中最终轨迹信息)为[a1,b1,c1,d1,e1,f1,g1,h1,v1]，该整合轨迹信息可以为采用轨迹信息集合进行赋值处理后得到的轨迹信息。

在得到整合轨迹信息后，可以将整合轨迹信息赋值给版本号为6的保单信息(图6中当前版本的保单信息)，进而可以得到保单信息回溯的目标版本号为1的保单信息，该保单信息为a1,b1,c1,d1,e1,f1,g1,h1,i1,j1。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图7，示出了本申请一实施例提供的一种保单信息的处理装置的结构示意图，具体可以包括如下模块：

保单回溯请求接收模块701，用于在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

轨迹信息集合确定模块702，用于确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

目标保单信息生成模块703，用于根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端。

在本申请一实施例中，所述目标保单信息生成模块703包括：

轨迹信息集合划分子模块，用于将所述轨迹信息集合划分为一个或多个轨迹信息组；

组内轨迹信息生成子模块，用于分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

目标保单信息生成子模块，用于采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息。

在本申请一实施例中，所述轨迹信息集合划分子模块包括：

分组处理数获取单元，用于获取预设的分组处理数；

轨迹信息集合分组单元，用于采用所述分组处理数，对所述轨迹信息集合进行分组，得到一个或多个轨迹信息组。

在本申请一实施例中，所述目标保单信息生成子模块包括：

保单信息获取单元，用于获取预置保单信息；

整合轨迹信息生成单元，用于采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成整合轨迹信息；

信息结合单元，用于结合所述整合轨迹信息和所述预置保单信息，生成针对所述保单回溯请求的目标保单信息。

在本申请一实施例中，所述保单回溯请求接收模块701包括：

第一版本标识确定子模块，用于在所述保单回溯请求中，确定第一版本标识；

第二版本标识确定子模块，用于确定与所述第一版本标识关联的一个或多个第二版本标识，并将所述第一版本标识和所述一个或多个第二版本标识组织成与所述保单回溯请求关联的版本标识集合。

在本申请一实施例中，所述装置还包括：

轨迹信息增量存储模块，用于在版本更新时，增量存储轨迹信息。

在本申请一实施例中，所述轨迹信息增量存储模块包括：

保单增量信息获取子模块，用于在版本更新时，获取所述版本更新前的保单信息与所述版本更新后的保单信息之间的保单增量信息；

轨迹信息存储子模块，用于将所述保单增量信息作为轨迹信息，进行存储。

在本申请一实施例中，所述装置还包括：

查询请求接收模块，用于接收客户端发送的版本信息查询请求；

候选版本信息确定模块，用于采用所述版本信息查询请求，确定一个或多个候选版本信息，并返回至客户端；其中，所述客户端用于在接收到所述一个或多个候选版本信息后，发送保单回溯请求。

本申请一实施例还提供了一种电子设备，可以包括处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上保单信息的处理方法的步骤。

本申请一实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如上保单信息的处理方法的步骤。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对所提供的一种保单信息的处理方法及装置、设备、介质，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种保单信息的处理方法，其特征在于，所述方法包括：

在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端；

其中，所述根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息的步骤包括：

将所述轨迹信息集合划分为一个或多个轨迹信息组；

分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息。

2.根据权利要求1所述的方法，其特征在于，所述将所述轨迹信息集合划分为一个或多个轨迹信息组的步骤包括：

获取预设的分组处理数；

采用所述分组处理数，对所述轨迹信息集合进行分组，得到一个或多个轨迹信息组。

3.根据权利要求1或2所述的方法，其特征在于，所述采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息的步骤包括：

获取预置保单信息；

采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成整合轨迹信息；

结合所述整合轨迹信息和所述预置保单信息，生成针对所述保单回溯请求的目标保单信息。

4.根据权利要求1所述的方法，其特征在于，所述确定与所述保单回溯请求关联的版本标识集合的步骤包括：

在所述保单回溯请求中，确定第一版本标识；

确定与所述第一版本标识关联的一个或多个第二版本标识，并将所述第一版本标识和所述一个或多个第二版本标识组织成与所述保单回溯请求关联的版本标识集合。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在版本更新时，增量存储轨迹信息；其中，所述轨迹信息存储于非关系型数据库中。

6.根据权利要求5所述的方法，其特征在于，所述在版本更新时，增量存储轨迹信息的步骤包括：

在版本更新时，获取所述版本更新前的保单信息与所述版本更新后的保单信息之间的保单增量信息；

将所述保单增量信息作为轨迹信息，进行存储。

7.根据权利要求1所述的方法，其特征在于，在所述在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合的步骤之前，所述方法还包括：

接收客户端发送的版本信息查询请求；

采用所述版本信息查询请求，确定一个或多个候选版本信息，并返回至客户端；其中，所述客户端用于在接收到所述一个或多个候选版本信息后，发送保单回溯请求。

8.一种保单信息的处理装置，其特征在于，包括：

保单回溯请求接收模块，用于在接收到客户端发送的保单回溯请求时，确定与所述保单回溯请求关联的版本标识集合；

轨迹信息集合确定模块，用于确定所述版本标识集合对应的轨迹信息集合；其中，每个版本标识对应一轨迹信息，所述轨迹信息为在版本更新时增量存储的信息；

目标保单信息生成模块，用于根据所述轨迹信息集合，生成针对所述保单回溯请求的目标保单信息，并返回至所述客户端；

其中，所述目标保单信息生成模块包括：

轨迹信息集合划分子模块，用于将所述轨迹信息集合划分为一个或多个轨迹信息组；

组内轨迹信息生成子模块，用于分别生成所述一个或多个轨迹信息组对应的组内轨迹信息；

目标保单信息生成子模块，用于采用所述一个或多个轨迹信息组对应的组内轨迹信息，生成针对所述保单回溯请求的目标保单信息。

9.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至7中任一项所述的保单信息的处理方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的保单信息的处理方法的步骤。

Images