CN107632893A - 消息队列处理方法及装置 - Google Patents

Abstract

本发明公开了一种消息队列处理方法及装置。该消息队列处理方法包括：从一消息队列中读取一当前消息；以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户；调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。该消息队列处理方法能够实现在启动消息队列监控处理作业的用户与发起消息的请求用户不一致的情况下，通过该作业的当前用户属性正确地更改文件的用户标签字段，且能够避免开启大量临时运行处理作业而导致的浪费系统资源及降低长运行处理作业效率的问题。

Description

消息队列处理方法及装置

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种消息队列处理方法及装置。

背景技术

消息队列(Message Queue,MQ)技术是一种应用于分布式应用间交换信息的技术。消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合的方法。消息队列的应用程序接口(Application Program Interface,API)被提供给新的或现存的应用中。通过消息的发送来提供各应用程序之间的信息交换功能。此外，消息队列还可以被应用于执行其他多种功能，如要求服务或异步处理等。

服务器在处理消息队列时，通常为其开启一长运行处理作业来进行处理，当检测到消息队列中出现待处理消息时，对该消息进行处理。当同时有大量消息进入消息队列中时，可以通过该长运行处理作业对消息队列中的消息逐一地进行处理。但是，由于长运行处理作业启动时，会默认设定其启动用户为其“当前用户”，输入输出程序(input/output，简称IO程序)会使用该“当前用户”更新文件的用户标签字段，即不管向前端服务器发起请求消息的用户是谁，在文件更新时总是打上了启动长运行处理作业的那个用户的用户标签，因此这种MQ长连接方案仅适用于那些发起消息的请求用户与启动长运行处理作业的用户一致的情况。

对于那些发起消息的请求用户可能发生变化的情况，可以使用的方案是长运行处理作业不用于处理消息，而是启动多个临时运行处理作业，并行地处理消息队列中的消息，一个临时运行处理作业只处理其相应的这一个消息，这一个消息处理完毕后就终止该临时运行处理作业。由于这些临时运行处理作业以其对应的消息的请求用户作为其当前用户，因此文件更新时用户标签的更改是正确的。但临时运行处理作业本身也会占用CPU资源且消耗内存，当同时开启较多地临时运行处理作业时反而会进一步降低效率，影响长运行处理作业的效率。

发明内容

有鉴于此，本发明提供一种消息队列处理方法及装置，能够解决文件更新时用户标签字段错误的问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

根据本发明的一方面，提供了一种消息队列处理方法，包括：从一消息队列中读取一当前消息；以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户；调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

在本公开的一种示例性实施例中，还包括：启动所述消息队列监控处理作业；调用一第二系统接口创建用户索引；其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

在本公开的一种示例性实施例中，还包括：判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户；如果所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户，则以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

在本公开的一种示例性实施例中，还包括：判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄；如果所述用户索引中不存在所述当前消息的请求用户相应的用户句柄，则以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

在本公开的一种示例性实施例中，还包括：调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。

根据本公开的一个方面，提供一种消息队列处理装置，包括：消息读取模块，用于从一消息队列中读取一当前消息；更改属性模块，用于以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户；更改字段模块，用于调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

在本公开的一种示例性实施例中，还包括：启动模块，用于启动所述消息队列监控处理作业；第一创建模块，用于调用一第二系统接口创建用户索引；其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

在本公开的一种示例性实施例中，还包括：第一判断模块，用于判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户；访问模块，用于当所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户时，以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

在本公开的一种示例性实施例中，还包括：第二判断模块，用于判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄；

第二创建模块，用于当所述用户索引中不存在所述当前消息的请求用户相应的用户句柄时，以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

在本公开的一种示例性实施例中，还包括：存储模块，用于调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。

根据本发明的消息队列处理方法及装置，能够通过用户句柄更改作业的当前用户，从而实现了发起消息的请求用户与启动作业的启动用户不一致的情况下正确更新文件的用户标签，同时避免了开启大量临时运行处理作业而导致的浪费系统资源及降低长运行处理作业效率的问题。另外，根据一些实施例，本发明的消息队列处理方法及装置还提供了一用户索引，用于存储已经创建的用户句柄及其用户之间的对应关系，从而可以在后面的消息中重复使用该用户句柄，能够避免句柄容量满了之后的报错。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。

附图说明

通过参照附图详细描述其示例实施例，本发明的上述和其它目标、特征及优点将变得更加显而易见。

图1是根据一示例性实施方式示出的一种消息队列处理方法的流程图。

图2是根据一示例性实施方式示出的另一种消息队列处理方法的流程图。

图3是根据一示例性实施方式示出的一种消息队列处理装置的框图。

图4是根据一示例性实施方式示出的另一种消息队列处理装置的框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本发明的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。

图1是根据一示例性实施方式示出的一种消息队列处理方法的流程图。如图1所示，消息队列处理方法包括：

在步骤S11中，从一消息队列中读取一当前消息。

在一示例性实施例，在步骤S11之前，该方法还可包括以下步骤：启动一消息队列监控处理作业。在另一实施例中，启动所述消息队列监控处理作业的时候，调用一第二系统接口创建一用户索引(user index，简称USRIDX，类似于一块内存)。其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

例如，假设所述消息队列中当前有3个待处理的消息A、消息B和消息C，分别对应发起消息A的请求用户甲、发起消息B的请求用户乙、发起消息C的请求用户丙，请求用户甲可对应创建一用户句柄甲、请求用户乙可对应创建一用户句柄乙、请求用户丙可对应创建一用户句柄丙，在所述用户索引中分别存储请求用户甲与用户句柄甲、请求用户乙与用户句柄乙、请求用户丙与用户句柄丙之间的对应关系。这里所说的对应关系可以是一一对应关系，即一个请求用户仅对应一个用户句柄，一个用户句柄仅对应一个请求用户；也可以是多对一的对应关系，即一个请求用户可以对应多个用户句柄。

其中所述消息队列监控处理作业可以为所述消息队列的长运行处理作业。这里的长运行处理作业是相对于临时运行处理作业而言的，即其持续监控所述消息队列，一旦发现有未处理的消息即将其取出处理，直到将所述消息队列中的消息处理完毕为止，而所述临时运行处理作业是为了某一消息单独生成的一个短运行处理作业，其处理完该消息即终止。

在步骤S12中，以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改所述消息队列监控处理作业的当前用户属性为所述当前消息的请求用户。

在一示例性实施例，在步骤S11和步骤S12之间还可包括以下步骤：判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户。

如果所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户，则以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

如果所述当前消息的请求用户与所述消息队列中的前一消息的请求用户为相同用户，则可直接调用所述长运行处理作业对所述当前消息进行处理，并且通过所述长运行处理作业的当前用户属性更改文件的用户标签字段。此时，不需要再以所述当前消息的请求用户的用户句柄为入参，调用所述第一系统接口更改所述消息队列监控处理作业的当前用户属性为所述当前消息的请求用户。

在一示例性实施例，在所述调用所述第三系统接口访问所述用户索引之后还可包括以下步骤：判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄。

如果所述用户索引中不存在所述当前消息的请求用户相应的用户句柄，则以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

如果所述用户索引中存在所述当前消息的请求用户相应的用户句柄，则可以直接从所述用户索引中读取获得所述当前消息的请求用户的用户句柄。

在一示例性实施例，在所述调用所述第四系统接口创建所述当前消息的请求用户对应的用户句柄之后还包括以下步骤：调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。

在步骤S13中，调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

本发明实施方式提供的消息队列处理方法，通过创建发起消息的请求用户的用户句柄，并利用用户句柄来更改作业的当前用户属性，从而能够实现在使用长运行处理作业处理消息时，即使请求用户发生变更也能正确更新文件的用户标签字段，并且避免了开启大量临时运行处理作业而导致的浪费系统资源及降低长运行处理作业效率的问题。

应清楚地理解，本发明描述了如何形成和使用特定示例，但本发明的原理不限于这些示例的任何细节。相反，基于本发明公开的内容的教导，这些原理能够应用于许多其它实施方式。

下面的实施方式以本发明提供的消息队列处理方法应用于一运行在IBM iSeries小型机上的保单核心管理系统为例进行详细说明。该保单核心管理系统包括基础开发架构和在该开发架构上开发和运行的保单管理系统，基础开发架构由CSC(Computer SciencesCorporation，公司计算机科学公司)提供，保险公司只能在其基础开发架构上进行保单管理功能的开发。作为其基础开发架构的一部分，文件更新的IO程序是基础开发架构自动创建的，“当前用户”是作业的一个属性，该IO程序使用作业的“当前用户”属性更新文件的用户标签字段，该用户标签字段是CSC标准文件结构的一部分。在作业启动的时候，“当前用户”默认设定为启动作业的用户的用户ID。

保单核心管理系统例如可以通过Websphere MQ消息中间件组件和外围系统进行交互，用户登录保险公司的网站、各种app等外围系统发起录单、保全、理赔等操作请求，这些外围系统把接收到的这些请求生成的消息(包括发起录单、保全、或者理赔等操作请求的用户的用户ID)发送到CSC系统的MQ消息中间件组件，CSC后台长运行处理作业监控MQ消息队列，一旦发现有消息立即直接进行处理，这些处理一般都会涉及到文件记录的更新。在现有技术方案下，此时文件的用户标签字段会更新为启动长运行处理作业的用户，也就意味着无论是谁在外围系统发起的请求，在文件更新的时候总是打上了启动长运行处理作业的那个用户的用户标签字段。因此MQ长运行方案仅适用于那些发起请求的用户与启动长运行处理作业的用户相同的MQ，启动长运行处理作业的用户必须和MQ的请求用户相同。例如，在电子化承保时使用的是同一个用户，可以为电子化承保建立专门的MQ，并使用电子化承保用户启动MQ长连接作业。而对于那些请求用户可能变化(例如保全和理赔操作)的业务，上述方案并不可行。

WebSphere MQ(也称MQSeries)以一致的、可靠的和易于管理的方式来连接应用程序，并为跨部门、企业范围的集成提供了可靠的基础。通过为重要的消息和事务提供可靠的、一次且仅一次的传递，Websphere MQ可以处理复杂的通信协议，并动态地将消息传递工作负载分配给可用的资源。

图2是根据一示例性实施方式示出的另一种消息队列处理方法的流程图。如图2所示，消息队列处理方法包括：在步骤S21中，启动消息队列监控处理作业。

在一示例性实施例，在步骤S21之前还可以包括以下步骤：判断是否启动消息队列监控处理作业，如果启动消息队列监控处理作业，则执行步骤S22，否则，执行步骤S213。

其中判断是否启动消息队列监控处理作业例如可以通过判断一预设标志的设置至来判断，如该预设标志为是(YES或TURE)，则判断启动该消息队列监控处理作业；而如果该预设标志设为否(NO或FALSE)，则判断不启动该消息队列监控处理作业。或者，也可以设为否时，启动该消息队列监控处理作业；而设为是时，不启动该消息队列监控处理作业。

该预设标志可以认为设定，也可以由其他应用程序、函数等进行设定等，本发明不以此为限。

在步骤S22中，调用一第二系统接口创建用户索引。

例如，所述第二系统接口为iSeries操作系统提供的QUSCRTUI接口，调用QUSCRTUI接口例如在qtemp库创建一个用户索引，用来保存用户和对应的用户句柄。当然，可以根据实际系统搭建需求建立在不同的操作系统，根据相应操作系统提供的API接口采用其它的接口，本发明不以此为限。

在步骤S23中，判断是否要求结束处理；如果是，则直接跳转到步骤S213结束；反之，进入步骤S24。

例如，这里的要求结束处理可以根据所述消息队列中待处理的消息是否完全处理完毕进行判断。当所述消息队列中没有待处理的消息时，直接结束本次操作。当所述消息队列中还有待处理的消息时，则执行后续的操作，继续读取所述消息队列中的下一个待处理的消息进行处理。

在一示例性实施例，可以根据预定规则对所述消息队列中的待处理消息进行优先级排序，也可以直接按照消息进入所述消息队列的时间先后顺序逐一处理。

在一示例性实施例，可以将所述消息队列中的一部分消息按照本发明提供的方法处理，此时，这里的要求结束处理可以根据所述消息队列中待处理的消息中按照本发明提供的方法处理的那部分消息是否完全处理完毕进行判断；也可以将所述消息队列中的另一部分消息采用新建的临时运行处理作业处理；还可以将所述消息队列中的再一部分消息采用现有技术中的直接利用长运行处理作业的当前用户属性更改文件的用户标签字段，而不需实现采取措施更改长运行处理作业的当前用户属性。

在步骤S24中，从所述消息队列中读取一消息。

当前读取的所述消息可以按照进入所述消息队列中的先后时间从待处理的消息中选择；也可以先读取优先级最高的待处理消息。

在步骤S25中，判断该消息的用户与前一消息的用户是否相同；如果用户相同，则跳转到步骤S212；反之，进入步骤S26。

在步骤S26中，以该消息的用户为入参，调用一第三系统接口访问所述用户索引。

例如，可以以该当前读取的消息的用户的用户ID为入参，或者其他任何能唯一标识该用户的标识作为入参，本发明不以此为限。

在一示例性实施例，所述第三系统接口可为QUSRTVUI接口。但本发明不以此为限。

在步骤S27中，判断所述用户索引中是否存在该消息的用户的用户句柄；如果所述用户索引中存在该消息的用户的用户句柄，则进入步骤S28；反之，跳转到步骤S29。

在步骤S28中，从所述用户索引中获得该消息的用户的用户句柄。

在步骤S29中，以该消息的用户为入参，调用一第四系统接口创建该消息的用户对应的用户句柄。

在一示例性实施例，所述第四系统接口可为QSYGETPH接口。但本发明不以此为限。

一个作业调用QSYGETPH接口目前最多只能创建约22000个句柄，现有技术中对同一个用户调用2次该QSYGETPH接口算2个句柄，也就意味着一个作业如果调用22000次该QSYGETPH接口以后，句柄容量就满了，会产生报错。

在步骤S210中，调用一第五系统接口将该消息用户和创建的用户句柄存储到所述用户索引中。

在一示例性实施例，所述第五系统接口可为QUSADDUI接口。但本发明不以此为限。

在步骤S211中，以该用户句柄为入参，调用一第一系统接口更改该作业的当前用户属性为该消息的用户。

在一示例性实施例，所述第一系统接口可为QWTSETP接口。但本发明不以此为限。

当长运行处理作业处理新消息时，首先调用QUSRTVUI接口检查该新消息中的用户是否在所述用户索引中存在，如果存在就直接读出该用户的用户句柄；如果不存在，则调用QSYGETPH接口得到该新消息的请求用户的用户句柄并调用QUSADDUI接口把它保存在用户索引中，然后以该用户句柄为入参调用QWTSETP接口从而更改长运行处理作业的当前用户属性。这意味着同一个用户只需要创建一个用户句柄，如果一个用户发送多个MQ消息，将共用一个用户句柄。这样虽然某一保险公司日处理消息上百万，但是用户数量如果小于22000，应用本发明实施方式提供的方法可以极大的提高消息的处理效率。

在步骤S212中，调用所述消息队列监控处理作业处理该消息，根据所述消息队列监控处理作业的当前用户属性更改文件的用户标签。处理完该次读取的消息后，继续跳回到步骤S25。

在一示例性实施例，消息队列监控处理作业处理消息的流程包括：判断所述消息队列中是否还有消息待处理，如果还有消息待处理，则循环执行上述步骤S24-S212，对消息队列中的消息进行处理；否则，进入无限等待模式，持续执行步骤S25中的判断。

本实施方式提供的消息队列处理方法，通过用户句柄来更改作业的当前用户属性，解决了请求用户变化情况下文件的用户标签字段更新错误的问题；同时，还通过创建存储用户和用户句柄的用户索引，使得同一用户的用户句柄可以重复使用，解决了句柄容量有限的问题。

需要注意的是，上述附图仅是根据本发明示例性实施方式的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。

下述为本发明装置实施例，可以用于执行本发明方法实施例。对于本发明装置实施例中未披露的细节，请参照本发明方法实施例。

图3是根据一示例性实施方式示出的一种消息队列处理装置的框图。如图3所示，消息队列处理装置10包括：消息读取模块11、更改属性模块12以及更改字段模块13。

其中消息读取模块11用于从一消息队列中读取一当前消息。

更改属性模块12用于以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户。

更改字段模块13用于调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

图4是根据一示例性实施方式示出的另一种消息队列处理装置的框图。如图4所示，消息队列处理装置20包括：启动模块21、第一创建模块22、消息读取模块23、第一判断模块24、访问模块25、第二判断模块26、第二创建模块27、存储模块28、更改属性模块29以及更改字段模块210。

其中消息读取模块23、更改属性模块29以及更改字段模块210分别与上述实施方式中的消息读取模块11、更改属性模块12以及更改字段模块13相同，在此不再赘述。

其中启动模块21用于启动所述消息队列监控处理作业。

第一创建模块22用于调用一第二系统接口创建用户索引。

其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

第一判断模块24用于判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户。

访问模块25用于当所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户时，以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

第二判断模块26用于判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄。

第二创建模块27用于当所述用户索引中不存在所述当前消息的请求用户相应的用户句柄时，以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

存储模块28用于调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。

需要注意的是，上述附图中所示的框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。

以上具体地示出和描述了本发明的示例性实施方式。应可理解的是，本发明不限于这里描述的详细结构、设置方式或实现方法；相反，本发明意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (10)

1.一种消息队列处理方法，其特征在于，包括：

从一消息队列中读取一当前消息；

以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户；

调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

2.根据权利要求1所述的消息队列处理方法，其特征在于，还包括：

启动所述消息队列监控处理作业；

调用一第二系统接口创建用户索引；

其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

3.根据权利要求2所述的消息队列处理方法，其特征在于，还包括：

判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户；

如果所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户，则以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

4.根据权利要求3所述的消息队列处理方法，其特征在于，还包括：

判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄；

如果所述用户索引中不存在所述当前消息的请求用户相应的用户句柄，则以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

5.根据权利要求4所述的消息队列处理方法，其特征在于，还包括：

调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。

6.一种消息队列处理装置，其特征在于，包括：

消息读取模块，用于从一消息队列中读取一当前消息；

更改属性模块，用于以所述当前消息的请求用户的用户句柄为入参，调用一第一系统接口更改一消息队列监控处理作业的当前用户属性为所述请求用户；

更改字段模块，用于调用所述消息队列监控处理作业处理所述当前消息，根据所述消息队列监控处理作业的所述当前用户属性更改文件的用户标签字段。

7.根据权利要求6所述的消息队列处理装置，其特征在于，还包括：

启动模块，用于启动所述消息队列监控处理作业；

第一创建模块，用于调用一第二系统接口创建用户索引；

其中，所述用户索引用于存储所述消息队列中的消息的请求用户及所述请求用户相应的用户句柄的对应关系。

8.根据权利要求7所述的消息队列处理装置，其特征在于，还包括：

第一判断模块，用于判断所述当前消息的请求用户与所述消息队列中的前一消息的请求用户是否为同一用户；

访问模块，用于当所述当前消息的请求用户与所述消息队列中的前一消息的请求用户不为同一用户时，以所述当前消息的请求用户为入参，调用一第三系统接口访问所述用户索引。

9.根据权利要求8所述的消息队列处理装置，其特征在于，还包括：

第二判断模块，用于判断所述用户索引中是否存在所述当前消息的请求用户相应的用户句柄；

第二创建模块，用于当所述用户索引中不存在所述当前消息的请求用户相应的用户句柄时，以所述当前消息的请求用户为入参，调用一第四系统接口创建所述当前消息的请求用户对应的用户句柄。

10.根据权利要求9所述的消息队列处理装置，其特征在于，还包括：

存储模块，用于调用一第五系统接口将所述当前消息的请求用户和创建的所述当前消息的请求用户对应的用户句柄存储到所述用户索引中。