具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
另外,下述各方法实施例中的步骤时序仅为一种举例,而非严格限定。
图1为本发明实施例提供的一种数据库系统的组成示意图,如图1所示,该数据库系统可以包括若干计算节点以及云存储系统。其中,若干计算节点比如包括图1中示意的计算节点1、计算节点2、……、计算节点N。其中,云存储系统可以是由若干存储节点构成的分布式云存储系统,存储节点是指包含存储介质的设备。
实际应用中,上述计算节点比如可以实现为云服务器(ECS),在计算节点中可以部署有所需的服务程序,比如下文中提及的存储引擎,等等。
需要说明的是:第一,本发明实施例中所说的数据库系统包括若干计算节点和云存储系统,并非限定这些计算节点和云存储系统是由数据库系统独占使用的,比如,计算节点中还可以运行有与数据库系统所需服务程序无关的其他服务程序,云存储系统中存储的不仅仅是数据库系统所需存储的消息。第二,本发明实施例中使用的数据库系统可以是计算与存储相分离的数据库系统,即计算资源(上述若干计算节点)与存储资源(云存储系统中包含的各存储节点)是分离的。其中,该分离是物理上的分离,比如,一个设备不同时作为存储节点和计算节点使用。相当于构建了两个独立的资源池,一个是计算资源池,一个是存储资源池。
在一可选实施例中,本发明实施例中的数据库系统可以是多模的分布式数据库系统,其中,所谓分布式数据库系统即为上文中所述的使用分布式计算资源和分布式存储资源的数据库系统,所谓多模是指数据库系统中支持多种存储引擎,比如下文中所提及的宽表引擎、全文搜索引擎,等等。实际应用中,同一计算节点中可以部署有一种或多种存储引擎,如图1中所示。
在存储分离的数据库系统架构下,对于计算资源即各计算节点来说,并不感知云存储系统的内部组成和工作过程,也就是说,计算节点仅维护自身的运行,不需要关心云存储系统的运行。如图1中所示,云存储系统对外可以提供有统一的服务接口,称为云存储服务接口,计算节点调用该云存储服务接口,将需要存储的数据提供给云存储系统,以由云存储系统进行数据存储,读取数据的过程亦然,也是通过调用该云存储服务接口,将查询请求提供到云存储系统以读取相应数据。一般地,为保证数据安全可靠,云存储系统是采用多副本机制进行数据存储的。
另外,如图1所示,在计算资源层面,可以在各个计算节点中设有统一的接入层,如图中示意的查询编译服务,用户对数据库系统的访问由该查询编译服务接入。
在本发明实施例中,数据库系统被用于进行消息队列的实现,在该场景下,访问数据库系统的用户一般称为:消息生产者和消息消费者。其中,消息生产者也可以称为消息发布者,是指发布消息到数据库系统的主体,该主体可以是终端、服务、服务器等。消息消费者也可以称为消息订阅者,是指负责接收并消费消息的主体。
常见的可以实现消息队列的数据库包括kafka、RocketMQ,等等。这些数据库尽管从架构和使用方式和性能上略有不同,但其基本使用场景都相对接近。传统的消息队列在消息推送等场景下存在以下问题:
存储:不适合长期保存数据,通常数据过期时间在天级别。
查询能力:不支持较为复杂的查询和过滤条件,往往仅支持单一维度的查询。
一致性和性能难以同时保证:有些数据库更重吞吐,为了提高性能存在某些情况下丢数据的可能,而事务处理能力较好的消息队列吞吐又较为受限。
分区(partition)快速扩展能力:通常一个主题(topic)下的分区数量是固定的,不支持快速扩展。
物理队列/逻辑队列:通常只支持少量的物理队列(如将每个分区看成是一个物理队列),而在实际应用场景下,可能需要的是在物理队列基础上模拟出逻辑队列。而物理队列和逻辑队列之间的转换通常都需要用户负责实现。
具体来说,在一些传统实现消息队列的数据库中,会定义一些主题,以即时通讯场景为例,涉及到的主题可能包括单聊、群聊。以单聊为例,比如某用户A在与其三位好友分别聊天,这三个聊天都属于单聊这个主题,即归属于同一topic。假设在这个主题下预先配置了10个分区,那么用户A与这三位好友的聊天消息将会被分散到不同的分区中存储,而且实际上,往往不一定是与同一位好友的聊天消息被存储到同一个分区内。概括来说,就是同一用户A与不同好友的聊天消息会被混在一起向特定的几个物理队列中存储。如果将用户A与多位好友分别聊天的需求看作是产生多个逻辑队列的需求,那么可以看到,物理队列与逻辑队列是不匹配的,两者之间没有关联性。在现有消息队列的实现架构下,比如想要为即时通讯系统中的每个用户维护一个逻辑上的消息队列,开发者往往需要很多额外的开发工作,开发难度很大。
针对上述问题,本发明实施例提供了一种新的轻量级的消息队列模型。该消息队列模型可以是基于上述数据库系统实现的,这样,基于数据库系统的计算存储相分离的架构,可以实现高效的消息处理,海量消息存储以及低成本的存储扩容。因为计算存储相分离,当需要扩展存储容量时,仅需要扩展存储节点即可。但是,如果计算和存储耦合在一起,当存储容量不够时,扩容了一个设备,则计算资源也被扩容了,成本变高。但是,上述消息队列模型也可以基于其他类型的数据库来实现,不以计算存储相分离的数据库系统为限。
本发明实施例中,可以将消息队列表示为stream,是一个逻辑上的队列,消息生产者可以按需自定义一个消息队列。比如,一个用户与另一个用户在通过即时通讯工具聊天,则该用户可以创建一个消息队列,用于与这个用户之间聊天消息的存储。一个消息队列可以通过消息队列标识来与其他消息队列区分,一般地,可以通过名字(streamname)来标识一个消息队列,实际应用中,消息队列标识可以是多个字段拼接起来的值,比如用户标识+应用标识。一个消息队列可以是一个用户的聊天窗口,也可以是一个用户的收件箱,或者是一个用户的行为记录,等等。
比如,用户A在与用户B通过某即时通讯软件在聊天,那么对于用户A来说,可以创建其与用户B的聊天窗口对应的一个消息队列,消息队列中可以存储用户B发来的聊天消息。该消息队列标识可以是:stream_用户A名称+用户B名称。
消息队列中信息传递的载体称为消息,每个消息可以包括多个字段,比如消息队列标识、消息序列标识、消息体,等等。可以认为除消息体外的部分,被称为消息头,即消息头中包括消息队列标识、消息序列标识。
其中,消息体即为消息生产者所发布的消息内容,比如邮件内容、一条聊天内容。
其中,消息序列标识指示了相应消息体在消息队列中对应的序列号。消息序列标识是一个大于0的正整数。消息序列标识在一个消息队列内部是唯一的。本发明实施例中,会自动为一个消息队列中写入的消息分配一个消息序列标识,且先后产生的消息是顺序编号的,即一个消息队列标识下依次生成的消息序列标识是连续递增的,比如1/2/3/4……。
在一些实施例中,当希望消息队列具有幂等性时,消息中还可以包括幂等标识,用于保证消息写入重试时的幂等性。具有相同幂等标识的新消息,多次写入时,只有第一个消息会被写入,后续的写入动作不会实际发生写操作,而是可以返回第一次写入的消息的消息序列标识(对用户而言表示写入成功了)。幂等性的判断可以设有相应的时间窗口,比如1天,在这个时间窗口内,具有相同幂等标识的消息写入时才会进行幂等性检查。
综上,在本发明实施例提供的消息队列模型中,消息生产者可以按需创建一个消息队列,该消息队列中写入的消息被分配有连续单调递增的消息序列标识,以保证消息队列内消息的保序性,另外,还消息队列还支持幂等性检查操作。另外,为了支持用户(比如消息生产者、消息消费者)对消息队列中消息的各种操作,在该消息队列模型所基于的数据库系统中还可以设置有多个操作接口,以用于进行消息读写操作。比如如下读写接口:
Append接口:用于向stream中追加一条消息。
Update接口:用于删除一条旧消息,同时插入一条新消息。
Replace接口:用于更新一条消息的内容。
Delete接口:用于删除一条消息。
Get接口:用于根据消息序列标识获取一条消息。
BatchGet接口:用于批量获取消息。
getScanner接口:用于在某范围内查询消息。
GetStreamLatestId 接口:用于获取stream的最新消息序列标识。
以上对消息队列模型以及实现该消息队列模型所基于的数据库系统进行了简单介绍,下面对基于该数据库系统和消息队列模型执行的消息处理过程进行示例性说明。
图2为本发明实施例提供的一种消息处理方法的流程图,该方法应用于数据库系统中的某计算节点,如图2所示,该方法可以包括如下步骤:
201、计算节点接收消息生产者发送的消息写入请求,消息写入请求中包括消息队列标识和消息体。
202、计算节点根据消息队列标识下已经生成的消息序列标识,确定所述消息体对应的目标消息序列标识,其中,消息队列标识下生成的消息序列标识连续递增。
203、计算节点将消息队列标识、目标消息序列标识和消息体转换成第一存储引擎所需的数据格式,以使第一存储引擎通过调用云存储服务接口,以所述数据格式将消息队列标识、目标消息序列标识和消息体存储到云存储系统中;其中,第一存储引擎位于计算节点,计算节点与云存储系统相分离。
如上文所述,数据库系统可以使用分布式计算节点集群来通过计算服务,上述步骤中的计算节点可以是根据某些设定的调度规则确定出的某个计算节点,该调度规则比如为负载均衡算法,本实施例中对该调度过程不做具体限定。
如上文所述,在数据库系统中可以设置有多个与消息相关的操作接口,可以认为在各计算节点中都配置有这些操作接口。
消息生产者可以调用用于写入消息的操作接口,比如上述举例中的Append接口向数据库系统触发消息写入请求,数据库系统调度响应该请求的计算节点,以由该计算节点进行相关消息处理过程。其中,消息生产者需要在上述消息写入请求中携带已经设定好的消息队列标识以及消息数据内容(即消息体)。
具体地,计算节点可以通过其中运行的查询编译服务接收该消息写入请求,解析出其中包含的消息队列标识和消息体,确定是否已经存在该消息队列标识,如果不存在,说明是一个新建的消息队列标识,那么此时为该消息体分配的消息序列标识即为1,表示这个消息体对应于这个消息队列中的第一条消息;如果已经存在,说明此前已经创建了相应的消息队列,此时需要承接此前最后分配的消息序列标识,而分配新的消息序列标识给这个消息体,比如之前已经连续分配的消息序列标识为1/2/3,那么当前应该分配的是4。本实施例中将当前为该消息体分配的消息序列标识称为目标消息序列标识。
可以理解的是,上文中所说在一个消息队列内部,保证消息序列标识是连续递增的,并不要求不同的消息队列之间,消息序列标识是连续递增的。比如,消息队列1中消息序列标识从1开始顺序编号,消息队列2中消息序列标识也是从1开始顺序编号的。
之后,计算节点可以通过查询编译服务将消息队列标识、目标消息序列标识和消息体转换成第一存储引擎所需的数据格式,以使第一存储引擎通过调用云存储服务接口,以所述数据格式将消息队列标识、目标消息序列标识和消息体存储到云存储系统中。
如上文所述,每个计算节点中可以设有一种或多种存储引擎,为提高消息的查询能力,可以使用一种或多种存储引擎进行消息的存储。
这里假设各计算节点中都设有第一存储引擎,第一存储引擎比如可以为图1中示意的宽表引擎,每种存储引擎存储消息时所采用的数据格式是不同的,宽表引擎所采用的数据格式可以称为键值对格式。在上述消息写入请求的情形下,键(key)为消息队列标识和目标消息序列标识,值(value)为消息体。宽表引擎可以调用云存储服务接口,将当前生成的与消息写入请求对应的一个键值对提供给云存储系统,云存储系统进行相应的存储处理。
可选地,假设计算节点中还设有第二存储引擎,第二存储引擎比如为图1中示意的全文检索引擎,那么查询编译服务还会将消息队列标识、目标消息序列标识和消息体转换成第二存储引擎所需的数据格式,以使第二存储引擎通过调用云存储服务接口,以第二存储引擎所需的数据格式将消息队列标识、目标消息序列标识和消息体存储到云存储系统中。
这样,通过全文检索引擎对由消息队列标识、目标消息序列标识和消息体构成的一条消息的存储,可以实现全文检索能力。通过宽表引擎对由消息队列标识、目标消息序列标识和消息体构成的一条消息的键值对存储方式,可以实现键维度的检索。这样就实现了对消息的多维度检索。比如,假设一条消息的消息队列标识为stream_userX,消息序列标识为10,消息体为:今天天气如何。如果查询请求中携带的参数为stream_userX+10,即包括消息队列标识和消息序列标识,则可以通过宽表引擎以查询key的方式直接定位出这条消息,反馈对应的消息体内容。如果查询请求中携带的参数为“天气”,则通过分词检索,可以通过全文检索引擎检索出消息体中包括这个分词的各条消息。
在另一可选实施例中,如图3中所示,宽表引擎在收到查询编译服务以键值对的格式发送来的消息队列标识、目标消息序列标识和消息体后,可以先将这些信息写入日志文件(比如图中示意的LDLog)中,之后写入内存中,最终落盘到云存储系统中。同时,宽表引擎还可以将从日志文件中读取到的上述信息通过数据同步组件(LTS)写入到全文搜索引擎中,其中,在写入过程中,需要将这些信息转换成全文搜索引擎所需的格式。另外,可以采用异步增量索引、全量索引的方式完成写入。类似地,全文搜索引擎将收到的信息可以先写入本地的日志文件(比如图中示意的TLog)中,再落盘到云存储系统中。
综上,计算节点在接收到消息查询请求时,可以根据消息查询请求中包含的查询参数,确定与消息查询请求对应的目标存储引擎,以使目标存储引擎响应该消息查询请求,目标存储引擎可以是上文中的第一存储引擎或第二存储引擎。具体地,若查询参数包括所述消息队列标识和目标消息序列标识,则确定目标存储引擎为第一存储引擎;否则,确定目标存储引擎为第二存储引擎。
实际应用中,对于消息生产者来说,其发布的消息被通过上述处理过程写入到云存储系统中之后,可以由数据库系统将写入的消息推送到消息消费者,和/或,也可以由消息消费者从数据库系统中拉取消息。不管是推送方式还是拉取方式,都基于消息序列标识实现消息消费者对某消息队列中产生的消息的有序读取。具体地,在推送方式下,数据库系统(具体为计算节点)中维护有一个消息队列中产生的消息序列标识,假设此前最后向消息消费者推送了序列号为9的一条消息内容了,那么当前需要推送的消息所对应的消息序列标识即为序列号10。类似地,在拉取方式下,消息消费者中维护有一个消息队列下已经获取的各条消息的消息序列标识,如果发现最后拉取的消息所对应的消息序列标识为9,那么可以得知接下来需要拉取的是消息序列标识为10的消息。
由此可见,基于一个消息队列内容消息序列标识的连续递增特点,可以使得消息消费者准确得知是否存在消息读取失败、消息漏推送的情形。
为实现一个消息队列中消息序列标识的连续递增性,实际应用中,计算节点可以为每个消息队列维护有相应的一个序列标识控制器,以用于按照设定的配置产生连续递增的消息序列标识。该配置可以是一次产生一个,或者一次产生多个。另外,如上文所述,在考虑消息的幂等性时,计算节点还可以为每个消息队列维护有相应的一个幂等标识控制器,以用于进行幂等检查。
为便于理解,结合图4举例来说,在图4中,假设的是针对用户A、用户B和用户C的邮件收信箱分别创建了一个消息队列,用于存储向这三个用户分别发送的邮件。这三个消息队列可以由同一个计算节点维护,也可以由不同计算节点维护。如图4中所示,每个消息队列被关联有一个序列标识控制器和幂等标识控制器。消息队列中会存入有不同的消息,在本举例中,一个消息对应于一封邮件,消息头可以包括消息队列标识、消息序列标识和幂等标识,消息体即为邮件内容。
由上述举例可知,实际应用中,随着邮件服务器中使用用户的不断增加,可以按需为各个用户创建与之对应的消息队列,支持无限扩展消息队列的能力。而且,消息队列中写入的消息可以被永久存储在云存储系统中。
除了上述举例的场景为,本发明实施例提供的消息处理方法还可以适用于即时通讯场景中,以实现海量聊天消息的高效推送。
以即时通讯场景为例,即时通讯场景通常采用的是写扩散模型,一般会为每个用户准备一个消息接收队列,用于接收与其聊天的其他用户发送的聊天消息。假设用户A与用户B在聊天,针对用户A来说,为其创建一个消息队列,可以接收用户B发送的聊天消息,在该假设情形下,用户B通过客户端发出的聊天消息可以先由某个服务器S1(即时通讯服务器)接收,之后,服务器S1将该条聊天消息发布到数据库系统进行存储处理,数据库系统发现需要将这条聊天消息发送至用户A时,可以将聊天消息发送到服务器S2(即时通讯服务器),以通过服务器S2发送到用户A的客户端。在上述举例情形下,对于数据库系统来说,消息生产者是服务器S1,消息消费者是服务器S2。
当某消息生产者需要发布一条聊天消息时,向数据库系统触发包含消息队列标识和该聊天消息的消息写入请求,其中,假设消息队列标识为:stream_userA+userB。数据库系统调度计算资源中的计算节点Z来响应该消息写入请求,计算节点Z若发现数据库系统中已经存在该消息队列标识,则确定该消息队列标识下最后分配的消息序列标识是什么,假设为序号8,那么计算节点Z会分配序列9给这条聊天消息,进而生成如下KV对:key=[stream_userA+userB,9],value=聊天消息。 通过宽表引擎将上述KV对存入到云存储系统中。之后,如果需要向用户A推送这条聊天消息,基于已经推送出的最后一条消息对应的消息序列标识为8的已知信息,在云存储系统中查询key= [stream_userA+userB,9],得到对应的聊天消息,通过服务器S2发送至用户A。
综上,基于存储计算分离的数据库系统而实现的消息队列,继承了该数据库系统的优势,可以实现海量消息的永久存储,且在存储需要扩展时,可以仅扩展存储节点即可,实现低成本的扩容,基于多种存储引擎对消息的存储,还可以实现多维度的消息查询能力。
图5为本发明实施例提供的另一种消息处理方法的流程图,该方法应用于数据库系统中的某计算节点,如图5所示,该方法可以包括如下步骤:
501、计算节点接收消息生产者发送的消息写入请求,消息写入请求中包括消息队列标识、消息体和目标幂等标识。
502、计算节点确定消息队列标识下已写入的消息体所对应的幂等标识中是否存在目标幂等标识,若不存在,则执行步骤503。
503、计算节点根据消息队列标识下已经生成的消息序列标识,确定所述消息体对应的目标消息序列标识,其中,消息队列标识下生成的消息序列标识是连续递增的。
504、计算节点将消息队列标识、目标消息序列标识、目标幂等标识和消息体转换成第一存储引擎所需的数据格式,以使第一存储引擎通过调用云存储服务接口,以所述数据格式将消息队列标识、目标消息序列标识和消息体存储到云存储系统中。
如图5中所示,如果确定存在目标幂等标识,则可以返回第一次生成的与目标幂等标识对应的消息序列标识,表示这条消息此前已经写入了。
本实施例中,目标幂等标识是消息生产者生成的,比如通过对消息体进行某些设定的摘要算法、数字签名算法得到一个标识作为幂等标识。幂等标识全局唯一,用于唯一地标识一个消息体。
计算节点在接收到包含消息队列标识、消息体和目标幂等标识的消息写入请求后,首先可以基于目标幂等标识进行消息的幂等性检查。即检查这个消息队列标识下是否已经写入过这个目标幂等标识,如果已经写入过,说明当前请求写入的消息体是重复写入的,当前不应进行写入操作,返回第一次写入该消息体时所分配的消息序列标识。如果没有写入过该目标幂等标识,说明是一个新的需要写入的消息体,进行相应消息序列标识的分配。
本实施例中假设第一存储引擎为宽表引擎,与其对应的数据格式为键值对格式。此时,将消息队列标识、目标消息序列标识、目标幂等标识和消息体转换成第一存储引擎所需的数据格式,具体可以实现为:
生成第一键值对,第一键值对中的键为消息队列标识和目标消息序列标识,值为消息体;
生成第二键值对,第二键值对中的键为消息队列标识和目标消息序列标识,值为目标幂等标识;
生成第三键值对,第三键值对中的键为消息队列标识和目标幂等标识,值为目标消息序列标识。
宽表引擎将生成的上述三组键值对发送到云存储系统进行存储。上述三组键值对为用户提供了三种维度的查询能力,如:基于消息队列标识和目标消息序列标识查询消息体;基于消息队列标识和目标消息序列标识查询目标幂等标识;基于消息队列标识和目标幂等标识查询目标消息序列标识。
可以理解的是,在进行幂等检查过程中,会使用到上述第三键值对。比如,假设第三键值对中的消息队列标识和目标幂等标识分别表示为:stream_Y,idem_K,并假设后续消息生产者又触发了一个消息写入请求,该消息写入请求中包含的消息队列标识和目标幂等标识分别为stream_Y,idem_K,则通过查询到上述第三键值对可以得知已经存在该目标幂等标识,确定本次写入操作是重复写入操作,不进行写入处理。
本实施例中未详细介绍的其他步骤的执行过程可以参考前述其他实施例中的相关说明,在此不赘述。
需要说明的是,本发明实施例提供的方案中,存储系统不限于云端的云存储系统,比如也可以在本地物理机上实现本地存储,任何提供存储服务的基础设施均可以。
以下将详细描述本发明的一个或多个实施例的消息处理装置。本领域技术人员可以理解,这些装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。
图6为本发明实施例提供的一种消息处理装置的结构示意图,该装置位于数据库系统中的计算节点,如图6所示,该装置包括:接收模块11、确定模块12、存储模块13。
接收模块11,用于接收消息生产者发送的消息写入请求,所述消息写入请求中包括消息队列标识和消息体。
确定模块12,用于根据所述消息队列标识下已经生成的消息序列标识,确定所述消息体对应的目标消息序列标识,其中,所述消息队列标识下生成的消息序列标识是连续递增的。
存储模块13,用于将所述消息队列标识、所述目标消息序列标识和所述消息体转换成第一存储引擎所需的数据格式,以使所述第一存储引擎通过调用云存储服务接口,以所述数据格式将所述消息队列标识、所述目标消息序列标识和所述消息体存储到云存储系统中;其中,所述第一存储引擎位于所述计算节点,所述计算节点与所述云存储系统相分离。
可选地,所述第一存储引擎包括宽表引擎,所述数据格式为键值对格式,其中,键为所述消息队列标识和所述目标消息序列标识,值为所述消息体。
可选地,所述消息写入请求中包括目标幂等标识,此时,所述确定模块12具体用于:若确定所述消息队列标识下已写入的消息体所对应的幂等标识中不存在所述目标幂等标识,则根据所述消息队列标识下已经生成的消息序列标识,确定所述消息体对应的目标消息序列标识。所述存储模块13具体用于:将所述消息队列标识、所述目标消息序列标识、所述目标幂等标识和所述消息体转换成第一存储引擎所需的数据格式,以使所述第一存储引擎通过调用云存储服务接口,以所述数据格式将所述消息队列标识、所述目标消息序列标识和所述消息体存储到云存储系统中。
其中,可选地,所述第一存储引擎包括宽表引擎,所述数据格式为键值对格式;所述存储模块13具体用于:生成第一键值对,所述第一键值对中的键为所述消息队列标识和所述目标消息序列标识,值为所述消息体;生成第二键值对,所述第二键值对中的键为所述消息队列标识和所述目标消息序列标识,值为所述目标幂等标识;生成第三键值对,所述第三键值对中的键为所述消息队列标识和所述目标幂等标识,值为所述目标消息序列标识。
可选地,所述计算节点中设有多个操作接口,以用于进行消息读写操作。
可选地,所述存储模块13还用于:将所述消息队列标识、所述目标消息序列标识和所述消息体转换成第二存储引擎所需的数据格式,以使所述第二存储引擎通过调用所述云存储服务接口,以所述第二存储引擎所需的数据格式将所述消息队列标识、所述目标消息序列标识和所述消息体存储到所述云存储系统中。
其中,可选地,所述第二存储引擎包括全文搜索引擎。
可选地,所述装置还包括:查询模块,用于接收消息查询请求;根据所述消息查询请求中包含的查询参数,确定与所述消息查询请求对应的目标存储引擎,以使所述目标存储引擎响应所述消息查询请求,所述目标存储引擎为所述第一存储引擎或所述第二存储引擎。
其中,所述查询模块具体可以用于:若所述查询参数包括所述消息队列标识和所述目标消息序列标识,则确定所述目标存储引擎为所述第一存储引擎;否则,确定所述目标存储引擎为所述第二存储引擎。
图6所示装置可以执行前述实施例中计算节点执行的步骤,详细的执行过程和技术效果参见前述实施例中的描述,在此不再赘述。
在一个可能的设计中,上述图6所示消息处理装置的结构可实现为一计算设备,如图7所示,该计算设备可以包括:处理器21、存储器22、通信接口23。其中,存储器22上存储有可执行代码,当所述可执行代码被处理器21执行时,使处理器21至少可以实现如前述实施例中计算节点执行的消息处理方法。
另外,本发明实施例提供了一种非暂时性机器可读存储介质,所述非暂时性机器可读存储介质上存储有可执行代码,当所述可执行代码被计算设备的处理器执行时,使所述处理器至少可以实现如前述实施例中提供的消息处理方法。
以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现,当然也可以通过硬件和软件结合的方式来实现。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。