直播业务中消息服务的方法与系统技术方案

本申请提供一种直播业务中消息服务的方法与系统。所述方法包括：服务端根据客户端发送的请求参数，获取所处集群信息；根据所述集群信息向所述客户端返回两个集群地址；通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据。所述系统包括服务端和客户端。所述系统包括服务端和客户端。所述系统包括服务端和客户端。

【技术实现步骤摘要】
直播业务中消息服务的方法与系统


[0001]本申请涉及通信技术应用领域，具体而言，涉及一种直播业务中消息服务的方法与系统。

技术介绍

[0002]随着近几年直播行业的快速兴起，用户数也不断增加。企业直播已经成为企业营销及其他商业应用的一种重要形式，包括医疗、教育、金融等多个行业。而在直播过程中，消息发送与接收作为串联直播业务的重要工具，必不可少。因此，设计一套可支持直播高并发场景下的消息服务就显得尤为重要。
[0003]但是，传统的采用超文本预处理器（PHP，Hypertext Preprocessor）语言来实现消息服务，在性能方面不能满足日益增长的直播需求，在资源浪费方面也很严重。
[0004]在所述
技术介绍
部分公开的上述信息仅用于加强对本申请的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现思路

[0005]为了解决上述问题，本申请提出一种直播业务中消息服务的方法与系统。
[0006]根据本申请的第一方面，提出一种直播业务中消息服务的方法，用于服务端，包括：根据客户端发送的请求参数，获取所处集群信息；根据所述集群信息向所述客户端返回两个集群地址；通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据。
[0007]根据一些实施例，所述消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
[0008]根据一些实施例，所述两个集群地址包括第一主地址和第二主地址，所述通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据，包括：基于所述第一主地址建立的长连接，按照第一类型消息发送方式发送消息类型为所述房间消息和所述自定义消息的消息；基于所述第二主地址建立的长连接，按照第二类型消息发送方式发送消息类型为所述聊天消息与所述上下线消息的消息。
[0009]根据一些实施例，在按照所述第一类型消息发送方式发送消息的情况下，所述服务端包括提供长连接服务的第一服务端和提供所述消息服务的第二服务端，其中：所述第一服务端为订阅方，所述第二服务端为发布方；所述第二服务端接收发送消息请求，发送消息；所述第一服务端与所述第二服务端使用同一套存储系统进行通讯，接收消息。
[0010]根据一些实施例，所述订阅方与所述发布方通过发射器进行消息发送，通过适配器进行消息的订阅。
[0011]根据一些实施例，在按照所述第二类型消息发送方式发送消息的情况下，所述客户端为订阅方，所述服务端为发布方；在所述服务端接收到所述客户端发送的发送消息的请求的情况下，采用短连接的请求方式，发送消息。
[0012]根据本申请的第二方面，提出一种直播业务中消息服务的方法，用于客户端，包括：发送参数请求；获取服务端根据所述参数请求返回的两个集群地址；根据所述两个集群地址分别建立两个长连接；根据所述两个长连接分别获取所述服务端发送的不同消息类型的消息数据。
[0013]根据一些实施例，所述消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
[0014]根据一些实施例，所述两个集群地址包括第一主地址和第二主地址，所述根据所述两个长连接分别获取所述服务端发送的不同消息类型的消息数据，包括：基于所述第一主地址建立的长连接，按照第一类型消息接收方式接收消息类型为所述房间消息和所述自定义消息的消息；基于所述第二主地址建立的长连接，按照第二类型消息接收方式接收消息类型为所述聊天消息与所述上下线消息的消息。
[0015]根据本申请的第三方面，提出一种直播业务中消息服务的系统，包括：服务端，用于执行如第一方面中任一项所述的方法；客户端，用于执行如第二方面中任一项所述的方法。
[0016]本申请提出一种直播业务中消息服务的方法与系统，消息服务在方案上进行合理的分层及分包设计，根据不同消息类型采用不同的长连接服务来进行消息分发，使业务使用更加合理化；通过引入RocketMQ消息中间件来进行消息异步分发，在高并发场景下能有效的降低消息的延迟率，并且通过其应用解耦、流量削峰的优点，使系统的整体性能得到更好的提升。
[0017]本申请提出一种直播业务中消息服务的方法与系统，在架构设计上，根据业务的不同需求进行合理的定向扩展，通过采用业务处理+数据处理分层的模式，在服务部署时可以更合理的规划不同服务的部署节点数，从而使各服务的利用率达到最大化以及最合理化，这样在企业直播行业里能更好的降低企业的服务部署成本。并且，该方案在实施过程中，因为本身服务间及服务内不同的分层设计，根据业务使用情况来定义服务初始部署节点，后期在消息业务增长或下降的场景下，可以根据业务增长情况进行扩容、缩容且保持成本最优；在应对不同业务需求上，其扩展性及可复用性都比传统模式的表现更突出，后期的服务可维护性更强。应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。
附图说明
[0018]通过参照附图详细描述其示例实施例，本申请的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本申请的一些实施例，而不是对本申请的限制。
[0019]图1示出一示例性实施例的直播业务中消息服务的方法流程图；图2示出一示例性实施例的直播业务中消息服务的系统示意图；图3示出一示例性实施例的直播业务中消息服务的整体架构示意图；图4示出一示例性实施例的连接建立与发送消息时序图。
具体实施方式
[0020]现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本申请将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
[0021]所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有这些特定细节中的一个或更多，或者可以采用其它的方式、组元、材料、装置等。在这些情况下，将不详细示出或描述公知结构、方法、装置、实现、材料或者操作。
[0022]附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
[0023]本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。
[00本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种直播业务中消息服务的方法，其特征在于，用于服务端，包括：根据客户端发送的请求参数，获取所处集群信息；根据所述集群信息向所述客户端返回两个集群地址；通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据。2.如权利要求1所述的直播业务中消息服务的方法，其特征在于，所述消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。3.如权利要求2所述的直播业务中消息服务的方法，其特征在于，所述两个集群地址包括第一主地址和第二主地址，所述通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据，包括：基于所述第一主地址建立的长连接，按照第一类型消息发送方式发送消息类型为所述房间消息和所述自定义消息的消息；基于所述第二主地址建立的长连接，按照第二类型消息发送方式发送消息类型为所述聊天消息与所述上下线消息的消息。4.如权利要求3所述的直播业务中消息服务的方法，其特征在于，在按照所述第一类型消息发送方式发送消息的情况下，所述服务端包括提供长连接服务的第一服务端和提供所述消息服务的第二服务端，其中：所述第一服务端为订阅方，所述第二服务端为发布方；所述第二服务端接收发送消息请求，发送消息；所述第一服务端与所述第二服务端使用同一套存储系统进行通讯，接收消息。5.如权利要求4所述的直播业务中消息服务的方法，其特征在于，所述订阅方与所述发布方通过发射器进行消息发送，...

【专利技术属性】
技术研发人员：袁增辉，
申请(专利权)人：北京微吼时代科技有限公司，
类型：发明
国别省市：