CN109729060B - 保单出单请求的处理方法、装置及设备 - Google Patents

Abstract

本申请公开了一种保单出单请求的处理方法、装置及设备，涉及保险技术领域，使得服务器处理请求时可以避开集中处理的情况，可以支持高并发大批量散单出单。其中方法包括：当服务器接收到客户端发送的保单出单请求时，获取保单出单请求中携带的投保请求数据；根据投保请求数据进行校验处理；若校验成功，则将投保请求数据存入预定消息缓存队列中，预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；按照预定推送规则，将预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。本申请适用于保单出单请求的处理。

Description

保单出单请求的处理方法、装置及设备

技术领域

本申请涉及保险技术领域，尤其是涉及到一种保单出单请求的处理方法、装置及设备。

背景技术

随着互联网技术的飞速发展，互联网公司与保险行业的合作也不断深入。互联网投保越来越成为一种流行趋势，用户可以通过网络在线投保，无需用户亲自去保险公司办理业务，节省了时间，极大的方便了用户投保。互联网投保的显著特点为出单量大，并发数高。

目前用户可以通过客户端应用在线购买保单，客户端将携带有用户投保请求数据的保单出单请求发送给保险公司服务器，保险公司服务器接收到保单出单请求后立即进行处理，根据用户的投保请求数据生成保单反馈给用户客户端。

然而由于保险公司服务器的数量固定，每台服务器的请求处理能力有限，如果遇到大量散户同时进行在线投保时，会给保险公司出单系统带来巨大的压力，甚至会出现服务器宕机的情况，进而会造成用户在此宕机阶段投保失败的情况发生，从而影响了用户的使用体验。

发明内容

有鉴于此，本申请提供了一种保单出单请求的处理方法、装置及设备，主要目的在于解决目前保险公司服务器接收到保单出单请求后立即进行处理生成保单，如果遇到大量散户同时进行在线投保时，会给保险公司出单系统带来巨大的压力，甚至会出现服务器宕机的情况，进而会造成用户在此宕机阶段投保失败的情况发生的问题。

根据本申请的一个方面，提供了一种保单出单请求的处理方法，该方法包括：

当服务器接收到客户端发送的保单出单请求时，获取所述保单出单请求中携带的投保请求数据；

根据所述投保请求数据进行校验处理；

若校验成功，则将所述投保请求数据存入预定消息缓存队列中，所述预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；

按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。

根据本申请的另一方面，提供了一种保单出单请求的处理装置，该装置包括：

获取单元，用于当服务器接收到客户端发送的保单出单请求时，获取所述保单出单请求中携带的投保请求数据；

校验单元，用于根据所述投保请求数据进行校验处理；

保存单元，用于若所述校验单元校验成功，则将所述投保请求数据存入预定消息缓存队列中，所述预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；

推送单元，用于按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。

依据本申请又一个方面，提供了一种存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述保单出单请求的处理方法。

依据本申请再一个方面，提供了一种保单出单请求的处理设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述保单出单请求的处理方法。

借由上述技术方案，本申请提供的一种保单出单请求的处理方法、装置及设备，与目前保险公司服务器接收到保单出单请求后立即进行处理生成保单的方式相比，本申请采用消息缓存队列的缓冲机制，在服务器接收到客户端发送的保单出单请求时，首先根据请求中携带的投保请求数据进行简单校验处理，如果校验成功，则将该投保请求数据存入预定消息缓存队列中等待推送给服务器进行处理，这样服务器处理请求时可以避开集中处理的情况，在遇到大量散户同时进行在线投保时，也不会给保险公司出单系统带来压力，减少出现服务器宕机的情况发生，通过这种方法可以支持高并发大批量散单出单。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例提供的一种保单出单请求的处理方法的流程示意图；

图2示出了本申请实施例提供的另一种保单出单请求的处理方法的流程示意图；

图3示出了本申请实施例提供的一种保单出单请求的处理装置的结构示意图；

图4示出了本申请实施例提供的另一种保单出单请求的处理装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种保单出单请求的处理方法，采用消息缓存队列的缓冲机制，使得服务器处理请求时可以避开集中处理的情况，可以支持高并发大批量散单出单，如图1所示，该方法包括：

101、当服务器接收到客户端发送的保单出单请求时，获取保单出单请求中携带的投保请求数据。

其中，投保请求数据中可以包括：订单数据(如下单时间、保险产品的支付金额、支付使用的优惠券、支付账户、下单用户购买的保险产品信息等)，投保数据(如下单用户填写的投保人信息、被保人信息、投保额、投保年限等)等；投保人信息可以包括投保人姓名、年龄、身份证号、家庭住址、联系方式等，被保人信息也同样包括被保人姓名、年龄、身份证号等这些内容，下单用户购买的保险产品信息可以包括如保险产品名称或编号(ID)、保单险种信息、保单类型信息等。

对于本实施例的执行主体可以为基于消息缓存队列缓冲机制的保单出单请求处理装置，其可以运行在保险公司服务器上，也可以为与保险公司服务器连接的独立装置，如前端服务器等，用于监控保险公司服务器接收到的保单出单请求，具体可以对保险公司服务器接收到的客户端发送的保单出单请求进行缓冲处理，等待推送给保险公司服务器进行处理生成保单。

102、根据获取到的投保请求数据进行校验处理。

对于本实施例可以根据投保请求数据进行简单校验处理，判断保单出单请求是否符合预先设置的一些保单出单基本要求，即进行初步的过滤筛选处理。这种初步校验处理的具体实施内容可以根据实际需求预先进行配置。

例如，根据投保请求数据中订单数据，判断下单用户需要购买的保险产品在保险公司方是否存在，即保险公司方是否正在在线销售该保险产品，如果下单用户购买的保险产品在保险公司方并不存在，那么可以确定此次校验失败，如果判定保险公司方确实正在在线销售该保险产品，可以进一步判断该保险产品的库存是否充足，如果库存不够，也可以确定此次校验失败。

再例如，根据投保请求数据中订单数据，判定下单用户是在时间段1内下单成功购买的保险产品a，但是经过查询发现保险产品a只能在时间段2内才能购买成功，即保险产品a为限时抢购商品，因此可以确定该下单用户违规操作，此次校验失败；再或者检测出下单用户支付所使用的优惠券不合规，也可以判断此次校验失败。

103、若校验成功，则将投保请求数据存入预定消息缓存队列中。

其中，预定消息缓存队列中保存有保险公司服务器待处理的不同保单出单请求分别所携带的投保请求数据。

对于本实施例，在经过各个保单出单基本要求初步过滤筛选之后，若最后校验成功，可以将本次接收到的保单出单请求所携带的这些投保请求数据存入预定消息缓存队列中等待合适的时机推送给保险公司服务器进行处理以生成保单，使得保险公司服务器避开集中处理的情况。

104、按照预定推送规则，将预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。

其中，预定推送规则可以根据保险业务的实际需求预先进行设定。

例如，可以根据保险公司服务器的实际请求处理情况，避开服务器集中处理的情况，将预定消息缓存队列中每个保单出单请求对应的投保请求数据分散推送给服务器进行处理，使得服务器不会同时处理大量的请求数据，对于这些请求数据服务器可以分不同时间段逐步消化处理，以便减轻服务器的负载压力。

需要说明的是，对于本实施例提供的保单出单请求的处理方法，除了可以应用在服务器对保单出单请求的处理场景中，还可以应用于其他请求处理场景中，如实现应用功能的应用请求、商品购买请求等，都可以采用这种消息缓存队列缓冲机制，避开服务器集中处理的情况，减少服务器崩溃或宕机的情况发生。

通过应用本实施例的技术方案，在服务器接收到客户端发送的保单出单请求时，首先根据请求中携带的投保请求数据进行简单校验处理，如果校验成功，则将该投保请求数据存入预定消息缓存队列中等待推送给服务器进行处理，这样服务器处理请求时可以避开集中处理的情况，在遇到大量散户同时进行在线投保时，也不会给保险公司出单系统带来压力，减少出现服务器宕机的情况发生，通过这种方法可以支持高并发大批量散单出单。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的具体实施过程，提供了另一种保单出单请求的处理方法，如图2所示，该方法包括：

201、预先创建消息缓存队列。

对于本实施例，可以在保险公司出单系统的隔离区(Demilitarized Zone，DMZ)预先搭建应用程序编程接口(Application Programming Interface，API)出单架构，作为本方法的执行主体装置，使得保险公司服务器接收到的客户端发送的保单出单请求首先进入该API出单架构中进行处理，具体可以根据保单出单请求中的投保请求数据做简单的校验、以及利用消息缓存队列对请求进行缓冲处理等。其中，该隔离区可以认为是非安全系统与安全系统之间的缓冲区，该隔离区位于保险公司出单系统网络和外部网络之间的网络区域，通过该隔离区可以有效地保护保险公司出单系统安全。

而作为API出单架构与保险公司服务器之间的数据缓冲区域，预先创建消息缓存队列，该队列长度可以根据实际需求进行设置，例如可以根据各个服务器同时承担处理请求的最大数量进行设定，或者根据保险客户端的下载量进行设定，还可以根据实时接收到的请求数量，做相应的增大，以保证消息缓存队列正常可用(即一种可变长度的消息缓存队列)。创建完成的消息缓存队列用于在API出单架构对保单出单请求校验成功时，按一定的顺序接收API出单架构发送的该请求中携带的投保请求数据，并进行依次存储。

为了在消息缓存队列出现异常、无法保存新接收到的投保请求数据时，仍能够继续实现本实施例中的请求缓冲机制，进一步的，在本实施例的一种可选方式中，可以预先部署Redis缓存服务器，以实现缓存补偿机制。例如，在消息缓存队列储存的投保请求数据已满，无法存入新接收到的投保请求数据时，可以通过Redis缓存服务器存储新接收到的投保请求数据，然后等待在合适的时机推送给保险公司服务器进行处理。

为了加快保险公司服务器对保单出单请求的处理效率，进一步的，在本实施例的另一种可选方式中，可以根据实际保险业务需求，预先创建多个不同类别的消息缓存队列，例如，根据保险产品信息划分不同的类别，包括寿险、车险、儿童险、交通险等类别的消息缓存队列，并且每种类别的消息缓存队列对应专门处理各自类别的保单出单请求的服务器，例如，对于寿险类别的消息缓存队列可以对应专门处理寿险保单出单请求的服务器，而对于交通险类别的消息缓存队列可以对应专门处理交通险保单出单请求的服务器等。

这样在投保请求数据需要存入消息缓存队列时，可以按照下单用户需要购买的保险产品的类别，将该投保请求数据存入到相应类别的消息缓存队列中，然后等待推送给专门处理这一类别的服务器进行处理。对于本可选方式，由于不同类别的保单的出单流程可能不同，通过这种有针对性的处理，每台服务器专门处理少数几种类别的保单出单过程，降低了保单出单过程的复杂度计算，可以加快请求处理效率以及准确性。

需要说明的是，上述步骤201中的过程可以认为是本实施例中预先装备的过程，接下来的步骤202至205b所示过程为本实施例中对保单出单请求具体处理的过程。

202、当服务器接收到客户端发送的保单出单请求时，获取保单出单请求中携带的投保请求数据。

在本实施例中，需要在线投保的用户可以通过保险客户端下单投保，该用户需要登录自己的账号，然后选择自己需要购买的保险产品进行下单购买，并填写相应的投保数据，例如投保人信息、被保人信息、投保额等内容。在该用户支付成功后，客户端会将携带有包含投保数据和订单数据等投保请求数据的保单出单请求发送给保险公司服务器。相应的，当保险公司服务器接收到客户端发送的保单出单请求时，步骤201中预先搭建的API出单架构将其拦截，暂时不发送给保险公司服务器进行处理，获取保单出单请求中携带的投保请求数据进行简单校验处理，具体如步骤203所示。

203、根据获取到的投保请求数据进行校验处理。

示例性的，为了说明步骤203的具体实施过程，在本实施例的一种可选方式中，步骤203具体可以包括：根据投保请求数据中的订单数据，检测下单用户需要购买的保险产品是否存在；若存在，则检测该保险产品的库存是否充足；和/或检测该保险产品是否支付成功；若已支付成功，则检测相应的下单用户购买金额是否符合该保险产品的购买金额要求；和/或查询该保险产品对应的投保资格，并结合投保请求数据中下单用户填写的投保人和被保人信息，检测本次保单出单请求是否符合该保险产品的出单要求。

相应的，当检测出该保险产品不存在、和/或该保险产品的库存不足、和/或该保险产品支付未成功、和/或下单用户购买金额不符合该保险产品的购买金额要求、和/或检测出本次保单出单请求不符合该保险产品的出单要求时，确定校验失败；当检测出该保险产品存在、且该保险产品的库存充足、且保险产品支付成功、且下单用户购买金额符合保险产品的购买金额要求、且检测出本次保单出单请求符合保险产品的出单要求时，确定校验成功。

例如，从订单数据中可以查询到下单用户需要购买的保险产品a的名称或产品编号等，然后利用该名称或产品编号等查询保险公司方在售的各个保险产品中是否存在保险产品a，如果不存在保险产品a，可以确定校验失败，如果存在保险产品a，还可以进一步判断相应的库存是否充足，如果库存不足，说明保险产品a已经销售完毕，此次购买无效，进而确定校验失败。

再例如，还可以从订单数据中查询下单用户是否支付成功，如果遇到系统异常，客户端发送了未支付成功的订单数据，则可以确定此次校验失败；如果查询到下单用户支付成功，还可以进一步检测相应的下单用户购买金额是否符合该保险产品的购买金额要求，即下单用户实际支付的金额(可以包含优惠券、积分兑换等)是否可购买该保险产品，如果检测出下单用户购买金额不符合该保险产品的购买金额要求，可以判定此次校验失败。

再例如，也可以利用下单用户需要购买的保险产品的名称或产品编号等，查询该保险产品的投保资格，即投保人或被保人所必须具备的条件，判断投保请求数据中下单用户填写的投保人和被保人信息是否符合该条件，如果不符合，可以确定此次校验失败。

通过上述这些校验规则进行校验处理，可以快速判别出本次保单出单请求是否符合一些保单出单基本规定要求，帮助保险公司服务器快速进行过滤筛选，过滤掉一些不符合要求的请求，进而减少服务器处理无效请求的情况，从而一定程度上减少了服务器的请求量，降低服务器的负载压力，需要说明的是，上述各个校验规则从几个不同方面举例说明，还可以包含其它校验规则，具体可以根据保险业务的实际需求而定。

为了保证保险出单系统的安全性，降低保险业务的安全隐患，作为另一种可选方式，保单出单请求中还携带有客户端信息，相应的，步骤203具体还可以包括：根据客户端信息包含的下单用户账户信息，检测下单用户的年龄是否符合预定购买年龄条件；和/或根据下单用户账户信息，查询下单用户的信用信息，并根据该信用信息，检测下单用户的信用是否符合预设信用要求；和/或根据客户端信息包含的下单终端设备的设备标识(如设备名称、IMEI号等)、下单用户的用户标识(如用户姓名、身份证号码等)，结合预先设置的白名单和黑名单进行安全验证；和/或根据设备标识、用户标识，统计预定时间段内服务器接收到的下单终端设备或下单用户发送的请求数量是否大于预设数量阈值。

相应的，当检测出下单用户的年龄不符合预定购买年龄条件、和/或下单用户的信用不符合预设信用要求、和/或安全验证未通过、和/或请求数量大于预设数量阈值时，确定校验失败。

其中，上述预定购买年龄条件、预设信用要求、白名单和黑名单、预定时间段、预设数量阈值等都可以根据实际需求预先进行设定，白名单中包含可以通过安全验证的终端设备标识和/或用户标识，而黑名单中包含不能通过的安全验证的终端设备标识和/或用户标识。例如从下单用户账户信息中可以查询到下单用户当初注册时填写的年龄信息，进而可以确定下单用户的年龄，如果该年龄小于12周岁，即处于儿童阶段，可以判定不符合预定购买年龄条件，因为很可能是儿童误操作，确定校验失败以避免给用户带来经济损失。

再例如，从下单用户账户信息中可以查询到下单用户当初注册时填写的姓名、身份证号码等信息，然后利用这些信息可以通过第三方平台查询该用户的信用信息，如信用值、信用评分等，如果该信用值低于一定阈值时，说明该用户的信用较差，很可能是骗保用户，可以判定校验失败以避免给保险公司带来经济损失。

再例如，通过白名单和黑名单进行筛选实现安全验证，如果用户a存在经常骗保的记录，可以预先将用户a的标识加入到黑名单中，在对用户a所发出的保单出单请求进行安全验证时，可以确定其校验失败，进而使得用户a购买保单出单失败，不让其成功出保单，以减少保险公司的经济损失。

再例如，还可以统计一定时间段内下单用户或终端发送的请求数量是否大于一定数量，如果是，则将其加入黑名单或者直接确定校验失败，并输出告警信息，这种方式可以防止服务器被黑客恶意攻击，避免造成服务器出现宕机的情况。

通过上述这些保证安全性的校验规则，可以保证保险出单系统的安全性，降低保险业务的安全隐患，避免给用户和保险公司带来不必要的财产损失，需要说明的是，校验规则可以不限于此，还可以有其它的保证安全性的校验规则，具体可以保证保险业务安全性的实际需求而定。

204a、若校验失败，则向客户端发送投保失败响应信息。

进一步的，以使得客户端根据接收到的投保失败响应信息，输出投保失败相关的提示信息。其中，提示信息可以为文本提示信息、图片提示信息、音频提示信息、视频提示信息、灯光提示信息、振动提示信息等。

为了使得用户了解投保失败的原因，在本实施例的一个可选方式中，还可以根据校验结果，结合不符合的校验规则向客户端发送投保失败响应信息，以使得客户端可以结合不符合的校验规则，输出包含投保失败原因的提示信息，例如，保险产品库存不足导致的投保失败、购买金额不符合要求导致的投保失败等。

与步骤204a并列的步骤204b、若校验成功，则将投保请求数据存入预定消息缓存队列中，并且向客户端发送投保成功响应信息。

进一步的，以使得客户端根据接收到的投保成功响应信息，输出投保成功相关的提示信息。

在本实施例中，若通过步骤203中的这些校验规则，则在服务器真正处理之前先向客户端返回投保成功的响应消息，若这些校验规则中存在一个或多个校验失败，则也在服务器真正处理之前先向客户端反馈投保失败的响应消息，通过这种方式可以使得用户快速了解在线投保操作是否成功，减少用户的等待时间，可以提升用户的使用体验。

对于本实施例，可以按照服务器接收请求的时间顺序，将相应的投保请求数据存储在消息缓存队列当中，同时记录投保请求数据存入消息缓存队列时的时间戳，以便后续从消息缓存队列中向服务器推送投保请求数据时，根据时间戳，按照存入时间从早到晚的顺序依次进行推送处理。

这里在将投保请求数据存储在消息缓存队列之前，需要对消息缓存队列进行异常检测，如果消息缓存队列存在异常，可以将投保请求数据保存在步骤201中预先部署的Redis缓存服务器中，以代替消息缓存队列，保证本实施例中的保单出单请求处理过程可以正常实施。

为了保证消息缓存队列的存储空间不被无效数据占用，在本实施例的一个可选方式中，还可以定期或不定期对消息缓存队列中的过期数据进行清理，以节省消息缓存队列的存储空间。

205b、按照预定推送规则，将预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。

其中，预定推送规则可以根据保险公司服务器的实际请求处理情况而设定。

示例性的，为了说明步骤205b的具体实施过程，在本实施例的一种可选方式中，步骤205b具体可以包括：实时监测服务器的负载情况，并按照负载情况确定服务器是否处于闲时阶段；若服务器处于闲时阶段，则将预定消息缓存队列中每个保单出单请求对应的投保请求数据，按照预设顺序依次推送给服务器进行处理以生成相应保单；若服务器处于忙时阶段，则将停止将预定消息缓存队列中的投保请求数据推送给服务器进行处理。

例如，根据保险公司服务器实时的请求处理情况，如果监测出服务器此时的负载压力较大，这时可以暂缓不向服务器推送投保请求数据，如果监测出服务器的负载压力较小，可以处理大量的请求数据，此时可以向服务器推送投保请求数据进行处理，这样在服务器相对负载压力较小时才进行请求处理，减轻了服务器的压力，减少出现服务器宕机的情况发生。

在本实施例的另一种可选方式中，步骤205b具体还可以包括：将预定消息缓存队列中预定周期内存入的每个保单出单请求对应的投保请求数据,按照预定周期平均推送给服务器进行处理以生成相应保单。

例如，通常白天保险公司服务器的请求处理量要大于深夜时服务器的请求处理量，将消息缓存队列中每个请求对应的投保请求数据按照24小时平均推送给服务器进行处理，这样服务器处理请求时可以避开集中处理的情况，在遇到大量散户同时进行在线投保时，也不会给保险公司出单系统带来压力。

为了避免服务器对相同投保请求数据进行重复处理，进一步的，在本实施例的又一种可选方式中，在将预定消息缓存队列中保单出单请求对应的投保请求数据向服务器推送成功后，还可以包括：将推送成功的投保请求数据从预定消息缓存队列中删除；或定期或不定期从预定消息缓存队列中删除已推送成功的投保请求数据。通过这样的方式，避免向服务器重复推送相同的投保请求数据进行处理，减少服务器的请求处理量，进而减轻服务器的负载压力。

对于本实施例，为了加快请求处理效率，进一步的，在推送给服务器进行处理时，还可以采用负载均衡机制，优先分配给系统中负载压力较小的服务器进行处理，以保证请求处理的效率，也实现服务器之间负载均衡的目的。

在本实施例中，对于运行异常的服务器(如出现宕机、处理请求速度过慢等情况)，先不向其推送投保请求数据，后续如果经过测试正常后，再向其发送投保请求数据，以保证保单出单请求可以正常处理，并且保证请求的处理效率。

为了进一步的保证服务器不对无效请求数据进行处理，在本实施例的再一种可选方式中，保险公司服务器在对投保请求数据处理之前，先判断之前对该数据对应请求的校验结果是否成功，即重复验证步骤203中的校验结果，这里为了实现本实施内容，在投保请求数据存储消息缓存队列时可以一并存入校验结果，然后将投保请求数据推送给服务器时一并带上该校验结果，使得服务器在处理请求数据之前可以根据该校验结果进行再次确认，这里该校验结果可以认为是服务器对投保请求数据进行处理的凭证。

如果服务器确定校验结果为不成功，或者没有携带校验结果，此时可以将该投保请求数据退回到类似于异常数据收集库中，并定期或实时向相关工作人员推送存在处理异常的任务信息；如果服务器确定校验结果为成功，再对该投保请求数据进行处理，以生成保单。通过这种方式，可以保证服务器不对无效请求数据进行处理，减少服务器的请求处理量，进而减轻服务器的负载压力。

通过应用本实施例的技术方案，利用消息缓存队列实现数据缓冲过渡，减少保险公司服务器对于出单请求的处理量，通过这种异步处理的方式，客户端可以直接得到返回的处理结果，同时服务器压力也得到了有效缓解，进而减轻了保险公司出单系统的负担，避免出现由于压力过大导致的宕机情况，不会影响用户的正常使用，通过这种方式可以支持高并发大批量散单出单。

进一步的，作为图1方法的具体实现，本申请实施例提供了一种保单出单请求的处理装置，如图3所示，该装置包括：获取单元31、校验单元32、保存单元33、推送单元34。

获取单元31，可以用于当服务器接收到客户端发送的保单出单请求时，获取保单出单请求中携带的投保请求数据；

校验单元32，可以用于根据投保请求数据进行校验处理；

保存单元33，可以用于若校验单元32校验成功，则将投保请求数据存入预定消息缓存队列中，预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；

推送单元34，可以用于按照预定推送规则，将预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单。

在具体的应用场景中，使得用户快速了解在线投保操作是否成功，如图4所示，本装置还包括：发送单元35；

发送单元35，可以用于若校验单元32校验失败，则向客户端发送投保失败响应信息，进一步的，以使得客户端根据投保失败响应信息，输出投保失败相关的提示信息；

相应的，保存单元，具体可以用于若校验单元32校验成功，则将投保请求数据存入预定消息缓存队列中，并且向客户端发送投保成功响应信息，进一步的，以使得客户端根据投保成功响应信息，输出投保成功相关的提示信息。通过这种方式可以使得用户快速了解在线投保操作是否成功，减少用户的等待时间，可以提升用户的使用体验。

在具体的应用场景中，为了快速判别出本次保单出单请求是否符合一些保单出单基本规定要求，校验单元32具体可以用于根据投保请求数据中的订单数据，检测下单用户需要购买的保险产品是否存在；若存在，则检测保险产品的库存是否充足；和/或检测保险产品是否支付成功；若已支付成功，则检测相应的下单用户购买金额是否符合保险产品的购买金额要求；和/或查询保险产品对应的投保资格，并结合投保请求数据中下单用户填写的投保人和被保人信息，检测本次保单出单请求是否符合保险产品的出单要求；

相应的，当检测出保险产品不存在、和/或保险产品的库存不足、和/或保险产品支付未成功、和/或下单用户购买金额不符合保险产品的购买金额要求、和/或检测出本次保单出单请求不符合保险产品的出单要求时，确定校验失败；当检测出保险产品存在、且保险产品的库存充足、且保险产品支付成功、且下单用户购买金额符合保险产品的购买金额要求、且检测出本次保单出单请求符合保险产品的出单要求时，确定校验成功。

通过上述这些校验规则进行校验处理，可以快速判别出本次保单出单请求是否符合一些保单出单基本规定要求，帮助保险公司服务器快速进行过滤筛选，过滤掉一些不符合要求的请求，进而减少服务器处理无效请求的情况，从而一定程度上减少了服务器的请求量，降低服务器的负载压力。

在具体的应用场景中，为了保证保险出单系统的安全性，降低保险业务的安全隐患，保单出单请求中还可以携带有客户端信息，相应的，校验单元32具体还可以用于根据客户端信息包含的下单用户账户信息，检测下单用户的年龄是否符合预定购买年龄条件；和/或根据下单用户账户信息，查询下单用户的信用信息，并根据信用信息，检测下单用户的信用是否符合预设信用要求；和/或根据客户端信息包含的下单终端设备的设备标识、下单用户的用户标识，结合预先设置的白名单和黑名单进行安全验证；和/或根据设备标识、用户标识，统计预定时间段内服务器接收到的下单终端设备或下单用户发送的请求数量是否大于预设数量阈值；

相应的，当检测出下单用户的年龄不符合预定购买年龄条件、和/或下单用户的信用不符合预设信用要求、和/或安全验证未通过、和/或请求数量大于预设数量阈值时，确定校验失败。

通过上述这些保证安全性的校验规则，可以保证保险出单系统的安全性，降低保险业务的安全隐患，避免给用户和保险公司带来不必要的财产损失。

在具体的应用场景中，推送单元34，具体可以用于实时监测服务器的负载情况，并按照负载情况确定服务器是否处于闲时阶段；若服务器处于闲时阶段，则将预定消息缓存队列中每个保单出单请求对应的投保请求数据，按照预设顺序依次推送给服务器进行处理以生成相应保单；若服务器处于忙时阶段，则将停止将预定消息缓存队列中的投保请求数据推送给服务器进行处理。这样在服务器相对负载压力较小时才进行请求处理，减轻了服务器的压力，减少出现服务器宕机的情况发生。

在具体的应用场景中，推送单元34，具体还可以用于将预定消息缓存队列中预定周期内存入的每个保单出单请求对应的投保请求数据,按照预定周期平均推送给服务器进行处理以生成相应保单。这样服务器处理请求时可以避开集中处理的情况，在遇到大量散户同时进行在线投保时，也不会给保险公司出单系统带来压力。

在具体的应用场景中，为了避免服务器对相同投保请求数据进行重复处理，如图4所示，本装置还包括：删除单元36；

删除单元36，用于在将预定消息缓存队列中保单出单请求对应的投保请求数据向服务器推送成功后，将推送成功的投保请求数据从预定消息缓存队列中删除；或定期或不定期从预定消息缓存队列中删除已推送成功的投保请求数据。通过这样的方式，避免向服务器重复推送相同的投保请求数据进行处理，减少服务器的请求处理量，进而减轻服务器的负载压力。

需要说明的是，本申请实施例提供的一种保单出单请求的处理装置所涉及各功能单元的其他相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本申请实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的保单出单请求的处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图1、图2所示的方法，以及图3、图4所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种保单出单请求处理的实体设备，具体可以为个人计算机、服务器、网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的保单出单请求的处理方法。

可选地，该保单出单请求处理的实体设备还可以包括用户接口、网络接口、摄像头、射频(Radio Frequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如蓝牙接口、WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种保单出单请求处理的实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理和保单出单请求处理的实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与该实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本申请的技术方案，利用消息缓存队列实现数据缓冲过渡，减少保险公司服务器对于出单请求的处理量，通过这种异步处理的方式，客户端可以直接得到返回的处理结果，同时服务器压力也得到了有效缓解，进而减轻了保险公司出单系统的负担，避免出现由于压力过大导致的宕机情况，不会影响用户的正常使用，通过这种方式可以支持高并发大批量散单出单。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种保单出单请求的处理方法，其特征在于，包括：

在应用程序编程接口出单架构与服务器之间的数据缓存区域中，创建不同保险类别的消息缓存队列；其中，各个保险类别的消息缓存队列分别对应不同保险类别的服务器，消息缓存队列长度根据接收到的保单出单请求数量确定；

当所述应用程序编程接口出单架构接收到客户端发送的保单出单请求时，获取所述保单出单请求中携带的投保请求数据；

根据所述投保请求数据进行校验处理；

若校验成功，则将所述投保请求数据存入预定消息缓存队列中，所述预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；

按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单；

其中，所述按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单，具体包括：按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给与所述预定消息缓存队列对应保险类别的服务器进行处理以生成相应保单。

2.根据权利要求1所述的方法，其特征在于，根据所述投保请求数据进行校验处理之后，还包括：

若校验失败，则向所述客户端发送投保失败响应信息，以使得客户端根据所述投保失败响应信息，输出投保失败相关的提示信息；

所述若校验成功，则将所述投保请求数据存入预定消息缓存队列中，具体包括：

若校验成功，则将所述投保请求数据存入预定消息缓存队列中，并且向所述客户端发送投保成功响应信息，以使得客户端根据所述投保成功响应信息，输出投保成功相关的提示信息。

3.根据权利要求1或2所述的方法，其特征在于，根据所述投保请求数据进行校验处理，具体包括：

根据所述投保请求数据中的订单数据，检测下单用户需要购买的保险产品是否存在；

若存在，则检测所述保险产品的库存是否充足；和/或

检测所述保险产品是否支付成功；

若已支付成功，则检测相应的下单用户购买金额是否符合所述保险产品的购买金额要求；和/或

查询所述保险产品对应的投保资格，并结合所述投保请求数据中下单用户填写的投保人和被保人信息，检测本次保单出单请求是否符合所述保险产品的出单要求；

当检测出所述保险产品不存在、和/或所述保险产品的库存不足、和/或所述保险产品支付未成功、和/或下单用户购买金额不符合所述保险产品的购买金额要求、和/或检测出本次保单出单请求不符合所述保险产品的出单要求时，确定校验失败；

当检测出所述保险产品存在、且所述保险产品的库存充足、且所述保险产品支付成功、且下单用户购买金额符合所述保险产品的购买金额要求、且检测出本次保单出单请求符合所述保险产品的出单要求时，确定校验成功。

4.根据权利要求3所述的方法，其特征在于，所述保单出单请求中还携带有客户端信息，根据所述投保请求数据进行校验处理，具体还包括：

根据所述客户端信息包含的下单用户账户信息，检测下单用户的年龄是否符合预定购买年龄条件；和/或

根据所述下单用户账户信息，查询下单用户的信用信息，并根据所述信用信息，检测所述下单用户的信用是否符合预设信用要求；和/或

根据所述客户端信息包含的下单终端设备的设备标识、下单用户的用户标识，结合预先设置的白名单和黑名单进行安全验证；和/或

根据所述设备标识、所述用户标识，统计预定时间段内服务器接收到的所述下单终端设备或所述下单用户发送的请求数量是否大于预设数量阈值；

当检测出下单用户的年龄不符合预定购买年龄条件、和/或所述下单用户的信用不符合预设信用要求、和/或安全验证未通过、和/或所述请求数量大于预设数量阈值时，确定校验失败。

5.根据权利要求1所述的方法，其特征在于，所述按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单，具体包括：

实时监测服务器的负载情况，并按照所述负载情况确定所述服务器是否处于闲时阶段；

若所述服务器处于闲时阶段，则将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据，按照预设顺序依次推送给服务器进行处理以生成相应保单；

若所述服务器处于忙时阶段，则将停止将所述预定消息缓存队列中的投保请求数据推送给所述服务器进行处理。

6.根据权利要求1所述的方法，其特征在于，所述按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给服务器进行处理以生成相应保单，具体包括：

将所述预定消息缓存队列中预定周期内存入的每个保单出单请求对应的投保请求数据，按照所述预定周期平均推送给服务器进行处理以生成相应保单。

7.根据权利要求5或6所述的方法，其特征在于，在将所述预定消息缓存队列中保单出单请求对应的投保请求数据向服务器推送成功后，所述方法还包括：

将推送成功的投保请求数据从所述预定消息缓存队列中删除；或

定期或不定期从所述预定消息缓存队列中删除已推送成功的投保请求数据。

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

创建单元，用于在应用程序编程接口出单架构与服务器之间的数据缓存区域中，创建不同保险类别的消息缓存队列；其中，各个保险类别的消息缓存队列分别对应不同保险类别的服务器，消息缓存队列长度根据接收到的保单出单请求数量确定；

获取单元，用于当所述应用程序编程接口出单架构接收到客户端发送的保单出单请求时，获取所述保单出单请求中携带的投保请求数据；

校验单元，用于根据所述投保请求数据进行校验处理；

保存单元，用于若所述校验单元校验成功，则将所述投保请求数据存入预定消息缓存队列中，所述预定消息缓存队列中保存有服务器待处理的不同保单出单请求分别所携带的投保请求数据；

推送单元，用于按照预定推送规则，将所述预定消息缓存队列中每个保单出单请求对应的投保请求数据推送给与所述预定消息缓存队列对应保险类别的服务器进行处理以生成相应保单。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1至7中任一项所述的保单出单请求的处理方法。

10.一种保单出单请求的处理设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至7中任一项所述的保单出单请求的处理方法。

Images