CN110572331B - 消息处理方法及其系统 - Google Patents

消息处理方法及其系统 Download PDF

Info

Publication number
CN110572331B
CN110572331B CN201810577458.1A CN201810577458A CN110572331B CN 110572331 B CN110572331 B CN 110572331B CN 201810577458 A CN201810577458 A CN 201810577458A CN 110572331 B CN110572331 B CN 110572331B
Authority
CN
China
Prior art keywords
channel
client
message
service data
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810577458.1A
Other languages
English (en)
Other versions
CN110572331A (zh
Inventor
刘绪超
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Qianshi Technology Co Ltd
Original Assignee
Beijing Jingdong Qianshi Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Qianshi Technology Co Ltd filed Critical Beijing Jingdong Qianshi Technology Co Ltd
Priority to CN201810577458.1A priority Critical patent/CN110572331B/zh
Publication of CN110572331A publication Critical patent/CN110572331A/zh
Application granted granted Critical
Publication of CN110572331B publication Critical patent/CN110572331B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/125Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本公开提供了一种消息处理方法,应用于消息通道,消息通道能够为多个客户端接收并下发业务数据,多个客户端包括第一客户端和至少一个第二客户端,该方法包括:若第一客户端使消息通道出现数据积压,则启用第一备用通道和第二备用通道;将消息通道中积压的需下发给第一客户端的业务数据分流到第一备用通道中;以及将消息通道中积压的需下发给至少一个第二客户端的业务数据分流到第二备用通道中。本公开还提供了一种消息处理系统,一种计算机系统和一种计算机可读存储介质。

Description

消息处理方法及其系统
技术领域
本公开涉及计算机技术领域,更具体地,涉及一种消息处理方法及其系统、计算机系统和计算机可读存储介质。
背景技术
一般地,上游互联网运营主体与下游仓库之间存在很多业务往来,因此可以按业务(订单、商品资料或站点信息等)拆分通道,即不同的业务使用不同的消息通道下发或者上传消息。由于交易活跃期间上游互联网运营主体需要下发大量数据,因此,一旦某个仓库出现网络问题,会直接导致所有仓库都出现业务积压。
如图1所示,仓库1,仓库2,仓库3,……的订单信息都通过通道1下发,它们的商品资料都通过通道2下发,它们的站点信息都通过通道3下发,……,若仓库1由于网络或其他原因导致通道1消费缓慢,则仓库2,仓库3,……由于与仓库1使用同一个通道,因此也会随之消费缓慢,使得时效性大大降低。
针对上述问题,相关技术提供了一种解决方案:如图2所示,当发现通道1发生业务积压,或者发现仓库1出现网络问题时,将之后新下发的业务数据拆分到通道2中消费。
然而,在实现本公开构思的过程中,发明人发现相关技术中至少存在如下问题:当仓库1由于网络问题导致通道1出现业务积压时,将其他仓库的后续业务数据放到通道2中消费,只能达到不影响其他仓库的接单效果,但是通道1中的积压并没有解决,仍然消费缓慢。
发明内容
有鉴于此,本公开提供了一种消息处理方法及其系统。
本公开的一个方面提供了一种消息处理方法,应用于消息通道,上述消息通道能够为多个客户端接收并下发业务数据,上述多个客户端包括第一客户端和至少一个第二客户端,上述方法包括:若上述第一客户端使上述消息通道出现数据积压,则启用第一备用通道和第二备用通道;将上述消息通道中积压的需下发给上述第一客户端的业务数据分流到上述第一备用通道中;以及将上述消息通道中积压的需下发给上述至少一个第二客户端的业务数据分流到上述第二备用通道中。
根据本公开的实施例,上述方法还包括:启用第三备用通道;以及在第一时刻之后,通过上述第三备用通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述方法还包括,在第一时刻之后:通过上述第一备用通道为上述第一客户端接收并下发业务数据;或者通过上述消息通道为上述第一客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述方法还包括:若在上述第一时刻之后,通过上述第一备用通道为上述第一客户端接收并下发业务数据,则在将上述消息通道中积压的需下发给上述第一客户端的业务数据全部分流到上述第一备用通道中后,将上述消息通道和上述第二备用通道合并为一个通道。
根据本公开的实施例,上述方法还包括,在第一时刻之后:通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据;或者通过上述消息通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述方法还包括:若在上述第一时刻之后,通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据,则在将上述消息通道中积压的需下发给上述至少一个第二客户端的业务数据全部分流到上述第二备用通道中后,将上述消息通道和上述第一备用通道合并为一个通道。
根据本公开的实施例,每个上述消息通道仅为上述多个客户端接收并下发一种业务数据。
根据本公开的实施例,每个上述消息通道可为上述多个客户端接收并下发多种业务数据。
本公开的另一个方面提供了一种消息处理系统,应用于消息通道,上述消息通道能够为多个客户端接收并下发业务数据,上述多个客户端包括第一客户端和至少一个第二客户端,上述系统包括:第一启动模块,用于在上述第一客户端使上述消息通道出现数据积压的情况下,启用第一备用通道和第二备用通道;第一分流模块,用于将上述消息通道中积压的需下发给上述第一客户端的业务数据分流到上述第一备用通道中;以及第二分流模块,用于将上述消息通道中积压的需下发给上述至少一个第二客户端的业务数据分流到上述第二备用通道中。
根据本公开的实施例,上述系统还包括:第二启动模块,用于在启用第三备用通道;以及第一收发模块,用于在第一时刻之后,通过上述第三备用通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述系统还包括:第二收发模块,用于在第一时刻之后,通过上述第一备用通道为上述第一客户端接收并下发业务数据;或者第三收发模块,用于在第一时刻之后,通过上述消息通道为上述第一客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述系统还包括:第一合并模块,用于在上述第一时刻之后,且通过上述第一备用通道为上述第一客户端接收并下发业务数据的情况下,在将上述消息通道中积压的需下发给上述第一客户端的业务数据全部分流到上述第一备用通道中后,将上述消息通道和上述第二备用通道合并为一个通道。
根据本公开的实施例,上述系统还包括:第四收发模块,用于在第一时刻之后,通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据;或者第五收发模块,用于在第一时刻之后,通过上述消息通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
根据本公开的实施例,上述系统还包括:第二合并模块,用于在上述第一时刻之后,且通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据的情况下,在将上述消息通道中积压的需下发给上述至少一个第二客户端的业务数据全部分流到上述第二备用通道中后,将上述消息通道和上述第一备用通道合并为一个通道。
根据本公开的实施例,每个上述消息通道仅为上述多个客户端接收并下发一种业务数据。
根据本公开的实施例,每个上述消息通道可为上述多个客户端接收并下发多种业务数据。
本公开的另一方面提供了一种计算机系统,包括:一个或多个处理器;存储器,用于存储一个或多个程序,其中,当上述一个或多个程序被上述一个或多个处理器执行时,使得上述一个或多个处理器实现如上所述的方法。
本公开的另一方面提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器实现如上所述的方法。
本公开的另一方面提供了一种计算机程序,所述计算机程序包括计算机可执行指令,所述指令在被执行时用于实现如上所述的方法。
根据本公开的实施例,可以至少部分地解决消息通道中长时间积压数据的技术问题,并因此可以实现疏导消息通道,防止其长时间积压的技术效果。
附图说明
通过以下参照附图对本公开实施例的描述,本公开的上述以及其他目的、特征和优点将更为清楚,在附图中:
图1示意性示出了一种相关技术实施例的实现消息处理的示意图;
图2示意性示出了另一种相关技术实施例的实现消息处理的示意图;
图3示意性示出了根据本公开实施例的消息处理方法及其系统的系统架构;
图4示意性示出了根据本公开实施例的消息处理方法的流程图;
图5示意性示出了根据本公开实施例的实现消息处理的示意图;
图6示意性示出了根据本公开实施例的消息处理系统的框图;以及
图7示意性示出了根据本公开实施例的适于实现消息处理方法及其系统的计算机系统的框图。
具体实施方式
以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。在下面的详细描述中,为便于解释,阐述了许多具体的细节以提供对本公开实施例的全面理解。然而,明显地,一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。本领域技术人员还应理解,实质上任意表示两个或更多可选项目的转折连词和/或短语,无论是在说明书、权利要求书还是附图中,都应被理解为给出了包括这些项目之一、这些项目任一方、或两个项目的可能性。例如,短语“A或B”应当被理解为包括“A”或“B”、或“A和B”的可能性。
本公开的实施例提供了一种消息处理方法以及能够应用该方法的消息处理系统。该方法包括若第一客户端使消息通道出现数据积压,则启用第一备用通道和第二备用通道;将消息通道中积压的需下发给第一客户端的业务数据分流到第一备用通道中;以及将消息通道中积压的需下发给至少一个第二客户端的业务数据分流到第二备用通道中。
图3示意性示出了根据本公开实施例的消息处理方法及其系统的系统架构。需要注意的是,图3所示仅为可以应用本公开实施例的系统架构的示例,以帮助本领域技术人员理解本公开的技术内容,但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
如图3所示,根据该实施例的系统架构100可以包括终端设备101、102、103,网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互,以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用,例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器,例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理,并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
需要说明的是,本公开实施例所提供的消息处理方法一般可以由服务器105执行。相应地,本公开实施例所提供的消息处理装置一般可以设置于服务器105中。本公开实施例所提供的消息处理方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地,本公开实施例所提供的消息处理装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。
应该理解,图3中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
图4示意性示出了根据本公开实施例的消息处理方法的流程图。
如图4所示,该方法应用于消息通道,该消息通道能够为多个客户端接收并下发业务数据,该多个客户端包括第一客户端和至少一个第二客户端,该方法包括:
在操作S401,若该第一客户端使该消息通道出现数据积压,则启用第一备用通道和第二备用通道;
在操作S402,将该消息通道中积压的需下发给该第一客户端的业务数据分流到该第一备用通道中;以及
在操作S403,将该消息通道中积压的需下发给该至少一个第二客户端的业务数据分流到该第二备用通道中。
在本公开实施例中,消息通道可以用于接收上游客户端的业务数据,并将其下发给下游客户端进行处理。其中,上游客户端可以是互联网运营实体的客户端,下游客户端可以是用于仓库管理的客户端。也可以正好相反,即上游客户端可以是用于仓库管理的客户端,下游客户端可以是互联网运营实体的客户端。
在本公开实施例中,使用消息通道接收上游数据并下发给下游时,由于下游的多个客户端共同使用一个消息通道传输一类业务数据,因而下游的任何一个客户端出现问题导致消息通道出现数据积压,都会影响到其他下游客户端。为了防止消息通道中长时间积压数据,影响其他下游客户端,本公开在该消息通道出现数据积压时,对该消息通道进行疏导和消息分流。具体地,启用两个备用消息通道,将积压数据中应该下发给问题客户端的业务数据分流到其中一个消息通道中,将积压数据中应该下发给其他非问题客户端的业务数据分流到其中另一个消息通道中,因而可以保证其他非问题客户端的业务数据不受问题客户端影响,得到及时处理,防止长时间积压。有效的解决了消息通道数据的积压,由于某一个仓网络或者其他原因引起的拥堵,只影响其本身,不会对其他没有故障的仓库造成下单不及时。
如图5所示,若仓库1由于网络故障或网络不畅,导致通道1中出现积压数据,为了避免通道1中的积压数据长时间得不到处理,可以启用两个备用通道即通道11和通道12,其中,通道11中单独存放属于仓库1的积压数据,通道12中单独存放属于除仓库1外其他仓库的积压数据,这样,受仓库1端网络的影响,通道11中的数据可能依然要长时间存在积压,但是由于其他仓库如仓库2-仓库4的积压数据不再受仓库1端的网络的影响,因而可以在短时间内消费掉。
其中,消息通道又称为消息队列,它是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。
下面结合具体实施例对图4所示的方法做进一步说明。
作为一种可选的实施例,上述方法还可以包括:启用第三备用通道;以及在第一时刻之后,通过上述第三备用通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
为了减轻消息通道的疏导和分流压力,在出现数据积压时,可以使用原消息通道继续接收一部分新产生的业务数据即属于下游的问题客户端的业务数据,而同时启用一个专门的备用通道来接收另一部分新产生的属于下游的非问题客户端的业务数据。即拆分(启用第三备用通道)和转移(启用第一备用通道和第二备用通道)一起,保证了数据的实效性,同时也增加了下发速度,并且节约了维护成本。
例如,如图5所示,在对通道1中的积压数据进行疏导和分流的同时,可以使用通道1继续接收上游客户端新产生的属于仓库1的业务数据或者直接使用通道11接收上游客户端新产生的属于仓库1的业务数据,同时启用通道2继续接收上游客户端新产生的属于除仓库1外其他仓库的业务数据,由于通道1只接收属于仓库1的业务数据或者根本就不再接收任何业务数据,因而可以减轻通道1的疏导和分流压力。优选地,可以直接使用通道11接收上游新产生的且属于仓库1的业务数据,这样待通道1中的积压数据全部分流完后,可以关闭通道1,从而可以节约一个消息通道。
如图5所示,采取的方案是:还是将原来的通道拆分,拆成通道1和通道2,在出现积压时,增加一个转移,将通道1中的积压数据经过按仓库1进行过滤,仓库1的业务数据放到通道11进行消费,剩下的放到通道12继续消费。这样通道数量没有增加多少,同时又维持了原有的业务优先级,并且还解决了已经积压的数据,同时还不会影响针对仓库2,仓库3等所下的订单。
需要说明的是,采用还是按原来的业务为通道进行拆分通道解决之后的积压,然后增加转移,使得之前已经积压的数据转移到另外一个无数据的消息通道中去消费,将由于网络不通的库房转移到另外一个消息通道中,从而只影响到这一个消息通道,也就是只会有这一个消息通道存在数据积压,其余的两个消息通道同时消费,也提高了下发速度。
作为一种可选的实施例,该方法还可以包括,在第一时刻之后:优选地,通过该第一备用通道为该第一客户端接收并下发业务数据;或者通过该消息通道为该第一客户端接收并下发业务数据,其中,该第一时刻为该消息通道出现数据积压的时刻或出现数据积压之后的时刻。
例如,如图5所示,在通道1由于仓库1端的网络问题而出现数据积压时,可以使用通道1继续接收上游客户端新产生的属于仓库1的业务数据,或者直接使用通道11接收上游客户端新产生的属于仓库1的业务数据,从而可以为新产生的且属于仓库1的业务数据提供多种通道接收和下发方式。优选地,可以直接使用通道11接收上游新产生的且属于仓库1的业务数据,这样待通道1中的积压数据全部分流完后,可以关闭通道1,从而可以节约一个消息通道。
作为一种可选的实施例,该方法还可以包括:若在该第一时刻之后,通过该第一备用通道为该第一客户端接收并下发业务数据,则在将该消息通道中积压的需下发给该第一客户端的业务数据全部分流到该第一备用通道中后,将该消息通道和该第二备用通道合并为一个通道。
例如,如图5所示,在通道1由于仓库1端的网络问题而出现数据积压时,如果直接使用通道11接收上游客户端新产生的属于仓库1的业务数据,那么待通道1中的积压数据分流完毕后,可以将通道1和通道12合二为一,同样可以达到节约一个消息通道的目的。
作为一种可选的实施例,该方法还可以包括,在第一时刻之后:通过该第二备用通道为该至少一个第二客户端接收并下发业务数据;或者通过该消息通道为该至少一个第二客户端接收并下发业务数据,其中,该第一时刻为该消息通道出现数据积压的时刻或出现数据积压之后的时刻。
例如,如图5所示,使用本公开实施例,无需启用通道2,而是继续使用通道1接收新产生的属于所有下游仓库的业务数据,只是需要一直使用通道11和通道12对通道1中的原先积压的和当前新接收的业务数据针对仓库进行分流。由于无需启用通道2,因而也可以达到节约一个消息通道的目的。
作为一种可选的实施例,该方法还可以包括:若在该第一时刻之后,通过该第二备用通道为该至少一个第二客户端接收并下发业务数据,则在将该消息通道中积压的需下发给该至少一个第二客户端的业务数据全部分流到该第二备用通道中后,将该消息通道和该第一备用通道合并为一个通道。
例如,如图5所示,使用本公开实施例,也无需启用通道2,而是继续使用通道1接收新产生的属于下游问题仓库的业务数据,而使用通道12接收新产生的属于下游其他非问题仓库的业务数据,待通道1只剩下属于下游问题仓库的业务数据时,将通道1和通道11合二为一,可以节约至少两个消息通道的目的。
作为一种可选的实施例,每个该消息通道仅为该多个客户端接收并下发一种(即一类)业务数据。
作为一种可选的实施例,每个该消息通道可为该多个客户端接收并下发多种(即多类)业务数据。
在本公开实施例中,一个消息通道可以仅用于对一类业务数据进行接收和下发,也可以用于对多类业务数据进行接收和下发,前者可以保证处理业务数据的优先级,但是需要启用一定数量的消息通道,导致浪费且难于管理,后者则虽然无法保证处理业务数据的优先级,但是启动的消息通道的数量较少,因而可以避免浪费且易于管理。其中,业务数据的类型包括:订单消息,商品消息,站点消息,等等,在此不做限定。
图6示意性示出了根据本公开实施例的消息处理系统的框图。
如图6所示,该消息处理系统600应用于消息通道,该消息通道能够为多个客户端接收并下发业务数据,该多个客户端包括第一客户端和至少一个第二客户端,该系统可以包括:第一启动模块601,第一分流模块602和第二分流模块603。其中:
第一启动模块601,用于在该第一客户端使该消息通道出现数据积压的情况下,启用第一备用通道和第二备用通道;
第一分流模块602,用于将该消息通道中积压的需下发给该第一客户端的业务数据分流到该第一备用通道中;以及
第二分流模块603,用于将该消息通道中积压的需下发给该至少一个第二客户端的业务数据分流到该第二备用通道中。
作为一种可选的实施例,上述系统还可以包括:第二启动模块,用于在启用第三备用通道;以及第一收发模块,用于在第一时刻之后,通过上述第三备用通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
作为一种可选的实施例,上述系统还可以包括:第二收发模块,用于在第一时刻之后,通过上述第一备用通道为上述第一客户端接收并下发业务数据;或者第三收发模块,用于在第一时刻之后,通过上述消息通道为上述第一客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
作为一种可选的实施例,上述系统还可以包括:第一合并模块,用于在上述第一时刻之后,且通过上述第一备用通道为上述第一客户端接收并下发业务数据的情况下,在将上述消息通道中积压的需下发给上述第一客户端的业务数据全部分流到上述第一备用通道中后,将上述消息通道和上述第二备用通道合并为一个通道。
作为一种可选的实施例,上述系统还可以包括:第四收发模块,用于在第一时刻之后,通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据;或者第五收发模块,用于在第一时刻之后,通过上述消息通道为上述至少一个第二客户端接收并下发业务数据,其中,上述第一时刻为上述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
作为一种可选的实施例,上述系统还可以包括:第二合并模块,用于在上述第一时刻之后,且通过上述第二备用通道为上述至少一个第二客户端接收并下发业务数据的情况下,在将上述消息通道中积压的需下发给上述至少一个第二客户端的业务数据全部分流到上述第二备用通道中后,将上述消息通道和上述第一备用通道合并为一个通道。
作为一种可选的实施例,每个上述消息通道仅为上述多个客户端接收并下发一种业务数据。
作为一种可选的实施例,每个上述消息通道可为上述多个客户端接收并下发多种业务数据。
需要说明的是,系统部分的实施例实现的功能以及达到的技术效果与方法部分的实施例对应相同或者类似,在此不再赘述。
本公开的另一方面提供了一种计算机系统,包括:一个或多个处理器;存储器,用于存储一个或多个程序,其中,当上述一个或多个程序被上述一个或多个处理器执行时,使得上述一个或多个处理器实现如上所述的方法。
本公开的另一方面提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器实现如上所述的方法。
根据本公开的实施例的模块中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块中的任意一个或多个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC),或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,根据本公开实施例的模块中的一个或多个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
例如,第一启动模块601,第一分流模块602和第二分流模块603中的任意多个可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本公开的实施例,第一启动模块601,第一分流模块602和第二分流模块603中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC),或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,第一启动模块601,第一分流模块602和第二分流模块603中的至少一个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
图7示意性示出了根据本公开实施例的适于实现消息处理方法及其系统的计算机系统的框图。图7示出的计算机系统仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图7所示,根据本公开实施例的计算机系统700包括处理器701,其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。处理器701例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(ASIC)),等等。处理器701还可以包括用于缓存用途的板载存储器。处理器701可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 703中,存储有计算机系统700操作所需的各种程序和数据。处理器701、ROM702以及RAM 703通过总线704彼此相连。处理器701通过执行ROM 702和/或RAM 703中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意,所述程序也可以存储在除ROM 702和RAM 703以外的一个或多个存储器中。处理器701也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例,计算机系统700还可以包括输入/输出(I/O)接口705,输入/输出(I/O)接口705也连接至总线704。计算机系统700还可以包括连接至I/O接口705的以下部件中的一项或多项:包括键盘、鼠标等的输入部分706;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707;包括硬盘等的存储部分708;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器710上,以便于从其上读出的计算机程序根据需要被安装入存储部分708。
根据本公开的实施例,根据本公开实施例的方法流程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分709从网络上被下载和安装,和/或从可拆卸介质711被安装。在该计算机程序被处理器701执行时,执行本公开实施例的系统中限定的上述功能。根据本公开的实施例,上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
本公开还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的;也可以是单独存在,而未装配入该设备/装置/系统中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被执行时,实现根据本公开实施例的方法。
根据本公开的实施例,计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、有线、光缆、射频信号等等,或者上述的任意合适的组合。
例如,根据本公开的实施例,计算机可读介质可以包括上文描述的ROM 702和/或RAM 703和/或ROM 702和RAM 703以外的一个或多个存储器。
附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时电可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
本领域技术人员可以理解,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合,即使这样的组合或结合没有明确记载于本公开中。特别地,在不脱离本公开精神和教导的情况下,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
以上对本公开的实施例进行了描述。但是,这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。尽管在以上分别描述了各实施例,但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。

Claims (18)

1.一种消息处理方法,应用于消息通道,所述消息通道能够为多个客户端接收并下发业务数据,所述多个客户端包括第一客户端和至少一个第二客户端,所述方法包括:
若所述第一客户端使所述消息通道出现数据积压,则启用第一备用通道和第二备用通道;
将所述消息通道中积压的需下发给所述第一客户端的业务数据分流到所述第一备用通道中;以及
将所述消息通道中积压的需下发给所述至少一个第二客户端的业务数据分流到所述第二备用通道中。
2.根据权利要求1所述的方法,其中,所述方法还包括:
启用第三备用通道;以及
在第一时刻之后,通过所述第三备用通道为所述至少一个第二客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
3.根据权利要求1所述的方法,其中,所述方法还包括,在第一时刻之后:
通过所述第一备用通道为所述第一客户端接收并下发业务数据;或者
通过所述消息通道为所述第一客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
4.根据权利要求3所述的方法,其中,所述方法还包括:
若在所述第一时刻之后,通过所述第一备用通道为所述第一客户端接收并下发业务数据,则在将所述消息通道中积压的需下发给所述第一客户端的业务数据全部分流到所述第一备用通道中后,将所述消息通道和所述第二备用通道合并为一个通道。
5.根据权利要求1所述的方法,其中,所述方法还包括,在第一时刻之后:
通过所述第二备用通道为所述至少一个第二客户端接收并下发业务数据;或者
通过所述消息通道为所述至少一个第二客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
6.根据权利要求5所述的方法,其中,所述方法还包括:
若在所述第一时刻之后,通过所述第二备用通道为所述至少一个第二客户端接收并下发业务数据,则在将所述消息通道中积压的需下发给所述至少一个第二客户端的业务数据全部分流到所述第二备用通道中后,将所述消息通道和所述第一备用通道合并为一个通道。
7.根据权利要求1至6中任一项所述的方法,其中,每个所述消息通道仅为所述多个客户端接收并下发一种业务数据。
8.根据权利要求1至6中任一项所述的方法,其中,每个所述消息通道可为所述多个客户端接收并下发多种业务数据。
9.一种消息处理系统,应用于消息通道,所述消息通道能够为多个客户端接收并下发业务数据,所述多个客户端包括第一客户端和至少一个第二客户端,所述系统包括:
第一启动模块,用于在所述第一客户端使所述消息通道出现数据积压的情况下,启用第一备用通道和第二备用通道;
第一分流模块,用于将所述消息通道中积压的需下发给所述第一客户端的业务数据分流到所述第一备用通道中;以及
第二分流模块,用于将所述消息通道中积压的需下发给所述至少一个第二客户端的业务数据分流到所述第二备用通道中。
10.根据权利要求9所述的系统,其中,所述系统还包括:
第二启动模块,用于在启用第三备用通道;以及
第一收发模块,用于在第一时刻之后,通过所述第三备用通道为所述至少一个第二客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
11.根据权利要求9所述的系统,其中,所述系统还包括:
第二收发模块,用于在第一时刻之后,通过所述第一备用通道为所述第一客户端接收并下发业务数据;或者
第三收发模块,用于在第一时刻之后,通过所述消息通道为所述第一客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
12.根据权利要求11所述的系统,其中,所述系统还包括:
第一合并模块,用于在所述第一时刻之后,且通过所述第一备用通道为所述第一客户端接收并下发业务数据的情况下,在将所述消息通道中积压的需下发给所述第一客户端的业务数据全部分流到所述第一备用通道中后,将所述消息通道和所述第二备用通道合并为一个通道。
13.根据权利要求9所述的系统,其中,所述系统还包括:
第四收发模块,用于在第一时刻之后,通过所述第二备用通道为所述至少一个第二客户端接收并下发业务数据;或者
第五收发模块,用于在第一时刻之后,通过所述消息通道为所述至少一个第二客户端接收并下发业务数据,
其中,所述第一时刻为所述消息通道出现数据积压的时刻或出现数据积压之后的时刻。
14.根据权利要求13所述的系统,其中,所述系统还包括:
第二合并模块,用于在所述第一时刻之后,且通过所述第二备用通道为所述至少一个第二客户端接收并下发业务数据的情况下,在将所述消息通道中积压的需下发给所述至少一个第二客户端的业务数据全部分流到所述第二备用通道中后,将所述消息通道和所述第一备用通道合并为一个通道。
15.根据权利要求9至14中任一项所述的系统,其中,每个所述消息通道仅为所述多个客户端接收并下发一种业务数据。
16.根据权利要求9至14中任一项所述的系统,其中,每个所述消息通道可为所述多个客户端接收并下发多种业务数据。
17.一种计算机系统,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序,
其中,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现权利要求1至8中任一项所述的方法。
18.一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器实现权利要求1至8中任一项所述的方法。
CN201810577458.1A 2018-06-06 2018-06-06 消息处理方法及其系统 Active CN110572331B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810577458.1A CN110572331B (zh) 2018-06-06 2018-06-06 消息处理方法及其系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810577458.1A CN110572331B (zh) 2018-06-06 2018-06-06 消息处理方法及其系统

Publications (2)

Publication Number Publication Date
CN110572331A CN110572331A (zh) 2019-12-13
CN110572331B true CN110572331B (zh) 2023-04-07

Family

ID=68771980

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810577458.1A Active CN110572331B (zh) 2018-06-06 2018-06-06 消息处理方法及其系统

Country Status (1)

Country Link
CN (1) CN110572331B (zh)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105594169A (zh) * 2013-11-07 2016-05-18 华为技术有限公司 用于流量分割的系统及方法
CN104363138A (zh) * 2014-11-14 2015-02-18 迈普通信技术股份有限公司 一种接口备份方法及设备
CN106789345B (zh) * 2017-01-20 2019-07-23 厦门集微科技有限公司 通道切换方法及装置
CN107197015B (zh) * 2017-05-23 2020-09-08 阿里巴巴集团控股有限公司 一种基于消息队列系统的消息处理方法和装置

Also Published As

Publication number Publication date
CN110572331A (zh) 2019-12-13

Similar Documents

Publication Publication Date Title
CN110888696A (zh) 页面展示方法及其系统、计算机系统及计算机可读介质
CN110019496B (zh) 数据读写方法和系统
CN111125107A (zh) 数据处理方法、装置、电子设备和介质
CN110874227A (zh) 实现于api网关的灰度发布的分流方法、系统和电子设备
CN112329049A (zh) 业务数据管理方法、装置、电子设备和介质
CN111258736A (zh) 信息处理方法、装置和电子设备
CN115170321A (zh) 批量交易数据的处理方法和装置
CN111478974A (zh) 网络连接方法及装置、电子设备和可读存储介质
CN112953769B (zh) 数据传输方法、装置、计算机系统及可读存储介质
CN113298387B (zh) 货物装卸分配方法、分配系统、电子设备及可读存储介质
US20190370293A1 (en) Method and apparatus for processing information
CN113132400B (zh) 业务处理方法、装置、计算机系统及存储介质
CN110968433A (zh) 信息处理方法、系统和电子设备
CN110572331B (zh) 消息处理方法及其系统
US11153399B2 (en) Facilitating inter-proxy communication via an existing protocol
CN114647499A (zh) 异步作业任务并发控制方法、装置、电子设备和存储介质
CN111580882B (zh) 应用程序启动方法、装置、计算机系统和介质
CN114793232A (zh) 业务处理方法、装置、电子设备及存储介质
CN112688982B (zh) 一种用户请求处理方法和装置
CN109976902B (zh) 任务处理方法、系统、电子设备及计算机可读介质
CN115250276A (zh) 分布式系统及数据处理的方法和装置
CN109992428B (zh) 数据处理方法及系统
CN111652691A (zh) 一种订单信息处理方法、装置和电子设备
CN111325621A (zh) 协议处理方法、装置、计算机系统和介质
CN115174588B (zh) 带宽控制方法、装置、设备、存储介质和程序产品

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20200519

Address after: Room A1905, 19th floor, No. 2 Building, 18 Kechuang 11th Street, Beijing Daxing District, Beijing

Applicant after: Beijing Jingdong Qianshi Technology Co.,Ltd.

Address before: 300457 1st floor, phase II, No.10, 4th Street, economic and Technological Development Zone, Binhai New Area, Tianjin

Applicant before: Tianjin Jingdong Shentuo Robot Technology Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant