本发明涉及数据监控
技术领域：
，尤其涉及一种高保额预警方法、装置、计算机设备及存储介质。
背景技术：
随着时代的发展，保险营销方式越来越呈多元化趋势。因网络的方便快捷性、身份隐藏性、以及大众保险意识的日益加强，网络营销保险的市场环境日益成熟，可以预见网络营销保险的方式将逐渐成为主导保险营销的方式。由于从线下营销方式转为线上营销，可减少人工复核的流程，也给保险业务带来风控问题。如果参保人在线上同时重复购一个或多个高保额，且被保险人为同一人的险种，将给保险公司带来保险金额总和超过保险标的的高赔付风险。保险公司如何对用户的网购保险行为进行风险控制成为亟需解决的问题。技术实现要素：基于此，有必要针对上述技术问题，提供一种可以对用户的网购保险行为进行风险控制的高保额预警方法、装置、计算机设备及存储介质。一种高保额预警方法，包括：获取客户端发送的投保请求，投保请求包括投保人id、险种id和被保险人id；基于险种id获取对应的当前险种保额和保额属性；若保额属性为高保额，则获取在预设时间内的累计高保额总和，累计高保额总和为投保人id和被保险人id均相同的所有高保额保单的历史险种保额的总和；基于当前险种保额和累计高保额总和，获得当前累计高保额；若当前累计高保额达到预设风控保额，则通知客户端线下处理。一种信息定制发送装置，包括：获取投保请求模块，用于获取客户端发送的投保请求，投保请求包括投保人id、险种id和被保险人id；获取险种保额模块，用于基于险种id获取对应的当前险种保额和保额属性；获取保额总和模块，用于若保额属性为高保额，则获取在预设时间内的累计高保额总和，累计高保额总和为投保人id和被保险人id均相同的所有高保额保单的历史险种保额的总和；获得累计保额模块，用于基于当前险种保额和累计高保额总和，获得当前累计高保额；发送线下处理模块，用于若当前累计高保额达到预设风控保额，则通知客户端线下处理。一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述高保额预警方法的步骤。一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述高保额预警方法的步骤。上述高保额预警方法、装置、计算机设备及存储介质中，通过筛选出保额属性为高保额的保单，然后计算该高保额保单对应的投保人id针对同一被保险人id在预设时间内的当前累计高保额来实现的。若当前累计高保额达到预设风控保额，则发送转线下处理通知，以转线下处理的方式可帮助保险公司有效避免因投保人多次重复投保，使得保险公司后期可能支付超出正常高价保额的风险。附图说明为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。图1是本发明一实施例中高保额预警方法的应用场景图；图2是本发明一实施例中高保额预警方法的流程图；图3是本发明一实施例中高保额预警方法的另一具体流程图；图4是本发明一实施例中高保额预警方法的另一具体流程图；图5是本发明一实施例中高保额预警方法的另一具体流程图；图6是本发明一实施例中高保额预警方法的另一具体流程图；图7是本发明一实施例中高保额预警方法的另一具体流程图；图8是本发明一实施例中高保额预警装置的一原理框图；图9是本发明一实施例中计算机设备的一示意图。具体实施方式下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。重复投保具体是指投保人以同一保险险种、同一可保利益同时向两个或两个以上的保险人购买险种的行为。因为生命无价，一般由于意外事故导致的残疾或身故，是可以重复投保获得重复获赔的，比如重疾险、寿险或生命险等。相应地，可重复投保的险种的险种保额也是较高的，从几十万起到几百万不等。重复投保很可能引起保险金额总和超过保险标的的保险价值，尤其网销保险在无人监管的环境下更容易引起上述问题。本发明针对保险公司如何对用户的网购保险行为进行风险控制的问题提出下述实施例：本实施例所提供的高保额预警方法，可应用在如图1的应用环境中，其中，客户端通过网络与服务器进行通信。客户端可以但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。本实施例中，服务器可以用独立设置的保险服务器来实现，该保险服务器是应用在保险公司中用于对保险业务数据进行处理的服务器。该保险服务器可与用户使用的客户端通过网络相连，用于对用户在客户端上进行的网购保险行为进行风险控制。在一实施例中，如图2所示，提供一种高保额预警方法，以该方法应用在图1中的服务器(具体为保险服务器)为例进行说明，包括如下步骤：s10.获取客户端发送的投保请求，投保请求包括投保人id、险种id和被保险人id。其中，投保请求是用户通过客户端向保险服务器发起购买保险业务的请求。可以理解地，该投保请求为线上投保请求，是用户通过客户端向服务器发起的请求。投保人是指与保险公司订立保险合同，并按照合同约定负有交付保险费义务的人。投保人id是用以区分不同投保人设立的唯一标识。该投保人id可以是投保人专属的标识，比如手机号、身份证号或用户名等。保险公司可提供多个不同的保险种类(以下简称“险种”)，险种id就是用以区分不同险种的唯一标识。该险种id可以是保险公司按内部预设规则生成的区别标识，包括以文字、数字、或者文字和数字的结合形成标识。比如意外险包括多个险种，对给意外险中多个险种区分时，可以以文字和数字的结合进行标识：ywx2018001、ywx2018002和ywx2018003等。被保险人是指其财产或者人身受保险合同保障，享有保险金请求权的人。被保险人可以为投保人，也可以为投保人指定的受益人。被保险人id是用以区分不同被保险人设立的唯一标识。该被保险人id可以是被保险人专属的标识，比如手机号、身份证号或用户名等。本步骤是保险服务器通过通讯协议端口接收客户端发送的投保请求，以通过该投保请求携带的信息进一步对投保人线上购买的保险请求实现高保额预警。s20.基于险种id获取对应的当前险种保额和保额属性。险种保额是指一个保险合同项下保险公司承担赔偿或给付保险金责任的最高限额。当前险种保额是指与该险种id对应的险种的险种保额。其中，保额属性是险种id对应的险种保额对应的属性。该保额属性可以将当前险种保额与预设标准进行比较，若当前险种保额高于预设标准，则其保额属性为高保额属性；反之，若当前险种保额不高于预设标准，则其保额属性为低保额属性。其中，预设标准为保险公司预先设置的用于评价保额属性的标准值。例如，预设标准为30万，若险种id对应的当前险种保额高于30万，则该险种id的保额属性为高保额属性。本步骤中，险种id对应的当前险种保额和保额属性是保险公司根据不同的险种预先设定的。保险服务器只需获取客户端发送的险种id即可在数据库中对应查找到保额属性和险种保额，无需用户再自行上传提供，简化投保流程。s30.若保额属性为高保额，则获取在预设时间内的累计高保额总和，累计高保额总和为投保人id和被保险人id均相同的所有高保额保单的历史险种保额的总和。其中，预设时间是保险公司根据实际情况设定的在保单生效起的一段时间，比如，保单生效起3个月。设定预设时间监控同一投保人的投保行为，可以避免投保人在一段时期内进行重复投保而产生骗保行为。累计高保额总和是在预设时间内，投保人id和被保险人id均相同的所有保额属性为高保额的保单中，所有历史险种保额的总和。比如，投保人id为tbr001在3个月内的累计高保额保单列表如下：由上表看出1号保单和3号保单对应同一投保人id，且被保险人id也相同。以1号保单中自tbr001的保单生效日20380301起3个月到20180601为止，3号保单还在有效期内(3号保单的失效日20380101>20180601)，投保人id为tbr001的投保人，给被保险人id为bxr001的被投保人投保的累计高保额总和为100万加150万，即250万。本步骤中，首先获取投保人id购买的的所有保额属性为高保额的高保额保单列表，然后从高保额保单列表中可筛选出被保人id相同的被保人列表，在该被保人列表可筛选出在预设时间内的目标险种，将目标险种分别对应的历史险种保额进行求和，可获取累计高保额总和。获取基于同一投保人id和同一被保人id对应的累计高保额总和，以便保险服务器实时计算基于同一投保人id和同一被保人id对应的当前累计高保额，加快计算当前累计高保额的处理速度。s40.基于当前险种保额和累计高保额总和，获得当前累计高保额。其中，当前累计高保额是连同当前投保请求中的保单，由同一投保人id购买，且被保人id相同的所有保单中险种保额的总和。本步骤中，将本次投保请求中的当前险种保额与累计高保额求和，可获得当前累计高保额，用以确认该投保申请是否可以在线上继续购买该保险。比如，当前险种保额为30万，累计高保额总和为250万，则当前累计高保额为280万。s50.若当前累计高保额达到预设风控保额，则通知客户端线下处理。其中，预设风控保额是保险公司为多个高保额的险种预先设定的一个在合理范围内的总保额，也即预设风控保额。转线下处理通知是将当前投保请求转为保险公司人工审核的通知，以便投保人及时获知当前投保请求的申请情况，保障双方通过安全可靠的方式继续完成投保人的投保请求。具体地，将步骤s40中计算得到的当前累计高保额与预设风控保额进行比较，若当前累计高保额达到(即大于或等于)预设风控保额，说明当前累计高保额可能超过财产的实际保险价值造成超保额，需要保险人线下进一步确认该保险业务。比如，预设风控保额为250万，而本次投保请求中投保人id对应的当前累计高保额为280万，此时保险服务器则将该投保请求转为下线处理也即由保险公司进行人工审核，以提高风险管控，因此，需通知客户端线下处理。本步骤中，保险服务器将可能产生高风险的投保申请转为线下处理，可有效避免因线上业务无人监管而给保险公司带来高保额的风险。优选地，在步骤s40之后，即在获得当前累计高保额的步骤之后，该高保额预警方法还包括：s60.若当前累计高保额未达到预设风控保额，则给客户端发送初审通过通知。其中，初审通过通知是保险服务器向客户端发送的用于表明投保申请通过初审的通知。本步骤中，若当前累计高保额未达到预设风控保额，说明该投保人的当前累计高保额在合理范围内，无需线下确认保单，可在线上继续完成保单初审的流程。本实施例中，保险服务器将计算后确定当前累计高保额仍属于合理范围内的保单继续在线上完成保单确认，提高保险业务处理的速率。本实施例提供的高保额预警方法首先筛选出保额属性为高保额的保单，然后计算该高保额保单对应的投保人id针对同一被保险人id在预设时间内的当前累计高保额。当前累计高保额达到预设风控保额，则转线下处理的方式可帮助保险公司有效避免因投保人多次重复投保，使得保险公司后期可能支付超出正常高价保额的风险；同时，保险服务器只需获取客户端发送的险种id即可在数据库中对应查找到保额属性和险种保额，无需用户再自行上传提供，简化投保流程；将计算后仍属于合理范围内的保单继续在线上完成保单确认，提高业务处理的速率。在一实施例中，如图3所示，在步骤s20中，即基于险种id获取对应的当前险种保额和保额属性，具体包括如下步骤：s21.获取与险种id对应的预设保险内容。其中，预设保险内容是保险公司给每个险种预先设定的，用于介绍与该险种相关的内容。该预设保险内容包括保额属性、险种保额、参保条件、保险有效期、保险标的和保险费用等。保险公司根据险种对应的预设保险内容可与投保人生成该险种的投保合同。本步骤中，保险服务器根据客户端发送的投保请求中携带的险种id，在数据库中查找该险种id对应的预设保险内容，无需客户端再自行上传，简化参保流程。s22.根据预设保险内容，获取当前险种保额和保额属性。具体地，险种id对应的预设保险内容可以以列表的形式展示，列表的列表头包括险种id、险种内容、保额属性和险种保额等内容。本步骤中，保险服务器读取列表中列表头为保险属性和险种保额的内容后，将险种id的当前险种保额和对应的保额属性复制到服务器的内存中，以便于进一步计算，无需客户端自行输入险种保额，以节省保险服务器获取信息并计算的时间，提高处理效率。本实施例中，保险服务器通过险种id可获取对应的预设保险内容，无需客户端再自行上传，简化参保流程；并可根据预设保险内容，快速获取与险种id对应的当前险种保额和保额属性，节省处理时间并提高处理效率。在一实施例中，如图4所示，在步骤s30中，即获取投保人id对应的同一被保险人id在预设时间内对应的累计高保额总和，具体包括如下步骤：s31.获取投保人id对应的高保额保单列表，高保额保单列表包括至少一个高保额保单，每一高保额保单包括被保险人id、险种保额和保单有效日期。其中，高保额保单列表是保险服务器给预先生成的，用于记录投保人在保险公司曾经购买过的所有保额属性为高保额的保单列表，以便于保险服务器实时调用该高保额保单列表，以获取用于监控高保额保单的数据。保单有效日期是指保险合同的有效期限，也是保险条款中的保险期间。在保险期间内，投保人按照约定交付保险费，保险公司则按照约定承担险种保额。大多数情况下保险期间的起始时间与投保人购买保险的开始时间是一致的。遇到不一致的情形，则在保险合同中对保单有效日期开始时间应另行规定。具体地，为了便于监控投保人的重复投保行为，在风险范围内，保险服务器给每个投保人都根据投保人id生成一份高保额保单列表，以便于及时获取与投保人id对应的历史高保额保单，从而进行风险监控。s32.统计高保额保单列表中被保险人id相同，且保单有效日期在预设时间内的所有险种保额的总和，获取累计高保额总和。具体地，保险服务器从高保额保单列表中可筛选出被保人id相同、在预设时间内的目标险种，并将目标险种分别对应的险种保额进行求和，可获取累计高保额总和。本步骤中，保险服务器可利用列表工具打开高保额保单列表。应用于本实施例，列表工具可使用sql,mysql或oracle等。现有列表工具都具有对多个列表头同时进行筛选的功能，该功能是通过设置查询指令来自动实现的。以sql为列表工具举例说明实现过程：(高保额保单列表的列表头包括保单有效日期、被保人和险种保额，且待查询的的被保人id为bxr001)：步骤1：通过数据库select指令对高保额保单列表进行筛选：保单有效日期在2018年3月1日至2038年3月1日之间，且被保人id＝bxr001的目标险种；步骤2：通过数据库sum指令对步骤1中筛选出的所有目标险种对应的险种保额进行求和操作。本实施例中可筛选出被保险人id相同，且保单有效日期在相同预设时间内的所有筛选列表，并将该筛选列表中的所有险种保额进行相加即可得到累计高保额总和。上述过程都是由保险服务器自动完成而无需人工干预计算，实现自动化处理保险业务，提高业务处理速度。本实施例中，保险服务器通过获取投保人id对应的高保额保单列表，可即时获取累计高保额总和，便于进一步结合本次投保请求中的当前险种保额计算当前累计高保额。在一实施例中，每一高保额保单对应唯一保单id，保单id是用以区分每一生效保单的唯一标识。保单有效日期包括保单生效时间和保单失效时间，其中，保单生效时间是保险公司开始履行保险合同承担保险义务开始的日期，保单失效时间是保险公司结束履行保险合同的日期。如图4所示，在步骤s31之后，即在获取投保人id对应的高保额保单列表的步骤之后，高保额预警方法还包括：s33.按预设时间更新高保额保单列表。为了维护高保额保单列表的有效性和可靠性，需要按预设时间更新高保额保单列表，避免计算出来的投保人id对应的累计高保额总和出现错误，而使线上保险业务的流程错误(比如本应转线下处理而未转线下处理)，从而避免这些流程错误造成不可避免的损失。预设时间可根据实际情况进行设定，比如可从保单生效时间起开始计算每1个月进行更新等。具体地，服务器按预设时间更新高保额保单列表，可以通过高保额保单列表所采用的列表工具上自带的定时更新工具完成。比如，在列表工具sql中，进入sqlserver数据库服务器获取企业管理器－>管理－>sqlserver代理－>作业－>新建作业，输入更新高保额保单列表，在“调度”里面设定更新时间，即可完成定时更新数据库中的高保额保单列表的任务。s34.在高保额保单列表中，若系统当前时间未达到任一保单id对应的保单生效时间或者已超过任一保单id对应的保单失效时间，则将保单id对应的险种保额清零。系统当前时间是指保险服务器与国家授时中心标准时间同步获得的当前时间。具体地，若系统当前时间未达到任一保单id对应的保单生效时间或者已超过任一保单id对应的保单失效时间，说明该保单id对应的保单未生效或者已经失效。可以理解地，保险公司只对生效保单承担保费，对失效的保单不再承担保险义务保费为零，因此需要将保单id对应的险种保额清零。以sql为列表工具举例说明实现过程：(高保额保单列表的列表头包括保单id、险种保额、保单生效时间和保单失效时间)：步骤1：通过数据库select指令获取系统当前时间；步骤2：通过数据库where指令获取系统当前时间小于保单生效时间，或者系统当前时间大于等于保单失效时间的保单id；步骤3：通过数据库update指令将步骤2得到的所有保单id对应的险种保额清零。本步骤中，保险服务器只保留在保单生效时间和保单失效时间之间的险种保额的实际数据，其余时间的数据都清零，保障保险服务器计算同一投保人的累计高保额总和的正确性。在一实施例中，每一投保人id对应唯一高保额保单列表，如图6所示，在步骤s60之后，即给客户端发送初审通过通知的步骤之后，该高保额预警方法还包括：s70.获取客户端发送的投保确认请求，投保确认请求包括投保人id和险种id。其中，高保额保单列表是保险服务器给预先生成的，用于记录投保人在保险公司曾经购买过的所有保额属性为高保额的保单列表，以便于保险服务器实时调用该高保额保单列表，以获取用于监控高保额保单的数据。可以理解地，服务器给每一投保人id都对应生成唯一的高保额保单列表。投保确认请求是用户通过客户端向保险服务器发送的用于确认购买保险业务的请求。投保确认请求包括投保人id，用以确认客户端同意以投保人id的名义购买该险种id。s80.基于投保确认请求生成与险种id对应的当前高保额保单。其中，当前高保额保单就是用户确认购买当前险种后生成的保单内容，也即电子保险合同。电子保险合同是投保人与保险公司基于险种id约定保险权利义务关系的协议。根据保险合同的约定，收取保险费是保险人的基本权利，赔偿或给付保险金是保险公司的基本义务；与此相对应的请求赔偿或给付险种保额是被保险人的基本权利。本步骤中，保险服务器接收到客户端发送的投保确认请求，也即可基于该投保确认请求对应的险种id，并生成电子保险合同，即当前高保额保单。具体地，电子保险合同可根据保险公司预设的保险合同模板生成。在保险公司预设的保险合同模板上，添加当前高保额保单的数据，比如：投保人id，被保人id、保单生效时间、险种属性和险种保额等。服务器通过自动添加内容到预设的保险合同模板上生成电子保险合同(即当前高保额保单)，加快保单的处理流程，减少人工录入保险信息的时间。s90.将当前高保额保单添加到投保人id对应的高保额保单列表中。为了便于保险公司及时统计投保人id对应的累计高保额总和，保险服务器需及时将保额属性为高保额的保单添加到高保额保单列表中。以sql为列表工具举例说明实现过程：(高保额保单列表包括的列表头顺序为投保人、被保人、保单生效时间、保单失效时期和险种保额)：通过数据库insert指令，按高保额保单列表中的列表头顺序依次添加对应数据，形成一条新的保单记录：投保人id为tbr001、被保人id为bxr001、保单生效时间为20180301、保单失效时间为20380301和险种保额为100万。投保人id被保人id保单生效时间保单失效时间险种保额tbr001bxr0012018030120380301100本步骤中，保险服务器根据高保额保单列表需要保存的列表头，从当前高保额保单中获取相应数据添加到高保额保单列表中，便于保险服务器后续实时计算累计高保额总和的正确性。在一实施例中，如图7所示，在步骤s50中，即通知客户端线下处理，具体包括如下步骤：s51.获取客户端的用户登录地址。其中，用户登录地址是用户通过互联网登录客户端时所在的位置。该用户登录地址可通过用户自行上传、定位工具(比如gps)定位或者基站定位等方式实现的。基于定位工具(比如gps)定位是利用手机上的第三方gps定位模块将自己的位置信号发送到定位后台来实现手机定位的。基站定位则是利用基站对手机的距离的测算距离来确定手机位置的。后者不需要手机具有gps定位能力，但是精度很大程度依赖于基站的分布及覆盖范围的大小，误差会超过一公里。以开启第三方gps定位模块的sdk为例说明定位过程：步骤1：获取用户所在的纬度和经度；步骤2：在第三方gps定位模块地图上显示出用户当前所在的位置。s52.根据用户登录地址，查找对应的线下营业网点。其中，查找线下营业网点可由客户根据自身情况进行个人设定，保险服务器也可默认指定一个预设半径，比如5公里。线下营业网点就是保险公司的业务分部所在地。具体地，保险公司的线下营业网点首先应将各自位置上传到第三方gps定位模块的地图上，以便第三方gps定位模块获取地图上的线下营业网点的位置。第三方gps定位模块在一用户登录地址为中心，预设半径范围内查找是否有已经上传的线下营业网点，并将查找结果在地图上显示出来。本步骤中，第三方gps定位模块可直观地显示线下营业网点的地址，便于用户及时获取线下营业网点所在的具体位置。s53.发送提醒信息，提醒信息包括线下营业网点。其中，提醒信息的方式包括但不限于：邮件、短信或者电话等，可以联系到用户的各种途径。具体地，保险服务器将线下营业网点的信息形成文字，粘贴到提醒信息中。以邮件为例，保险服务器获取用户注册时预留的电子邮箱地址，将粘贴有线下营业网点的提醒信息发送给该电子邮箱地址。本步骤中，保险服务器将线下营业网点发送给客户端，可以有效保障保险业务的推进。本实施例中，保险服务器通过用户登录地址获取到用户所在地附近的线下营业网点后，将相关的线下营业网点返回给客户端，可以有效保障保险业务的推进。本实施例提供的高保额预警方法首先筛选出保额属性为高保额的保单，然后计算该高保额保单对应的投保人id针对同一被保险人id在预设时间内的当前累计高保额。在当前累计高保额达到预设风控保额，则转线下处理的方式可帮助保险公司有效避免因投保人多次重复投保，使得保险公司后期可能支付超出正常高价保额的风险。进一步地，保险服务器通过险种id可获取对应的预设保险内容，无需客户端再自行上传，简化参保流程。保险服务器通过获取投保人id对应的高保额保单列表，可即时获取累计高保额总和，便于进一步结合本次投保申请计算当前累计高保额。保险服务器只保留在保单生效时间和保单失效时间直接的险种保额的实际数据，其余时间的数据都清零，保障保险服务器计算同一投保人的累计高保额总和的正确性。保险服务器根据高保额保单列表需要保存的列表头，从当前高保额保单中获取相应数据添加到高保额保单列表中，便于保险服务器后续实时计算累计高保额总和的正确性。保险服务器通过用户登录地址获取到用户所在地附近的线下营业网点后，将相关的线下营业网点返回给客户端，利于保险业务的顺利进展。应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。图8示出与上述实施例中高保额预警方法一一对应的高保额预警装置的原理框图。如图8所示，该高保额预警装置包括获取投保请求模块10、获取险种保额模块20、获取保额总和模块30、获得累计保额模块40和发送线下处理模块50。其中，获取投保请求模块10、获取险种保额模块20、获取保额总和模块30、获得累计保额模块40和发送线下处理模块50的实现功能与实施例中高保额预警方法s10至s50的步骤分别对应，为避免赘述，本实施例不一一详述。获取投保请求模块10，用于获取客户端发送的投保请求，投保请求包括投保人id、险种id和被保险人id。获取险种保额模块20，用于基于险种id获取对应的当前险种保额和保额属性；获取保额总和模块30，用于若保额属性为高保额，则获取投保人id对应的同一被保险人id对应的在预设时间内的累计高保额总和。获得累计保额模块40，用于基于当前险种保额和累计高保额总和，获得当前累计高保额。发送线下处理模块50，用于若当前累计高保额达到预设风控保额，则通知客户端线下处理。优选地，该高保额预警装置还包括发送通过通知单元60。发送通过通知单元60，用于若当前累计高保额未达到预设风控保额，则给客户端发送初审通过通知。优选地，获取险种保额模块20包括获取保险内容单元21和获取险种保单单元22。获取保险内容单元21，用于获取与险种id对应的预设保险内容。获取险种保单单元22，用于根据预设保险内容，获取当前险种保额和保额属性。优选地，获取保额总和模块30包括获取保单列表单元31和获取保额总和单元32。获取保单列表单元31，用于获取投保人id对应的高保额保单列表，高保额保单列表包括至少一个高保额保单，每一高保额保单包括被保险人id、险种保额和保单有效日期。获取保额总和单元32，用于统计高保额保单列表中被保险人id相同，且保单有效日期在预设时间内的所有险种保额的总和，获取累计高保额总和。优选地，该高保额预警装置还包括更新保单列表单元33和清零险种保额单元34。更新保单列表单元33，用于按预设时间更新高保额保单列表。清零险种保额单元34，用于在高保额保单列表中，若系统当前时间未达到任一保单id对应的保单生效时间或者已超过任一保单id对应的保单失效时间，则将保单id对应的险种保额清零。优选地，该高保额预警装置还包括获取确认请求单元70、生成保单单元80和添加保单单元90。获取确认请求单元70，用于获取客户端发送的投保确认请求，投保确认请求包括投保人id和险种id。生成保单单元80，用于基于投保确认请求生成与险种id对应的当前高保额保单。添加保单单元90，用于将当前高保额保单添加到投保人id对应的高保额保单列表中。优选地，发送线下处理模块50包括获取登录地址单元51、定位线下网点单元52和返回提醒信息单元53。获取登录地址单元51，用于获取客户端的用户登录地址。定位线下网点单元52，用于根据用户登录地址，查找对应的线下营业网点。返回提醒信息单元53，用于发送提醒信息，提醒信息包括线下营业网点。在一实施例中，提供一计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中高保额预警方法，为避免重复，这里不再赘述。或者，该计算机程序被处理器执行时实现上述实施例中高保额预警中各模块的功能，为避免重复，这里不再赘述。可以理解地，所述一个或多个存储有计算机可读指令的非易失性可读存储介质可以包括：能够携带所述计算机可读指令的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。在一实施例中，提供了一种计算机设备，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、内存储器、网络接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部服务器通过网络连接通信。该计算机程序被处理器执行时以实现一种高保额预警方法。所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。当前第1页12