CN110765167B - 保单数据的处理方法、装置及设备 - Google Patents

Abstract

本申请提供的保单数据的处理方法、装置及设备，采用多生产者‑单消费者模型实现，多生产者线程并行接收保单处理请求，并将保单处理请求中的保单数据写入到同一个缓存队列中，单消费者线程对该缓存队列中的数据依次进行客户‑业务员之间的服务关系的分配处理。由于只有一个消费者线程，可以对缓存队列中的保单数据进行重复性判断，从而避免了对相同数据进行重复分配处理，提高了数据库数据的准确性。

Description

保单数据的处理方法、装置及设备

技术领域

本发明实施例涉及保险技术领域，尤其涉及一种保单数据的处理方法、装置及设备。

背景技术

保险领域中，在保单续保、失效、满期等场景中，如果发现保单对应的业务员离职，需要为保单分配新的业务员。

通常，为保单分配新的业务员时，由保单上传人员将保单数据上传至服务器，由服务器为该保单分配业务员。实际应用中，保单上传人员为了提高上传效率，可能会选择批量上传，即每次上传多个保单数据。进一步的，保单上传人员有时会出现人为性的对批量保单进行重复上传。例如，保单上传人员批量上传N个保单数据后，在服务器返回分配结果之前，保单上传人员可能由于长时间未等到服务器返回结果而认为该次上传失败，因此，又对这N个保单数据进行重复上传。

对于服务器而言，每次批量上传对应一个数据库事务，多个事务之间的数据具有不可见性。当保单上传人员对批量保单进行重复上传时，服务器会对这些保单进行重复的业务员分配处理，因此可能会导致业务员重复分配问题，从而影响数据的准确性。

发明内容

本本申请提供一种保单数据的处理方法、装置及设备，用以解决对重复的保单数据进行重复处理的问题，提高数据的准确性。

第一方面，本申请提供一种保单数据的处理方法，应用于服务器，所述服务器包括第一消费者线程和多个生产者线程，所述方法包括：

每个所述生产者线程分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息；

每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列；

所述第一消费者线程依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系。

一种可能的实现方式中，所述建立所述保单对应的客户与所述保单对应的业务员之间的服务关系，包括：

根据所述客户的信息，判断第一数据库中是否存在所述客户对应的服务关系，所述第一数据库用于存储不同客户与不同业务员之间的服务关系；

若所述第一数据库中不存在所述客户对应的服务关系，则建立所述客户与所述业务员之间的服务关系，并将所述服务关系添加到所述第一数据库中。

一种可能的实现方式中，所述根据所述客户的信息，判断所述第一数据库中是否存在所述客户对应的服务关系之前，还包括：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

一种可能的实现方式中，所述服务器还包括多个第二消费者线程，所述每个所述生产者线程分别接收保单处理请求之后，还包括：

每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，所述第二缓存队列的数量与所述第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应；

每个所述第二消费者线程依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系。

一种可能的实现方式中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据；所述每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，包括：

每个所述生产者线程针对所述保单处理请求中的每个所述保单数据，确定所述保单数据对应的业务类型；

根据所述保单数据对应的业务类型，将所述保单数据放入所述业务类型对应的第二缓存队列中。

一种可能的实现方式中，所述建立所述保单与所述保单对应的业务员之间的对应关系，包括：

判断第二数据库中是否存在所述保单与所述业务员之间的对应关系，所述第二数据库用于存储不同保单与不同业务员之间的对应关系；

若所述第二数据库中不存在所述保单与所述业务员之间的对应关系，则建立所述保单与所述业务员之间的对应关系，并将所述对应关系添加至所述第二数据库中。

一种可能的实现方式中，所述判断第二数据库中是否存在所述保单与所述业务员之间的对应关系之前，还包括：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

第二方面，本申请提供一种保单数据的处理装置，包括：第一处理模块和多个接收模块；

每个所述接收模块，用于分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息；

每个所述接收模块，还用于将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列；

所述第一处理模块，用于依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系。

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

根据所述客户的信息，判断第一数据库中是否存在所述客户对应的服务关系，所述第一数据库用于存储不同客户与不同业务员之间的服务关系；

若所述第一数据库中不存在所述客户对应的服务关系，则建立所述客户与所述业务员之间的服务关系，并将所述服务关系添加到所述第一数据库中。

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

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

一种可能的实现方式中，所述装置还包括多个第二处理模块；

每个所述接收模块，还用于将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，所述第二缓存队列的数量与所述第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应；

每个所述第二处理模块，用于依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系。

一种可能的实现方式中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据；每个所述接收模块具体用于：

针对所述保单处理请求中的每个所述保单数据，确定所述保单数据对应的业务类型；

根据所述保单数据对应的业务类型，将所述保单数据放入所述业务类型对应的第二缓存队列中。

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

判断第二数据库中是否存在所述保单与所述业务员之间的对应关系，所述第二数据库用于存储不同保单与不同业务员之间的对应关系；

若所述第二数据库中不存在所述保单与所述业务员之间的对应关系，则建立所述保单与所述业务员之间的对应关系，并将所述对应关系添加至所述第二数据库中。

一种可能的实现方式中，每个所述第二处理模块还具体用于：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

第三方面，本申请提供一种服务器，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行如第一方面任一项所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

本申请提供的保单数据的处理方法、装置及设备，采用多生产者-单消费者模型实现，多生产者线程并行接收保单处理请求，并将保单处理请求中的保单数据写入到同一个缓存队列中，单消费者线程对该缓存队列中的数据依次进行分配处理。由于只有一个消费者线程，可以对缓存队列中的保单数据进行重复性判断，从而避免了对相同数据进行重复分配处理，提高了数据库数据的准确性。

附图说明

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

图1为本申请提供的一种保单数据的处理过程的示意图；

图2为本申请一实施例提供的保单数据的处理方法的流程示意图；

图3为本申请一实施例提供的保单数据的处理过程示意图；

图4为本申请一实施例提供的建立客户与业务员之间的服务关系的流程示意图；

图5为本申请一实施例提供的保单数据的处理方法的流程示意图；

图6为本申请一实施例提供的保单数据的处理过程示意图；

图7为本申请一实施例提供的保单数据的处理装置的结构示意图；

图8为本申请一实施例提供的保单数据的处理装置的结构示意图；

图9为本申请一实施例提供的服务器的硬件结构示意图。

具体实施方式

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

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

本申请的业务场景为保单分配场景。其中，保单分配是指：在保单续保、失效、满期等场景中，如果发现保单对应的业务员离职，则为保单分配新的业务员。

实际应用中，由保单上传人员将保单数据上传至服务器，由服务器为该保单分配业务员。保单上传人员为了提高上传效率，可能会选择批量上传，即每次上传多个保单数据。

图1为本申请提供的一种保单数据的处理过程的示意图。参见图1，保单上传人员的每次批量上传对应一个保单处理请求，即，保单处理请求中包括一个或多个保单数据。服务器采用多线程并行处理机制，针对每个保单处理请求采用一个独立的线程进行处理。示例性的，针对保单处理请求1，由线程1进行分配处理，即线程1对保单处理请求1中的各保单数据进行分配处理。针对保单处理请求2，由线程2进行分配处理，即线程2对保单处理请求2中的各保单数据进行分配处理。针对保单处理请求3，由线程3进行分配处理，即线程3对保单处理请求3中的各保单数据进行分配处理。可以理解的，上述3个线程之间为并行处理关系，3个线程将各自处理得到的处理结果写入到数据库中。

然而，实际应用中，保单上传人员有时会出现人为性的对批量保单进行重复上传。例如，保单上传人员批量上传N个保单数据(假设对应图1中的保单处理请求1)后，在服务器返回分配结果之前，保单上传人员可能由于长时间未等到服务器返回结果而认为该次上传失败，因此，又对这N个保单数据进行重复上传(假设对应图1中的保单处理请求2)。这样，导致服务器收到的保单处理请求1和保单处理请求2中的保单数据其实是相同的。但是，由于不同的保单处理请求是由不同的线程处理的，不同线程之间所处理的保单数据具有不可见性，因此，服务器无法判断出不同保单处理请求中的数据是否为重复数据，使得对重复的数据进行了重复的分配处理，导致了业务员重复分配的问题，并导致数据库中存在大量的重复数据。

为了解决上述问题，本申请提供一种保单数据的处理方法，采用多生产者-单消费者模型实现。具体的，多生产者线程并行接收保单处理请求，并将保单处理请求中的保单数据写入到同一个缓存队列中，单消费者线程对该缓存队列中的数据依次进行分配处理。由于只有一个消费者线程，可以对缓存队列中的保单数据进行重复性判断，从而避免了对相同数据进行重复分配处理，提高了数据库数据的准确性。

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

图2为本申请一实施例提供的保单数据的处理方法的流程示意图。本实施例的方法由服务器执行，服务器可以为任意具有数据处理能力的电子设备。本实施例中，服务器采用多生产者-单消费者模型，即服务器包括多个生产者线程和1个第一消费者线程，每个生产者线程用于接收保单处理请求，并将保单处理请求中的各保单数据写入第一缓存队列中，该第一消费者线程依次对第一缓存队列中的保单数据进行处理。需要说明的是，本实施例中所述服务器包括1个第一消费者线程是指：多个生产者线程生产的数据由1个第一消费者线程处理，而并不是限定服务器中只能包括1个第一消费者线程。可以理解的，当服务器为多核处理器时，每个处理器中均可以采用上述的多生产者-单消费者模型。

如图2所示，本实施例的方法，包括：

S201：每个所述生产者线程分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息。

其中，每个保单处理请求中可以包括一个或者多个保单数据。本申请中的一个保单数据是指一个保单对应的数据。每个保单数据中可以包括该保单对应的客户的信息和保单对应的业务员的信息。其中，客户的信息可以为能够唯一标识该客户的任意信息，例如：身份证号、ID、姓名等。业务员的信息可以为能够唯一标识该业务员的任意信息，例如：身份证号、ID、姓名、工号等。

一种可能的场景中，保单数据中所包括的业务员的信息可以是该保单对应的原业务员的信息。该场景中，服务器需要根据保单数据，对业务员的状态进行校验，并在该业务员的状态为非正常服务状态时，为该保单分配新的业务员，并对客户与新的业务员之间的服务关系进行记录。

另一种可能的场景中，保单数据中所包括的业务员的信息可以是为该保单分配的新的业务员的信息。该场景中，在将保单数据上传至服务器之前，需要人为确定保单对应的业务员的状态为非正常服务状态，并人为为该保单分配新的业务员。服务器接收到保单数据后，需要对客户与新的业务员之间的服务关系进行记录。

其中，“业务员的状态为非正常服务状态”是指由于某些原因，业务员无法正常为保单对应的客户提供服务。例如，业务员可能离职、请长假、调岗等。

可以理解的，由于保单上传人员在上传保单数据时，可能存在人为性的重复上传问题，因此，本实施例中，不同生产者线程所接收到的保单处理请求中的保单数据可能是重复的。例如：生产者线程1接收到的保单处理请求1中的保单数据与生产者线程2接收到的保单处理请求2中的保单数据是相同的。其中，这里的相同，可以是全部相同还可以是部分相同，本实施例对此不作具体限定。

需要说明的是，本实施例对于生产者线程的数量不作具体限定。多个生产者线程之间彼此独立运行。

S202：每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列。

S203：所述第一消费者线程依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系。

本申请实施例中，为保单数据设置一个第一缓存队列，第一缓存队列用于缓存未被处理的保单数据。每个生产者线程将各自接收到的保单处理请求中的各保单数据放入该第一缓存队列中。第一消费者线程从第一缓存队列中依次取出一个保单数据进行第一处理。

下面结合图3进行举例说明。图3为本申请一实施例提供的保单数据的处理过程示意图。如图3所示，假设服务器包括3个生产者线程和1个第一消费者线程。生产者线程1接收到保单处理请求1，其中包括3个保单的数据，分别为保单1、保单2和保单3，生产者线程1将这3个保单数据写入到第一缓存队列中。生产者线程2接收到保单处理请求2，保单处理请求2是由保单上传人员人为性的对保单处理请求1中的数据重复发送的，即，保单处理请求2中的保单数据与保单处理请求1中的保单数据相同，分别为保单1、保单2和保单3，生产者线程2将这3个保单数据写入到第一缓存队列中。生产者线程3接收到保单处理请求3，其中包括3个保单的数据，分别为保单4、保单5和保单6，生产者线程3将这3个保单数据写入到第一缓存队列中。3个生产者线程将接收到的保单数据写入到第一缓存队列后，第一缓存队列的状态如图3所示。其中，包括了重复的保单数据。

与此同时，第一消费者线程按照第一缓存队列中的各保单数据的存储顺序，依次读取保单数据进行第一处理。其中，第一处理包括：建立保单对应的客户与保单对应的业务员之间的服务关系。下面结合两种可能的实施方式对第一处理进行描述。

一种可能的实施方式中，针对前述的场景：保单数据中的业务员的信息是该保单对应的原业务员的信息。该场景下，需要由服务器对原业务员的状态进行判断，并在原业务员的状态为非正常服务状态时，为保单分配新的业务员，进而建立客户与新分配的业务员之间的服务关系。下面结合图4对本实施方式进行介绍。

图4为本申请一实施例提供的建立客户与业务员之间的服务关系的流程示意图。可以理解的，第一消费者线程针对第一缓存队列中的每个保单数据，均可以采用本实施例的处理方法，本实施例是以其中一个保单数据的处理过程为例进行描述的。如图4所示，本实施例的方法，包括：

S2031：根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态。

可选的，参见图3，服务器中设置有业务员属性数据库，业务员属性数据库中记录了不同业务员的状态属性。其中，业务员的状态包括正常服务状态和非正常服务状态。可以根据业务员的信息，在业务员属性数据库中进行查询，确定出业务员的状态。

S2032：若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

可以理解的，当业务员的状态为非正常服务状态时，说明该业务员无法继续提供服务，因此，需要为保单分配新的业务员。可选的，参见图3，服务其中设置有客户属性数据库，可以根据客户的信息，查询客户属性数据库，获取客户的属性信息，并根据客户的属性信息为客户分配新的业务员。可选的，还可以根据客户的信息和不同业务员之间的关系信息，为客户分配新的业务员。示例性的，假设业务员A离职后，可以将业务员A对应的保单分配给业务员A的上级业务员B。这样，根据业务员之间的血缘关系为保单分配新的业务员，可以保证业务员分配质量，保证新分配的业务员能够为客户提供优质服务。

若业务员的状态为正常服务状态，则说明原业务员依然可以继续服务，无需为该保单分配新的业务员，继续执行S2033。

S2033：根据所述客户的信息，判断第一数据库中是否存在所述客户对应的服务关系，所述第一数据库用于存储不同客户与不同业务员之间的服务关系。

S2034：若所述第一数据库中不存在所述客户对应的服务关系，则建立所述客户与所述业务员之间的服务关系，并将所述服务关系添加到所述第一数据库中。

该实施方式中，为了避免重复分配的问题，第一消费者线程针对从第一缓存队列中获取的每个保单数据进行服务关系分配时，首先根据客户的信息，判断第一数据库中是否存在该客户的对应的服务关系。其中，第一数据库用于存储不同客户与不同业务员之间的服务关系，参见图3，第一数据库可以对应图3中的“客户-业务员服务关系数据库”。

若第一数据库中存在该客户对应的服务关系，则说明当前保单数据可能为之前某个保单数据的重复数据，在处理之前的保单数据时，已经为该客户建立了服务关系，因此，无需对当前保单数据进行处理。若第一数据库中不存在该客户对应的服务关系，则说明当前保单数据对应的客户还未建立服务关系，因此，第一消费者线程针对当前保单数据，建立客户与业务员之间的服务关系，并将服务关系添加至第一数据库中。

另一种可能的实施方式中，针对前述的场景：保单数据中的业务员的信息是为该保单新分配的业务员的信息。示例性的，当保单续保、失效或者满期时，若发现该保单对应的业务员处于非正常服务状态，则由人工或者其他设备为保单分配新的业务员。该场景下，将保单数据和新的业务员的信息上传至服务器，由服务器建立保单对应的客户和该新的业务员之间的服务关系。该实施方式中，服务器无需执行图4中的S2031和S2032，只需要执行S2033和S2034即可，具体实现过程与上述实施方式类似，此处不再赘述。

本实施例中，在客户和业务员之间的服务关系建立时，采用多生产者—单消费者模型，该模型可以把生产者线程和消费者线程的实现解耦开来。示例性的，可以采用JAVA中的LinkedBlockingQueue阻塞队列开发一套生产者和单消费者模型，以解决不同事务之间的数据不可见的情况。在上传保单数据的时候，将客户的信息和业务员的信息作为一个Block(块数据模块)发送到阻塞队列中进行排队。然后消费者线程从阻塞队列中逐个获取到Block进行处理。根据目前已有的数据分析，在批量数据上传中，客户-业务员服务关系数据库中存储已建立过的服务关系，并且，客户-业务员服务关系数据库会作为后续保单分配的校验基准。因此，通常只有少量的保单数据需要经过上述的服务关系建立过程，所以，只采用单消费者线程也可以在要求的时间内完成保单数据的处理，并且不会存在队列大量的阻塞行为。

消费者线程读取到一个Block数据后，解析出客户的信息、业务员的信息，然后判断客户-业务员服务关系数据库中是否已存在该客户对应的服务关系，如果存在，不做处理，继续读取下一个Block数据。如果不存在该客户对应的服务关系，则在客户-业务员服务关系数据库中添加该客户与该业务员之间的服务关系，并为该业务员设置临时服务标识。待处理完成后，轮询下一个Block。进一步的，针对标识为“临时服务”的业务员，如果该业务员在预设时长的服务期内为该客户服务成功(例如，为该客户下了新的保单)，则将该业务员的临时服务标识取消；相反，如果该业务员在预设时长的服务期内未对该客户服务成功，则后续的保单数据处理中，接触该业务员与该客户之间的服务关系，并为该客户分配新的业务员。

本申请实施例提供的保单数据的处理方法，采用多生产者-单消费者模型实现，多生产者线程并行接收保单处理请求，并将保单处理请求中的保单数据写入到同一个缓存队列中，单消费者线程对该缓存队列中的数据依次进行分配处理。由于只有一个消费者线程，可以对缓存队列中的保单数据进行重复性判断，从而避免了对相同数据进行重复分配处理，提高了数据库数据的准确性。

图5为本申请一实施例提供的保单数据的处理方法的流程示意图。在上述实施例的基础上，服务器还可以包括多个第二消费者线程，每个第二消费者线程对保单数据进行第二处理，其中，第二处理包括：建立保单与业务员之间的对应关系。

如图5所示，本实施例的方法，包括：

S501：每个所述生产者线程分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息。

本实施例中，S501的具体实施方式与上述实施例中的S201类似，此处不再赘述。

S502：每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列，并且，每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中。

本实施例中，与图2所示实施例不同的是，每个生产者线程将接收到的保单数据放入第一缓存队列之后，还将接收到的保单数据放入多个第二缓存队列中。其中，所述第二缓存队列的数量与所述第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应。

一种可能的实施方式中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据。具体的，每个所述生产者线程针对所述保单处理请求中的每个所述保单数据，确定所述保单数据对应的业务类型；根据所述保单数据对应的业务类型，将所述保单数据放入所述业务类型对应的第二缓存队列中。示例性的，可以根据保单数据中的机构标识，确定保单数据对应的业务类型。

S503：所述第一消费者线程依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系。

本实施例中，S503的具体实施方式与图2中的S202类似，此处不再赘述。

S504：每个所述第二消费者线程依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系。

本实施例中，对保单数据进行第二处理(建立保单与业务员之间的对应关系)时，采用的是多生产者-多消费者模型。多个第二消费者线程对各自对应的第二缓存队列中的保单数据进行并行地处理，一方面保证了保单数据处理的效率，提高了保单数据处理的实时性，另一方面隔离了不同业务类型之间的保单数据处理过程，保证了保单数据处理的安全性。

下面结合图6进行举例说明。图6为本申请一实施例提供的保单数据的处理过程示意图。如图6所示，假设服务器包括3个生产者线程和3个第二消费者线程。生产者线程1接收到保单处理请求1，其中包括3个保单的数据，分别为保单1、保单2和保单3，生产者线程1根据各保单对应的业务类型，将各保单分别放入各自业务类型对应的第二缓存队列中。例如：假设保单1和保单3对应业务类型1，保单2对应业务类型2，则将保单1和保单3放入业务类型1对应的第二缓存队列中，将保单2放入业务类型2对应的第二缓存队列中。类似的，针对保单处理请求2和保单处理请求3中的各保单数据，均按照业务类型放入对应的第二缓存队列中，最终得到的3个业务类型对应的第二缓存队列的状态如图6所示。

与此同时，每个第二消费者线程对应一个第二缓存队列，每个第二消费者线程按照各自对应的第二缓存队列中的各保单数据的存储顺序，依次读取保单数据进行第二处理。

一种可能的实施方式中，当保单数据中的业务员的信息是为该保单新分配的业务员的信息时，第二处理过程可以具体包括：判断第二数据库中是否存在所述保单与所述业务员之间的对应关系，所述第二数据库用于存储不同保单与不同业务员之间的对应关系；若所述第二数据库中不存在所述保单与所述业务员之间的对应关系，则建立所述保单与所述业务员之间的对应关系，并将所述对应关系添加至所述第二数据库中。第二数据库可以对应图6中的“保单-业务员对应关系数据库”。

可选的，当保单数据中的业务员的信息是该保单对应的原业务员的信息时，第二处理过程还可以包括：根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。可以理解的，为保单分配新的业务员的过程与图4所示的实施例类似，此处不再赘述。

进一步的，本实施例中的第二数据库中的数据可以被推送给其他业务设备，以供其他业务场景使用。

由图6可知，由于各保单数据是按照业务类型进行缓存的，当存在重复的保单数据时，重复的保单数据会出现在同一个缓存队列中。例如图6中，重复的保单1和保单3出现在业务类型1对应的第二缓存队列中，重复的保单2出现在业务类型2对应的第二缓存队列中。每个第二消费者线程在进行第二处理时，可以先对保单数据进行重复性判断，若是重复的保单数据，则无需处理，若是非重复的保单数据，再进行上述的第二处理过程，也避免了对相同数据进行重复处理，保证了数据库中的数据的准确性。

图7为本申请一实施例提供的保单数据的处理装置的结构示意图。如图7所示，本实施例提供的保单数据的处理装置700，包括：接收模块701和第一处理模块702。其中，接收模块701的数量为多个，每个接收模块701实现的功能对应上述方法实施例中的每个生产者线程实现的功能。第一处理模块702的数量为1个，第一处理模块702实现的功能对应上述方法实施例中的第一消费者线程实现的功能。

每个所述接收模块701，用于分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息；

每个所述接收模块701，还用于将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列；

所述第一处理模块702，用于依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系。

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

根据所述客户的信息，判断第一数据库中是否存在所述客户对应的服务关系，所述第一数据库用于存储不同客户与不同业务员之间的服务关系；

若所述第一数据库中不存在所述客户对应的服务关系，则建立所述客户与所述业务员之间的服务关系，并将所述服务关系添加到所述第一数据库中。

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

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

本实施例的保单数据的处理装置，可用于执行上述的图2至图4所示的方法实施例，其实现原理和技术效果类似，此处不再赘述。

图8为本申请一实施例提供的保单数据的处理装置的结构示意图。如图8所示，本实施例的保单数据的处理装置700，还可以包括第二处理模块703。其中，第二处理模块703的数量为多个，每个第二处理模块703实现的功能对应上述方法实施例中的每个第二消费者线程实现的功能。

一种可能的实现方式中，每个所述接收模块701，还用于将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，所述第二缓存队列的数量与所述第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应；

每个所述第二处理模块703，用于依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系。

一种可能的实现方式中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据；每个所述接收模块701具体用于：

针对所述保单处理请求中的每个所述保单数据，确定所述保单数据对应的业务类型；

根据所述保单数据对应的业务类型，将所述保单数据放入所述业务类型对应的第二缓存队列中。

一种可能的实现方式中，每个所述第二处理模块703具体用于：

判断第二数据库中是否存在所述保单与所述业务员之间的对应关系，所述第二数据库用于存储不同保单与不同业务员之间的对应关系；

若所述第二数据库中不存在所述保单与所述业务员之间的对应关系，则建立所述保单与所述业务员之间的对应关系，并将所述对应关系添加至所述第二数据库中。

一种可能的实现方式中，每个所述第二处理模块703还具体用于：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

本实施例的保单数据的处理装置，可用于执行上述任一方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

图9为本申请一实施例提供的服务器的硬件结构示意图。如图9所示，本实施例的服务器900，包括：处理器901以及存储器902；其中，存储器902，用于存储计算机程序；处理器901，用于执行存储器存储的计算机程序，以实现上述实施例中的保单数据的处理方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器902既可以是独立的，也可以跟处理器901集成在一起。

当所述存储器902是独立于处理器901之外的器件时，所述服务器900还可以包括：总线903，用于连接所述存储器902和处理器901。

本实施例提供的服务器，可用于执行上述任一方法实施例中的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例中的技术方案。

本申请实施例还提供一种芯片，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行上述任一方法实施例中的技术方案。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

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

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

Claims (9)

1.一种保单数据的处理方法，其特征在于，应用于服务器，所述服务器包括第一消费者线程和多个生产者线程，所述方法包括：

每个所述生产者线程分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息；

每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列；

所述第一消费者线程依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系；

所述服务器还包括多个第二消费者线程，所述每个所述生产者线程分别接收保单处理请求之后，还包括：

每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，所述第二缓存队列的数量与所述第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应；

每个所述第二消费者线程依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系；

其中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据。

2.根据权利要求1所述的方法，其特征在于，所述建立所述保单对应的客户与所述保单对应的业务员之间的服务关系，包括：

根据所述客户的信息，判断第一数据库中是否存在所述客户对应的服务关系，所述第一数据库用于存储不同客户与不同业务员之间的服务关系；

若所述第一数据库中不存在所述客户对应的服务关系，则建立所述客户与所述业务员之间的服务关系，并将所述服务关系添加到所述第一数据库中。

3.根据权利要求2所述的方法，其特征在于，所述根据所述客户的信息，判断所述第一数据库中是否存在所述客户对应的服务关系之前，还包括：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

4.根据权利要求1所述的方法，其特征在于，所述每个所述生产者线程将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，包括：

每个所述生产者线程针对所述保单处理请求中的每个所述保单数据，确定所述保单数据对应的业务类型；

根据所述保单数据对应的业务类型，将所述保单数据放入所述业务类型对应的第二缓存队列中。

5.根据权利要求1所述的方法，其特征在于，所述建立所述保单与所述保单对应的业务员之间的对应关系，包括：

判断第二数据库中是否存在所述保单与所述业务员之间的对应关系，所述第二数据库用于存储不同保单与不同业务员之间的对应关系；

若所述第二数据库中不存在所述保单与所述业务员之间的对应关系，则建立所述保单与所述业务员之间的对应关系，并将所述对应关系添加至所述第二数据库中。

6.根据权利要求5所述的方法，其特征在于，所述判断第二数据库中是否存在所述保单与所述业务员之间的对应关系之前，还包括：

根据所述业务员的信息，判断所述业务员的状态是否为正常服务状态；

若所述业务员的状态为非正常服务状态，则根据所述客户的信息，和/或，不同业务员之间的关系信息，分配一个新的业务员作为所述保单对应的业务员。

7.一种保单数据的处理装置，其特征在于，包括：第一处理模块和多个接收模块；

每个所述接收模块，用于分别接收保单处理请求，每个所述保单处理请求中包括至少一个保单的保单数据，每个所述保单数据包括所述保单对应的客户的信息和所述保单对应的业务员的信息；

每个所述接收模块，还用于将各自接收到的保单处理请求中的各所述保单数据放入第一缓存队列；

所述第一处理模块，用于依次对所述第一缓存队列中的各所述保单数据进行第一处理，所述第一处理包括：建立所述保单对应的客户与所述保单对应的业务员之间的服务关系；

所述处理装置还包括第二处理模块，所述第二处理模块的数量为多个；

每个所述接收模块，还用于将各自接收到的保单处理请求中的各所述保单数据放入多个第二缓存队列中，所述第二缓存队列的数量与第二消费者线程的数量相同，所述第二消费者线程与所述第二缓存队列一一对应；

每个所述第二处理模块，用于依次对各自对应的所述第二缓存队列中的各所述保单数据进行第二处理，所述第二处理包括：建立所述保单与所述保单对应的业务员之间的对应关系；

其中，不同的第二缓存队列用于存储不同的业务类型对应的保单数据。

8.一种服务器，其特征在于，包括：存储器、处理器以及计算机程序，所述计算机程序存储在所述存储器中，所述处理器运行所述计算机程序执行如权利要求1至6任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的方法。

Images