本说明书一个或多个实施例涉及技术领域，尤其涉及一种消息异步处理方法及其设备。
背景技术：
由于企业面临各样数据集成和系统整合，corba、dcom、rmi等rpc(远程服务调用)中间件技术也应运而生，但由于采用rpc同步处理技术，在系统性能、健壮性、可扩展性上都存在着很多缺点。如投保单上传、投保状态查询、交费及查询接口服务原有调用顺序是国寿e店后台调用适配器，适配器调用esb(企业服务总线)，esb调用核心系统，整个流程全部是同步调用，耗时较长，用户等待时长较高。在交易高峰期时，系统会出现大量等待线程，导致系统响应缓慢，甚至宕机，严重影响用户体验。
目前业界普遍采用消息队列来解决以上问题，消息队列利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。常用的mq(消息服务)产品，例如rabbitmq、rocketmq、activemq、kafka等一般都有比较复杂的接口和通讯协议，学习和维护成本较高，并且不利于二次开发和维护，消费消息不支持重试，并且存在机器宕机后可能会产生消息顺序错乱的问题。
技术实现要素：
有鉴于此，本说明书一个或多个实施例的目的在于提出一种消息异步处理方法及其设备，以解决的现有技术中消息服务产品的不足导致的系统响应缓慢，严重响应用户体验的问题。
基于上述目的，本说明书一个或多个实施例提供了一种消息异步处理方法，包括：
接收请求消息，根据请求消息生成任务报文；
将任务报文放到任务队列中，形成消息队列；
从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
对上述步骤进行监控管理，并根据监控结果对上述步骤进行参数调整和报警处理。
可选的，所述将任务报文放到任务队列中，形成消息队列，包括：
对请求报文进行筛选，属于任务队列的请求报文，生成请求报文id，不属于任务队列的请求报文，则返回“错误”提示；
将请求报文id与现存的任务id进行比对，对非重复的请求报文id进行封装，形成封装请求报文，重复的请求报文id则返回“重复提交”提示；
将封装请求报文放入任务队列中并进行备份，形成消息队列。
可选的，所述消息队列为redis队列，是缓存队列结构，由队列(list)、索引(map)两部分构成；
所述list是一个先入先出(fifo)队列，采用redis的list实现，用于存储客户端上传数据；
所述map是采用redis的map实现，用于存储任务队列中存在的key和在任务队列中的位置(index)。
可选的，所述将封装请求报文放入任务队列中并进行备份，形成消息队列，包括：
将封装请求报文写入redis队列头部，并将封装请求报文索引同步备份到redis队列索引中，形成消息队列。
可选的，所述从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务状态，包括：
从消息队列的尾部提取请求任务；
根据调度任务对请求任务进行分类，所述调度任务至少包括：保单号申请调度任务、保单上载调度任务、状态刷新调度任务、交易号申请调度任务、交费调度任务、每日归档调度任务；
将分类后的请求任务的请求报文id与正在等待的线程进行匹配，唤醒线程，执行请求任务；
执行成功将请求任务的索引从redis队列的map中移除；执行失败将请求任务重新放入任务队列中，并将处理结构返回；
根据返回的处理结果，对至少包括：处理成功表、处理失败表、保单状态表进行状态的更新。
可选的，所述对上述步骤进行监控管理，包括：消息队列状态监控、调度任务状态监控和失败任务处理监控。
可选的，所述消息队列状态监控，包括：redis队列的灾备处理，所述redis队列的灾备处理包括：
调用redis队列的bgrewriteaof命令将内存中的数据重新刷到磁盘日志文件(.aof)中；
采用aof的每秒钟写入磁盘一次(appendfsynceverysec)方式来持久化redis队列中的数据；
用主从设备模式(master-slave)来进行容灾处理，master负责处理请求消息，并采用后台进程将数据同步至slave，slave负责数据的持久化。
可选的，所述调度任务状态监控，包括：通过页面进行调度任务的参数调整，将调整后的参数信息发送至调度任务服务端，进行调度任务服务端内存中参数值的调整。
可选的，所述失败任务处理监控，包括：查询失败任务，选择需要进行失败处理的任务，将需要处理的失败任务信息进行重复性检查，并反馈检查结果。
一种装置，用于执行所述消息异步处理方法，包括：
接收模块，用于接收请求消息，根据请求消息生成任务报文；
调度处理模块，用于将任务报文放到任务队列中，形成消息队列，从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
监控模块，用于对接收模块、调度处理模块中的处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理。
从上面所述可以看出，本说明书一个或多个实施例提供的一种消息异步处理方法及其设备，基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性。消息队列作为一个中间层软件，它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。
通过消息队列来实现系统间异步调用，实现应用解耦，提高系统响应速度，使系统运行更加健壮、稳定。同时通过对处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理，有利于降低机器宕机后消息产生顺序错乱的频率。
附图说明
为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本说明书一个或多个实施例消息异步处理方法流程图；
图2为本说明书一个或多个实施例redis队列数据结构图；
图3为本说明书一个或多个实施例任务调度处理流程图；
图4为本说明书一个或多个实施例监控管理框架图；
图5为本说明书一个或多个实施例redis灾备处理图；
图6为本说明书一个或多个实施例执行消息异步处理方法的设备内部结构框图；
图7为本说明书一个或多个实施例请求信息处理流程图。
具体实施方式
为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。
可知的是，以保险公司为例，投保单上传、投保状态查询、交费及查询接口服务原有调用顺序是e店后台调用适配器，适配器调用esb(企业服务总线)，esb调用核心系统，整个流程全部是同步调用，耗时较长，用户等待时长较高。在交易高峰期会时，系统会出现大量等待线程，导致系统响应缓慢，甚至宕机，严重响应用户体验。
目前业界普遍采用消息队列来解决系统同步处理数据带来的导致系统响应缓慢，甚至宕机，严重影响用户体验的问题，消息队列利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。常用的mq(消息服务)产品，例如rabbitmq、rocketmq、activemq、kafka等一般都有比较复杂的接口和通讯协议，学习和维护成本较高，并且不利于二次开发和维护，消费消息不支持重试，并且存在机器宕机后可能会产生消息顺序错乱的问题。
基于此，本说明书一个或多个实施例提供了一种消息异步处理方法，包括：
接收请求消息，根据请求消息生成任务报文；
将任务报文放到任务队列中，形成消息队列；
从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
对上述步骤进行监控管理，并根据监控结果对上述步骤进行参数调整和报警处理。
同时提供了一种装置，用于执行消息异步处理方法，包括：
接收模块，用于接收请求消息，根据请求消息生成任务报文；
调度处理模块，用于将任务报文放到任务队列中，形成消息队列，从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
监控模块，用于对接收模块、调度处理模块中的处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理。
基于消息的异步处理模型采用非阻塞的调用特性，发送者将消息发送给消息服务器，消息服务器在合适的时候再将消息转发给接收者；发送和接收是异步的，发送者无需等待，二者的生命周期也可以不必相同，而且发送者可以将消息间接传给多个接收者，大大提高了程序的性能、可扩展性及健壮性。消息队列作为一个中间层软件，它为分布式系统中创建、发送、接收消息提供了一套可靠通用的方法，实现了分布式系统中可靠的、高效的、实时的跨平台数据传输。
通过消息队列来实现系统间异步调用，实现应用解耦，提高系统响应速度，使系统运行更加健壮、稳定。同时通过对处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理，有利于降低机器宕机后消息产生顺序错乱的问题。
本说明书一个或多个实施例提供了一种消息异步处理方法，流程图如图1所示，以保险公司处理保单为例。包括如下步骤：
步骤101：接收请求消息，根据请求消息生成任务报文。
作为一个可选的实施例，步骤101接收请求消息，根据请求消息生成任务报文，具体的，以保险公司开发的保单处理客户端作为接收用户请求消息的平台，客户端作为任务提交者，负责组织报文和提交报文，以及对返回报文的解析。客户端接收用户请求后，组织任务报文并将报文通过接口调试提交到适配器。
步骤102：将任务报文放到任务队列中，形成消息队列。
作为一个可选的实施例，步骤102将任务报文放到任务队列中，形成消息队列，包括对请求报文进行筛选，属于任务队列的请求报文，生成请求报文id，不属于任务队列的请求报文，则返回“错误”提示；
将请求报文id与现存的任务id进行比对，对非重复的请求报文id进行封装，形成封装请求报文，重复的请求报文id则返回“重复提交”提示；
将封装请求报文放入任务队列中并进行备份，形成消息队列，具体的，将封装请求报文写入redis队列头部，并将封装请求报文索引同步备份到redis队列索引中，形成消息队列。
消息队列为redis队列，是缓存队列结构，由队列(list)、索引(map)两部分构成；所述list是一个先入先出(fifo)队列，采用redis的list实现，用于存储客户端上传数据。map是采用redis的map实现，用于存储任务队列中存在的key和在任务队列中的位置(index)。
具体的，适配器在接收到客户端请求时，如果未启用队列，则采用旧模式运行，或提交的任务不属于任务队列，则将“错误”提示结果返回客户端，属于任务队列的请求报文，生成请求报文id，适配器依次从任务队列，正在处理任务，成功表和成功历史表中，判断请求报文id是否已有相同任务被提交，如果有重复，则提示用户“重复提交”，如果没有，对请求报文id进行封装，形成封装请求报文，将封装之后的请求报文放入redis队列，如图2所示，并将报文存入备份表，形成消息队列。如果任务已在成功表中存在则直接取出结果报文返回到客户端。redis队列是缓存队列结构，由队列(list)、索引(map)两部分构成；list是一个先入先出(fifo)队列，采用redis的list实现，用于存储客户端上传数据；map是采用redis的map实现，用于存储任务队列中存在的key和在任务队列中的位置(index)。用于快速检索队列中的某项数据，比如重复上传校验。适配器将任务写入任务队列头部，并将任务索引同步到map中，以便于检测任务是否重复。
所有往redis队列中的写入操作都是在适配器中进行，其中写操作包括以下几个方面：客户端发送的请求。调度任务请求esb超时后重入队列操作。管理员从后台管理界面重新提交报文操作。
步骤103：从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态。
作为一个可选的实施例，步骤103从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态，包括从消息队列的尾部提取请求任务；
根据调度任务对请求任务进行分类，调度任务至少包括：保单号申请调度任务、保单上载调度任务、状态刷新调度任务、交易号申请调度任务、交费调度任务、每日归档调度任务；
将分类后的请求任务的请求报文id与正在等待的线程进行匹配，唤醒线程，执行请求任务；
执行成功将请求任务的索引从redis队列的map中移除；执行失败将请求任务重新放入任务队列中，并将处理结构返回；
根据返回的处理结果，对至少包括：处理成功表、处理失败表、保单状态表进行状态的更新。
具体的，调度任务依次从消息队列中将任务取出，通过接口调用方式将请求任务发送到esb服务，根据esb返回结果记录到表中。调度任务依据先进先出(fifo)原则依次从消息队列尾部获取待处理的任务进行异步处理：调度任务从消息队列中获取请求任务，按照请求任务类型进行业务处理，并发送至esb服务器，并等待esb服务器的处理结果，根据esb返回的处理结果对处理成功表、处理失败表、保单状态等相关表进行状态的更新。调度任务可按业务类型进行分类：保单号申请调度任务、保单上载调度任务、状态刷新调度任务、交易号申请调度任务、交费调度任务、每日归档调度任务等。根据将分类后的请求任务的请求报文id找到正在等待的线程，然后唤醒线程，线程唤醒后去获取结果并返回。当线程等待超时后直接返回超时提示信息。并执行任务，任务成功后将任务索引从map中移除；如果任务执行失败，则重新入队。
如图3所示，调度任务线程从消息队列中获取到的任务类型，将消息队列map中的任务信息放入到任务调度的map中，并将该任务信息从原来的任务队列中删除(根据key值删除任务队列的map中的该任务信息)，从内存中读取任务类型的服务器配置信息，并且将请求报文发送至esb服务器并等待esp服务器返回结果。如果报文发送至esb服务器成功，并且esb也返回处理结果，将esb的处理结果存储到任务成功表和任务失败表；如果报文发送至esb服务器不成功(网络、程序错误等原因引起发送不成功)，则将map中该任务信息的不成功次数 1，如果不成功次数小于系统设置的不成功次数，则从调度任务的map中删除该任务信息，将该任务重新插入任务队列的map中，如果不成功次数大于等于系统设置的不成功次数，则从调度任务的map中删除该任务信息，并且将失败信息写入任务处理失败表并记录失败原因，处理完成后该线程将处理队列中的下一个任务。
步骤104：对上述步骤进行监控管理，并根据监控结果对上述步骤进行参数调整和报警处理。
作为一个可选的实施例，步骤104对步骤101～103进行监控管理，并根据监控结果对步骤101～103(如图7)进行参数调整和报警处理，监控管理以后台运行方式对调度任务状态、消息队列状态及服务器运行状态监控，通过系统参数配置对调度任务进行管理，通过对处理失败的任务重新入队列的方式进行处理，通过设置预警参数，对失败任务进行预警，并将预警信息以短信、邮件方式发送至管理员。
消息队列状态监控，包括：redis队列的灾备处理，redis队列的灾备处理包括：
调用redis队列的bgrewriteaof命令将内存中的数据重新刷到磁盘日志文件(.aof)中；
采用aof的每秒钟写入磁盘一次(appendfsynceverysec)方式来持久化redis队列中的数据；
用主从设备模式(master-slave)来进行容灾处理，master负责处理请求消息，并采用后台进程将数据同步至slave，slave负责数据的持久化。
调度任务状态监控，包括：通过页面进行调度任务的参数调整，将调整后的参数信息发送至调度任务服务端，进行调度任务服务端内存中参数值的调整。
失败任务处理监控，包括：查询失败任务，选择需要进行失败处理的任务，将需要处理的失败任务信息进行重复性检查，并反馈检查结果。
具体的，如图4所示，监控管理：监控管理负责对任务调度状态、消息队列状态、以及任务调度服务器进行监控，类似心跳处理，admin后台每隔一段时间(时间可配置)，向任务调度服务器发起监控请求，调度任务服务器接收到请求，将监控结果返回给admin后台，admin后台管理接收到监控结果，及时将最新的监控结果进行页面展示并保存数据库。监控内容包括：
1)调度任务线程池使用状态(使用状态、正在执行的线程数)；
2)服务器状态(cpu使用率、内存使用率、线程数)；
3)redis服务状态(内存使用率、剩余空间)；
4)调用超时任务数量。
redis灾备处理，如图5所示，采用master-slave方式来进行容灾处理，master负责处理客户端请求，并采用后台进程将数据同步至slave，slave负责数据的持久化；当master宕机之后通过radwarevip把slave升级为master来接管已宕机的master，直到管理员重启宕机的master后，再恢复至初始的master-slave工作模式，以此来实现24小时不间断的服务。
为了降低redis服务器意外宕机时的数据丢失率，在redis服务重启时能够自动恢复内存中的数据，在此采用aof的appendfsynceverysec方式来持久化缓存队列中的数据。同时为了避免aof文件过于冗余和臃肿，定时(每天)的调用redis的bgrewriteaof命令来将内存中的数据重新刷到磁盘日志文件(.aof)中。bgrewriteaof命令和快照方式类似，将内存中的所有数据以命令方式保存到临时文件，再用临时文件替换旧的aof文件。
调度任务状态监控：admin后台管理可通过调度任务参数配置实时调整调度任务服务器设置，在admin后台管理服务通过页面进行系统参数的调整，调整录入完成后，admin后台将调整后的参数信息发送到任务调度服务端，任务调度服务端接收到调整后的参数，及时更新任务调度服务端内存中的系统参数的值，可进行配置的参数有：最大线程数、超时时间、最大失败次数、预警阀值。比如调整调度任务的最大线程总数，当业务非常多，调度任务的线程不够用，造成任务队列快满，可及时的调大跳读任务的最大线程总数，加快调度任务的处理，达到减少任务队列的目的。
失败任务处理：admin后台可通过页面对失败任务进行查询，选择要进行失败处理的任务，确认之后，admin后台将需要处理的失败任务信息发送到适配器端进行重复性检查，并将检查结果反馈至admin后台服务端，结果可分为：提示任务重复；提示任务已经进入队列。
基于上述的方法，本发明实施例提供一种执行消息异步处理方法的设备，内部结构框图如图6所示，包括接收模块601，调度处理模块602，监控模块603。
接收模块601，用于接收请求消息，根据请求消息生成任务报文；具体的，以保险公司开发的保单处理客户端作为接收用户请求消息的平台，客户端作为任务提交者，负责组织报文和提交报文，以及对返回报文的解析。客户端接收用户请求后，组织任务报文并将报文通过接口调试提交到适配器。
调度处理模块602，用于将任务报文放到任务队列中，形成消息队列，从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态。具体的：形成消息队列，包括对请求报文进行筛选，属于任务队列的请求报文，生成请求报文id，不属于任务队列的请求报文，则返回“错误”提示；
将请求报文id与现存的任务id进行比对，对非重复的请求报文id进行封装，形成封装请求报文，重复的请求报文id则返回“重复提交”提示；
将封装请求报文放入任务队列中并进行备份，形成消息队列，具体的，将封装请求报文写入redis队列头部，并将封装请求报文索引同步备份到redis队列索引中，形成消息队列。
消息队列为redis队列，是缓存队列结构，由队列(list)、索引(map)两部分构成；所述list是一个先入先出(fifo)队列，采用redis的list实现，用于存储客户端上传数据。map是采用redis的map实现，用于存储任务队列中存在的key和在任务队列中的位置(index)。
包括从消息队列的尾部提取请求任务；
根据调度任务对请求任务进行分类，调度任务至少包括：保单号申请调度任务、保单上载调度任务、状态刷新调度任务、交易号申请调度任务、交费调度任务、每日归档调度任务；
将分类后的请求任务的请求报文id与正在等待的线程进行匹配，唤醒线程，执行请求任务；
执行成功将请求任务的索引从redis队列的map中移除；执行失败将请求任务重新放入任务队列中，并将处理结构返回；
根据返回的处理结果，对至少包括：处理成功表、处理失败表、保单状态表进行状态的更新。
监控模块603，用于对接收模块、调度处理模块中的处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理。具体的：监控管理以后台运行方式对调度任务状态、消息队列状态及服务器运行状态监控，通过系统参数配置对调度任务进行管理，通过对处理失败的任务重新入队列的方式进行处理，通过设置预警参数，对失败任务进行预警，并将预警信息以短信、邮件方式发送至管理员。
消息队列状态监控，包括：redis队列的灾备处理，redis队列的灾备处理包括：
调用redis队列的bgrewriteaof命令将内存中的数据重新刷到磁盘日志文件(.aof)中；
采用aof的每秒钟写入磁盘一次(appendfsynceverysec)方式来持久化redis队列中的数据；
用主从设备模式(master-slave)来进行容灾处理，master负责处理请求消息，并采用后台进程将数据同步至slave，slave负责数据的持久化。
调度任务状态监控，包括：通过页面进行调度任务的参数调整，将调整后的参数信息发送至调度任务服务端，进行调度任务服务端内存中参数值的调整。
失败任务处理监控，包括：查询失败任务，选择需要进行失败处理的任务，将需要处理的失败任务信息进行重复性检查，并反馈检查结果。
需要说明的是，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。
本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。
1.一种消息异步处理方法，其特征在于，包括：
接收请求消息，根据请求消息生成任务报文；
将任务报文放到任务队列中，形成消息队列；
从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
对上述步骤进行监控管理，并根据监控结果对上述步骤进行参数调整和报警处理。
2.根据权利要求1所述的消息异步处理方法，其特征在于，所述将任务报文放到任务队列中，形成消息队列，包括：
对请求报文进行筛选，属于任务队列的请求报文，生成请求报文id，不属于任务队列的请求报文，则返回“错误”提示；
将请求报文id与现存的任务id进行比对，对非重复的请求报文id进行封装，形成封装请求报文，重复的请求报文id则返回“重复提交”提示；
将封装请求报文放入任务队列中并进行备份，形成消息队列。
3.根据权利要求2所述的消息异步处理方法，其特征在于，所述消息队列为redis队列，是缓存队列结构，由队列(list)、索引(map)两部分构成；
所述list是一个先入先出(fifo)队列，采用redis的list实现，用于存储客户端上传数据；
所述map是采用redis的map实现，用于存储任务队列中存在的key和在任务队列中的位置(index)。
4.根据权利要求2所述的消息异步处理方法，其特征在于，所述将封装请求报文放入任务队列中并进行备份，形成消息队列，包括：
将封装请求报文写入redis队列头部，并将封装请求报文索引同步备份到redis队列索引中，形成消息队列。
5.根据权利要求1所述的消息异步处理方法，其特征在于，所述从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务状态，包括：
从消息队列的尾部提取请求任务；
根据调度任务对请求任务进行分类，所述调度任务至少包括：保单号申请调度任务、保单上载调度任务、状态刷新调度任务、交易号申请调度任务、交费调度任务、每日归档调度任务；
将分类后的请求任务的请求报文id与正在等待的线程进行匹配，唤醒线程，执行请求任务；
执行成功将请求任务的索引从redis队列的map中移除；执行失败将请求任务重新放入任务队列中，并将处理结构返回；
根据返回的处理结果，对至少包括：处理成功表、处理失败表、保单状态表进行状态的更新。
6.根据权利要求1所述的消息异步处理方法，其特征在于，所述对上述步骤进行监控管理，包括：消息队列状态监控、调度任务状态监控和失败任务处理监控。
7.根据权利要求6所述的消息异步处理方法，其特征在于，所述消息队列状态监控，包括：redis队列的灾备处理，所述redis队列的灾备处理包括：
调用redis队列的bgrewriteaof命令将内存中的数据重新刷到磁盘日志文件(.aof)中；
采用aof的每秒钟写入磁盘一次(appendfsynceverysec)方式来持久化redis队列中的数据；
用主从设备模式(master-slave)来进行容灾处理，master负责处理请求消息，并采用后台进程将数据同步至slave，slave负责数据的持久化。
8.根据权利要求6所述的消息异步处理方法，其特征在于，所述调度任务状态监控，包括：通过页面进行调度任务的参数调整，将调整后的参数信息发送至调度任务服务端，进行调度任务服务端内存中参数值的调整。
9.根据权利要求6所述的消息异步处理方法，其特征在于，所述失败任务处理监控，包括：查询失败任务，选择需要进行失败处理的任务，将需要处理的失败任务信息进行重复性检查，并反馈检查结果。
10.一种装置，其特征在于，用于执行权利要求1～9任一所述消息异步处理方法，包括：
接收模块，用于接收请求消息，根据请求消息生成任务报文；
调度处理模块，用于将任务报文放到任务队列中，形成消息队列，从消息队列中获取请求任务，并对请求任务进行业务分类，将分类后的请求任务进行业务处理，并根据处理结果更新请求任务的状态；
监控模块，用于对接收模块、调度处理模块中的处理步骤进行监控管理，并根据监控结果对各步骤进行参数调整和报警处理。
技术总结