CN106911766A - 一种消息传输方法 - Google Patents

一种消息传输方法 Download PDF

Info

Publication number
CN106911766A
CN106911766A CN201710050015.2A CN201710050015A CN106911766A CN 106911766 A CN106911766 A CN 106911766A CN 201710050015 A CN201710050015 A CN 201710050015A CN 106911766 A CN106911766 A CN 106911766A
Authority
CN
China
Prior art keywords
intermediate conveyor
message
conveyor passage
service message
passage
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.)
Pending
Application number
CN201710050015.2A
Other languages
English (en)
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 Si Tech Information Technology Co Ltd
Original Assignee
Beijing Si Tech Information 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 Si Tech Information Technology Co Ltd filed Critical Beijing Si Tech Information Technology Co Ltd
Priority to CN201710050015.2A priority Critical patent/CN106911766A/zh
Publication of CN106911766A publication Critical patent/CN106911766A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

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

Abstract

本发明涉及一种消息传输方法。该方法包括:向服务器发送请求消息,该请求消息用于与中间传输通道建立通信连接;接收服务器发送的与中间传输通道建立通信连接的指示信息;根据指示信息,与中间传输通道建立通信连接;并将服务消息写入至中间传输通道,以便消息发送系统从中间传输通道读取服务消息。服务消息暂时存储于中间传输通道中,而并非直接传输至消息发送系统,或者消息发送系统直接从消息运营系统读取,目的是为了当消息运营系统或者消息发送系统中任意一台主机发生故障时,消息运营系统已经产生的业务消息不会全部随之消失或者发生损坏,由此,暂时也不会影响业务的运行。

Description

一种消息传输方法
技术领域
本发明涉及计算机技术领域,尤其涉及一种消息传输方法。
背景技术
消息发送是指业务运营支撑系统在一定条件触发的情况下,通过短信、彩信、电子邮件和信函等方式,主动发送的旨在帮助客户更好的了解当前的通信消费、业务及服务状态,维护自身利益和权益的一系列免费告知服务。
其中,当前能够实现消息发送的技术途径主要包括以下几种:
第一种,接口表方式。
具体为,消息发送系统从业务运营支撑系统接口表中读取数据信息,其中数据信息包括用户的电话号码、用户名等个人信息,用户当前的通信消费情况以及当前所使用的通信业务等等。然后,消息发送系统获取数据信息后,将其通过短信、彩信、电子邮件和信函等方式发送至相应的客户。
第二种,webservice方式。
具体为,消息发送系统提供webservice接口,业务运行支撑系统可以调用该webservice接口,然后获取相应的数据信息,其中,数据信息同上文所述的数据信息所包含的内容相同。然后,消息发送系统获取数据信息后,将其通过短信、彩信、电子邮件和信函等方式发送至相应的客户。
第三种,文件方式。
具体为,消息发送系统提供文件接口,业务运营支撑系统通过文件接口将FTP消息文件发送至消息发送系统。其中,ftp消息文件中同样包含上文中所述的数据信息。然后,消息发送系统获取数据信息后,将其通过短信、彩信、电子邮件和信函等方式发送至相应的客户。
但是,上述消息发送系统从业务运营支撑系统获取数据信息的途径均存在一定的缺陷。例如,采用接口表方式。由于接口表方式属于消息发送系统单线程处理接口表,每秒最多处理1000条左右的数据信息。而如果业务运营商不停的产生新的数据信息,不断更新接口表。例如,接口表中的数据信息为10000条,那么消息发送系统则需要至少10s的时间处理完当前接口表中的数据。也即是当接口表中存在大量数据时,会造成数据处理延时。而且,因为每个接口表只会利用一套程序执行,那么当接口表线程异常时,则会造成故障。又或者,如果一台主机处理多个接口表时,如果主机发生故障,那么该主机所处理的多个接口表都将受到影响。即使采用备用主机,当当前处理接口表的主机发生故障,切换备用主机处理,因为双机切换时间较长,甚至是切换失败,同样会造成业务故障。
而webservice方式则是受限于webservice接口的通讯效率和xml保温的复杂性,导致接口接收效率过低。
文件接口实时性较差,那么同样会存在采用接口表方式时所出现的问题。
发明内容
本发明所要解决的技术问题是提供一种消息传输方法。
本发明解决上述技术问题的技术方案如下:
第一方面,本发明实施例提供了一种消息传输方法,该方法包括:
向服务器发送请求消息,该请求消息用于与中间传输通道建立通信连接;
接收服务器发送的与中间传输通道建立通信连接的指示信息;
根据指示信息,与中间传输通道建立通信连接;
并将服务消息写入至中间传输通道,以便消息发送系统从中间传输通道读取服务消息。
本发明的有益效果是:服务消息暂时存储于中间传输通道中,而并非直接传输至消息发送系统,或者消息发送系统直接从消息运营系统读取,目的是为了当消息运营系统或者消息发送系统中任意一台主机发生故障时,消息运营系统已经产生的业务消息不会全部随之消失或者发生损坏,由此,暂时也不会影响业务的运行。
进一步,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
采用上述进一步的方案的有益技术效果在于,每一个子通道仅存储一种类型的服务消息,可以使消息运营系统产生的消息能够有序的存储在中间传输通道中,便于消息发送系统从中间传输通道中读取消息。
进一步,根据指示信息,将服务消息发送至中间传输通道,包括:
根据服务消息的类型,将服务消息发送至中间传输通道中与服务消息类型对应的子通道。
采用上述进一步的技术方案的有益技术效果在于,与上一步的有益效果类似的,服务消息根据类型不同,有序的存储在不同的子通道中,有利于消息发送系统从对应的子通道中读取某一类型的服务消息。
进一步的,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
采用上述进一步的技术方案的有益技术效果在于:每一个中间传输通道都是相同的中间传输通道,且每一个中间传输通道都包括相同的子通道。也既是每一个中间传输通道执行的功能均是相同的,每个中间传输通道存储的服务消息均是同步的。当其中一个中间传输通道处于忙碌状态时,可以保证消息运营系统可以将服务数据加入至其他中间传输通道;或者,保证消息发送系统可以从其他中间传输通道读取服务消息。由此提高工作效率。
进一步的,当中间传输通道包括至少一个时,接收服务器发送的与中间传输通道建立通信连接的指示信息,具体包括:
接收服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,最优的中间传输通道为服务器确定的至少一个中间传输通道中当前承载负荷最少的中间传输通道。
采用上述进一步的技术方案的有益技术效果在于:当某一个中间传输通道处于“忙碌”状态时,服务器首先确定当前处于“闲”状态的中间传输通道,然后让消息运营系统和处于“闲”状态的中间传输通道建立连接,并将服务消息发送至该中间传输通道,由此提高工作效率。而因为每一个中间传输通道执行的功能相同,所存储的服务消息是同步的,所以,消息发送系统可以从任意一个中间传输通道读取该消息。由此,不会影响消息的传输。
第二方面,本发明实施例提供了一种消息传输方法,该方法包括:
向服务器发送请求消息,该请求消息用于与中间传输通道建立通信连接;
接收服务器发送的与中间传输通道建立通信连接的指示信息;
根据指示信息,与中间传输通道建立通信连接;
并从中间传输通道读取服务消息,其中,服务消息为消息运营系统发送至中间传输通道的消息。
上述方案的有益技术效果在于,服务消息暂时存储于中间传输通道中,而并非直接传输至消息发送系统,或者消息发送系统直接从消息运营系统读取,目的是为了当消息运营系统或者消息发送系统中任意一台主机发生故障时,消息运营系统已经产生的业务消息不会全部随之消失或者发生损坏,由此,暂时也不会影响业务的运行。
进一步的,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
采用上述进一步的方案的有益技术效果在于,每一个子通道仅存储一种类型的服务消息,可以使消息运营系统产生的消息能够有序的存储在中间传输通道中,便于消息发送系统从中间传输通道中读取消息。
进一步的,根据指示信息,从中间传输通道读取服务消息,包括:
根据服务消息的类型,从与服务消息类型对应的子通道中读取服务消息。
采用上述进一步的技术方案的有益技术效果在于,与上一步的有益效果类似的,服务消息根据类型不同,有序的存储在不同的子通道中,有利于消息发送系统从对应的子通道中读取某一类型的服务消息。
进一步的,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
采用上述进一步的技术方案的有益技术效果在于,每一个中间传输通道都是相同的中间传输通道,且每一个中间传输通道都包括相同的子通道。也既是每一个中间传输通道执行的功能均是相同的,每个中间传输通道存储的服务消息均是同步的。当其中一个中间传输通道处于忙碌状态时,可以保证消息运营系统可以将服务数据加入至其他中间传输通道;或者,保证消息发送系统可以从其他中间传输通道读取服务消息。由此提高工作效率。
进一步的,当中间传输通道包括至少一个时,接收服务器发送的与中间传输通道建立通信连接的指示信息包括:
接收服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,最优的中间传输通道为服务器确定的至少一个中间传输通道中当前承载负荷最少的中间传输通道。
采用上述进一步的技术方案的有益技术效果在于:当某一个中间传输通道处于“忙碌”状态时,服务器首先确定当前处于“闲”状态的中间传输通道,然后让消息发送系统和处于“闲”状态的中间传输通道建立连接,并从该中间传输通道读取服务消息,由此提高工作效率。而因为每一个中间传输通道执行的功能相同,所存储的服务消息是同步的,所以,消息发送系统可以从任意一个中间传输通道读取该消息。由此,不会影响消息的传输。
附图说明
图1为本发明实施例提供的一种消息传输方法流程示意图;
图2为本发明实施例提供的另一种消息传输方法流程示意图;
图3为本发明实施例提供的一种消息传输装置的结构示意图;
图4为本发明实施例提供的另一种消息传输装置的结构示意图。
具体实施方式
以下描述中,为了说明而不是为了限定,提出了诸如特定系统结构、接口、技术之类的具体细节,以便透切理解本发明。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中,省略对众所周知的装置、电路以及方法的详细说明,以免不必要的细节妨碍本发明的描述。
在本发明中,可以包括以下4类执行主体,消息运营系统、消息发送系统、中间传输通道和服务器。其中,消息运营系统可以包括多个,每一个消息运营系统产生的服务消息可以是相同的或者是不同的。例如,消息运营系统可以包括客户关系系统、客服系统、电子渠道系统以及账务计费系统等。而消息发送系统则只包括一个。中间传输通道可以理解为是一个中间件(或者仅仅是一个或者多个程序),主要用于缓存服务消息。而服务器可以是分布式功能的服务器。
图1为本发明实施例提供的一种消息传输方法流程示意图。如图1所示,该方法主要由消息运营系统执行,该方法包括以下步骤:
步骤110,向服务器发送请求消息。
具体的,该请求消息用于与中间传输通道建立通信连接。在该请求消息中,可以包括与服务消息对应的标识信息,例如该标识信息可以为服务消息的主题。而每一个消息的主题代表服务消息的一种类型。
在一种情况中,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
步骤120,接收服务器发送的中间传输通道建立通信连接的指示信息。
具体的,如步骤110中的,服务消息可以包括至少一种类型,而中间传输通道同样包括了至少一个子通道,且每一个子通道用于存储一种类型的服务消息。所以,服务器在接收到请求消息时,可以根据请求消息中的服务消息标识信息,确定消息的类型,然后根据消息类型,确定消息运营系统需要和中间传输通道中的哪一个子通道建立通信连接。并向消息运营系统发送指示信息,用于消息运营系统和该中间传输通道中的一个子通道建立通信连接。
在一种情况中,为了能够提高工作效率,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。也既是说,中间传输通道可以包括多个,而每一个中间传输通道可以执行相同的功能。即每一个中间传输通道接收消息运营系统传输的服务消息是同步的,也即是不论消息运营系统将服务消息发送至哪一个中间传输通道,其他中间传输通道中对应位置均会存储相同的服务消息。因此,服务器还需要确定消息运营系统需要和哪一个中间传输通道进行通信连接。而确定消息运营系统与最优的中间传输通道建立通信连接的准则是:最优的中间传输通道为当前承载负荷最少的中间传输通道。
步骤130,根据指示信息,与中间传输通道建立通信连接。
具体的,如步骤120中,当服务器确定消息运营系统需要和哪个消息中间传输通道中的一个子通道进行连接时,则向消息运营系统发送指示信息。消息运营系统根据指示信息,和“最优”的中间传输通道建立通信连接。,其中,建立连接的过程可以为:消息运营系统向“最优”的中间传输通道发送API调用接口,通过API调用接口,和“最优”的中间传输通道建立通信连接。
步骤140,将服务消息写入至中间传输通道。
具体的,当消息运营系统和“最优”的中间传输通道建立连接后,可以将服务消息写入至中间传输通道中。以便消息发送系统从中间传输通道读取服务消息。
读者应理解,中间传输通道只能暂时缓存服务消息,而不能够永久性的存储该服务消息。那么,为了避免消息发送系统不能够及时处理消息运行系统产生的大量服务消息,中间传输通道可以将大量的服务消息写入存储器中,其中存储器可以是一张或者多张磁盘。而当消息发送系统需要读取服务消息时,中间传输通道则从存储器中取出服务消息,以便消息发送系统读取该服务消息后,发送给用户。
进一步的,读者应理解,在消息发送系统中,可以包括多个程序,每一个程序用于处理一种类型的消息。这些程序可以存放于一台主机中。但是,为了避免一台主机发生损坏,而延误服务消息的处理。在消息发送系统中还可以备用多台主机,每一台主机均存有与当前正在使用的主机相同的程序,用于在当前正在使用的主机发生故障时,作为备选处理服务消息。又或者,这些主机可以同时投入使用,处理不同的服务消息,以提高工作效率。
进一步优选的,为了防止消息运行系统生产服务消息时,短时间内生产大量的同一类服务消息,那么一台主机中还可以包含处理该类服务消息的多个程序,同时进行处理。以此提高工作效率。
进一步的,上文中所说的服务器,同样可以包括多个,当消息运行系统需要和中间传输通道建立连接时,首先向服务器集群发送请求消息,服务器集群内部选出处理该请求消息的服务器,并且利用被选的服务器找到最优的中间传输通道,并向消息运营系统发送指示信息,以便消息运营系统和最优的中间传输通道建立通信连接。类似的,在下一时刻,消息运营系统需要和一个中间传输通道建立连接时,通过上述步骤,利用服务器集群中的一个服务器(此时是最空闲的服务器)确定当前时刻最优的中间传输通道,然后建立与当前时刻最优的中间传输通道之间的连接。
本发明实施例提供的一种消息传输方法,通过分布式的拓展中间传输通道、服务器集群以及消息发送系统所占用的主机等,避免了当消息发送系统中的一台主机损坏时,影响服务消息的处理进度的情况发生的同时,最大化的提升了工作效率。
图2为本发明实施例提供的另一种消息传输方法流程示意图。如图2所示,本实施例包括以下步骤:
步骤210,向服务器发送请求消息。
具体的,该请求消息用于与中间传输通道建立通信连接。在该请求消息中,可以包括与服务消息对应的标识信息,例如该标识信息可以为服务消息的主题。而每一个消息的主题代表服务消息的一种类型。
在一种情况中,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
步骤220,接收服务器发送的与中间传输通道建立通信连接的指示信息。
具体的,如步骤210中的,服务消息可以包括至少一种类型,而中间传输通道同样包括了至少一个子通道,且每一个子通道用于存储一种类型的服务消息。所以,服务器在接收到请求消息时,可以根据请求消息中的服务消息标识信息,确定消息的类型,然后根据消息类型,确定消息发送系统需要和中间传输通道中的哪一个子通道建立通信连接。并向消息发送系统发送指示信息,用于消息发送系统和该中间传输通道中的一个子通道建立通信连接。
在一种情况中,为了能够提高工作效率,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。也既是说,中间传输通道可以包括多个,而每一个中间传输通道可以执行相同的功能。即每一个中间传输通道中存储的服务消息是同步的,也即是不论消息发送系统读取的是哪一个中间传输通道内存储的服务消息,其内容均是相同的。因此,服务器还需要确定消息发送系统需要和哪一个中间传输通道进行通信连接。而确定消息发送系统与最优的中间传输通道建立通信连接的准则是:最优的中间传输通道为当前承载负荷最少的中间传输通道。
步骤230,根据指示信息,与中间传输通道建立通信连接。
具体的,如步骤220中,当服务器确定消息发送系统需要和哪个消息中间传输通道中的一个子通道进行连接时,则向消息发送系统发送指示信息。消息发送系统根据指示信息,和“最优”的中间传输通道建立通信连接。其中,建立连接的过程可以为:消息发送系统向“最优”的中间传输通道发送API调用接口,通过API调用接口,和“最优”的中间传输通道建立通信连接。
步骤240,从中间传输通道读取服务消息。
具体的,当消息发送系统和“最优”的中间传输通道建立连接后,可以从该中间传输通道中读取服务消息。
读者应理解,中间传输通道只能暂时缓存服务消息,而不能够永久性的存储该服务消息。那么,为了避免消息发送系统不能够及时处理消息运行系统产生的大量服务消息,中间传输通道可以将大量的服务消息写入存储器中,其中存储器可以是一张或者多张磁盘。而当消息发送系统需要读取服务消息时,中间传输通道则从存储器中取出服务消息,以便消息发送系统读取该服务消息后,发送给用户。
进一步的,读者应理解,在消息发送系统中,可以包括多个程序,每一个程序用于处理一种类型的消息。这些程序可以存放于一台主机中。但是,为了避免一台主机发生损坏,而延误服务消息的处理。在消息发送系统中还可以备用多台主机,每一台主机均存有与当前正在使用的主机相同的程序,用于在当前正在使用的主机发生故障时,作为备选处理服务消息。又或者,这些主机可以同时投入使用,处理不同的服务消息,以提高工作效率。
进一步优选的,为了防止消息运行系统生产服务消息时,短时间内生产大量的同一类服务消息,那么一台主机中还可以包含处理该类服务消息的多个程序,同时进行处理。以此提高工作效率。
进一步的,上文中所说的服务器,同样可以包括多个,在某一时刻,当消息发送系统需要和中间传输通道建立连接时,首先向服务器集群发送请求消息,服务器集群内部选出处理该请求消息的服务器,并且利用被选的服务器找到最优的中间传输通道,并向消息发送系统发送指示信息,以便消息发送系统和最优的中间传输通道建立通信连接。类似的,在下一时刻,消息发送系统需要和一个中间传输通道建立连接时,通过上述步骤,利用服务器集群中的一个服务器(此时是最空闲的服务器)确定当前时刻最优的中间传输通道,然后建立与当前时刻最优的中间传输通道之间的连接。
本发明实施例提供的另一种消息传输方法,通过分布式的拓展中间传输通道、服务器集群以及消息发送系统所占用的主机等,避免了当消息发送系统中的一台主机损坏时,影响服务消息的处理进度的情况发生的同时,最大化的提升了工作效率。
另外,读者还应理解的是,上述两种实施例中,消息运营系统和消息发送系统在与中间传输通道之间建立连接关系,以及进行消息写入或者读取时,并没有什么时序关系。消息运营系统和中间传输通道建立连接和写入数据等过程,与消息发送系统与中间传输通道建立连接关系和读取数据等过程分别是独立完成的。二者之间仅仅是建立连接的步骤相似,所使用的中间传输通道相同,读/写数据可能是相同的而已。读者不能理所当然的认为二者之间有什么具体的时序顺序。
相应地,本发明实施例还提供了一种消息传输装置。图3为本发明实施例提供的一种消息传输装置结构示意图。如图3所示,该装置包括以下单元:
发送单元301,接收单元302以及处理单元303。
发送单元301,用于向服务器发送请求消息。
具体的,请求消息用于与中间传输通道建立通信连接。
接收单元302,用于接收服务器发送的与中间传输通道建立通信连接的指示信息。
处理单元303,用于根据指示信息,与中间传输通道建立通信连接。
处理单元303还用于,将服务消息写入至中间传输通道,以便消息发送系统从中间传输通道读取服务消息。
具体的,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
处理单元303具体用于,根据服务消息的类型,将服务消息写入至中间传输通道中与服务消息类型对应的子通道。
在一种情况中,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
而当中间传输通道包括至少一个时,接收单元302具体用于,接收服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,最优的中间传输通道为服务器确定的至少一个中间传输通道中当前承载负荷最少的中间传输通道。
该消息传输装置中的各部件所执行的功能已经在上述实施例一种消息传输方法中做了详细的介绍,这里不再赘述。
本发明实施例提供的一种消息传输装置,通过分布式的拓展中间传输通道、服务器集群以及消息发送系统所占用的主机等,避免了当消息发送系统中的一台主机损坏时,影响服务消息的处理进度的情况发生的同时,最大化的提升了工作效率。
与上述实施例的另一种消息传输方法相对应的,本发明实施例还提供了另一种消息传输装置。具体如图4所示,图4为本发明实施例提供的另一种消息传输装置结构示意图。该装置包括以下单元:
发送单元401,用于向服务器发送请求消息。
具体的,请求消息用于与中间传输通道建立通信连接。
接收单元402,用于接收服务器发送的与中间传输通道建立通信连接的指示信息。
处理单元403,用于根据指示信息,与中间传输通道建立通信连接;并从中间传输通道读取服务消息,其中,服务消息为消息运营系统发送至中间传输通道的消息。
具体的,服务消息包括至少一种类型,中间传输通道包括至少一个子通道,且服务消息的种类数量与子通道数量相同,中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
处理单元403具体用于,根据服务消息的类型,从与服务消息类型对应的子通道中读取服务消息。
在一种情况中,中间传输通道包括至少一个,且至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
当中间传输通道包括至少一个时,接收单元402具体用于,接收服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,最优的中间传输通道为服务器确定的至少一个中间传输通道中当前承载负荷最少的中间传输通道。
该系统中各部件所执行的功能均已在上述另一种消息传输方法中做了详细介绍,这里不再赘述。
本发明实施例提供的另一种消息传输装置,通过分布式的拓展中间传输通道、服务器集群以及消息发送系统所占用的主机等,避免了当消息发送系统中的一台主机损坏时,影响服务消息的处理进度的情况发生的同时,最大化的提升了工作效率。
读者应理解,在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不必针对的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本发明的实施例,可以理解的是,上述实施例是示例性的,不能理解为对本发明的限制,本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种消息传输方法,其特征在于,所述方法包括:
向服务器发送请求消息,所述请求消息用于与中间传输通道建立通信连接;
接收所述服务器发送的与所述中间传输通道建立通信连接的指示信息;
根据所述指示信息,与所述中间传输通道建立通信连接;
并将服务消息写入至所述中间传输通道,以便消息发送系统从所述中间传输通道读取所述服务消息。
2.根据权利要求1所述的方法,其特征在于,所述服务消息包括至少一种类型,所述中间传输通道包括至少一个子通道,且所述服务消息的种类数量与所述子通道数量相同,所述中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
3.根据权利要求2所述的方法,其特征在于,所述根据所述指示信息,将服务消息发送至所述中间传输通道,包括:
根据所述服务消息的类型,将所述服务消息发送至所述中间传输通道中与所述服务消息类型对应的子通道。
4.根据权利要求1至3任一项所述的方法,其特征在于,所述中间传输通道包括至少一个,且所述至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
5.根据权利要求4所述的方法,其特征在于,当所述中间传输通道包括至少一个时,所述接收所述服务器发送的与所述中间传输通道建立通信连接的指示信息,具体包括:
接收所述服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,所述最优的中间传输通道为所述服务器确定的所述至少一个中间传输通道中当前承载负荷最少的中间传输通道。
6.一种消息传输方法,其特征在于,所述方法包括:
向服务器发送请求消息,所述请求消息用于与中间传输通道建立通信连接;
接收所述服务器发送的与所述中间传输通道建立通信连接的指示信息;
根据所述指示信息,与所述中间传输通道建立通信连接;
并从所述中间传输通道读取服务消息,其中,所述服务消息为消息运营系统发送至所述中间传输通道的消息。
7.根据权利要求6所述的方法,其特征在于,所述服务消息包括至少一种类型,所述中间传输通道包括至少一个子通道,且所述服务消息的种类数量与所述子通道数量相同,所述中间传输通道中每一个子通道用于存储且仅存储一种类型的服务消息。
8.根据权利要求7所述的方法,其特征在于,所述根据所述指示信息,从中间传输通道读取服务消息,包括:
根据所述服务消息的类型,从与所述服务消息类型对应的子通道中读取所述服务消息。
9.根据权利要求6至8任一项所述的方法,其特征在于,所述中间传输通道包括至少一个,且所述至少一个中间传输通道中每一个中间传输通道均包括相同的子通道。
10.根据权利要求9所述的方法,其特征在于,当所述中间传输通道包括至少一个时,接收所述服务器发送的与所述中间传输通道建立通信连接的指示信息包括:
接收所述服务器发送的与最优的中间传输通道建立通信连接的指示信息,其中,所述最优的中间传输通道为所述服务器确定的所述至少一个中间传输通道中当前承载负荷最少的中间传输通道。
CN201710050015.2A 2017-01-23 2017-01-23 一种消息传输方法 Pending CN106911766A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710050015.2A CN106911766A (zh) 2017-01-23 2017-01-23 一种消息传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710050015.2A CN106911766A (zh) 2017-01-23 2017-01-23 一种消息传输方法

Publications (1)

Publication Number Publication Date
CN106911766A true CN106911766A (zh) 2017-06-30

Family

ID=59207131

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710050015.2A Pending CN106911766A (zh) 2017-01-23 2017-01-23 一种消息传输方法

Country Status (1)

Country Link
CN (1) CN106911766A (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217558A (zh) * 2007-12-26 2008-07-09 中国移动通信集团湖北有限公司 一种业务中间件服务负载均衡方法
CN101442538A (zh) * 2008-11-19 2009-05-27 航旅信通(北京)信息技术有限公司 一种使用多种全球分销业务的方法、系统和中间服务器
CN102185902A (zh) * 2011-04-19 2011-09-14 北京神州数码思特奇信息技术股份有限公司 一种分布式管理系统及该系统实现业务负载均衡的方法
CN102377685A (zh) * 2010-08-06 2012-03-14 阿里巴巴集团控股有限公司 一种订阅消息的发送系统以及订阅消息的发送方法
CN102469033A (zh) * 2010-11-01 2012-05-23 阿里巴巴集团控股有限公司 一种消息订阅系统以及消息发送方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101217558A (zh) * 2007-12-26 2008-07-09 中国移动通信集团湖北有限公司 一种业务中间件服务负载均衡方法
CN101442538A (zh) * 2008-11-19 2009-05-27 航旅信通(北京)信息技术有限公司 一种使用多种全球分销业务的方法、系统和中间服务器
CN102377685A (zh) * 2010-08-06 2012-03-14 阿里巴巴集团控股有限公司 一种订阅消息的发送系统以及订阅消息的发送方法
CN102469033A (zh) * 2010-11-01 2012-05-23 阿里巴巴集团控股有限公司 一种消息订阅系统以及消息发送方法
CN102185902A (zh) * 2011-04-19 2011-09-14 北京神州数码思特奇信息技术股份有限公司 一种分布式管理系统及该系统实现业务负载均衡的方法

Similar Documents

Publication Publication Date Title
CN104239132B (zh) 一种唤醒对齐的方法、装置及终端
CN103701807B (zh) 一种vdi环境下的数据发送方法和装置
US20120258722A1 (en) Resource Allocation Method and Device for Foreground Switch of J2ME Application
CN101877604B (zh) 一种传输文件的方法及系统
KR20120076859A (ko) 휴대단말에서 킵 얼라이브 패킷 동기화 방법 및 장치
CN101520792A (zh) 一种自动挂载与识别系统文件的方法及其系统
CN102196033B (zh) 一种传送和接收远程呈现数据的方法和系统
CN104216835A (zh) 一种实现内存融合的方法及装置
CN106936896A (zh) Kafka集群的数据传送方法和装置
CN101977410A (zh) 一种双网双待终端进行通讯的方法和装置
CN103338144A (zh) 一种会话数据同步方法和装置
CN113703954A (zh) 一种消息备份方法、装置、电子设备及计算机存储介质
CN107454171A (zh) 消息服务系统及其实现方法
CN102510407A (zh) 一种对博客进行读、写操作的方法及系统
CN106162577A (zh) 一种消息推送方法,及消息推送设备
CN108600294A (zh) 一种云终端屏幕共享系统及方法
CN205283611U (zh) 一种将移动端和服务器端消息信息进行同步的装置
CN105808324A (zh) 一种提高系统流畅度的方法及移动终端
CN106911766A (zh) 一种消息传输方法
CN103209255B (zh) 移动终端网络游戏系统
CN110889765B (zh) 交易信息报送方法及装置
CN112543374A (zh) 一种转码控制方法、装置及电子设备
CN112702146B (zh) 数据处理方法及设备
CN110333973B (zh) 一种多机热备的方法和系统
CN105676989A (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
RJ01 Rejection of invention patent application after publication

Application publication date: 20170630

RJ01 Rejection of invention patent application after publication