直播业务中消息服务的方法与系统与流程

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


背景技术：

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


技术实现要素：

5.为了解决上述问题，本技术提出一种直播业务中消息服务的方法与系统。
6.根据本技术的第一方面，提出一种直播业务中消息服务的方法，用于服务端，包括：根据客户端发送的请求参数，获取所处集群信息；根据所述集群信息向所述客户端返回两个集群地址；通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据。
7.根据一些实施例，所述消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
8.根据一些实施例，所述两个集群地址包括第一主地址和第二主地址，所述通过所述客户端分别与所述两个集群地址建立两个长连接，经由所述两个长连接发送不同消息类型的消息数据，包括：基于所述第一主地址建立的长连接，按照第一类型消息发送方式发送消息类型为所述房间消息和所述自定义消息的消息；基于所述第二主地址建立的长连接，按照第二类型消息发送方式发送消息类型为所述聊天消息与所述上下线消息的消息。
9.根据一些实施例，在按照所述第一类型消息发送方式发送消息的情况下，所述服务端包括提供长连接服务的第一服务端和提供所述消息服务的第二服务端，其中：所述第一服务端为订阅方，所述第二服务端为发布方；所述第二服务端接收发送消息请求，发送消息；所述第一服务端与所述第二服务端使用同一套存储系统进行通讯，接收消息。
10.根据一些实施例，所述订阅方与所述发布方通过发射器进行消息发送，通过适配器进行消息的订阅。
11.根据一些实施例，在按照所述第二类型消息发送方式发送消息的情况下，所述客户端为订阅方，所述服务端为发布方；在所述服务端接收到所述客户端发送的发送消息的请求的情况下，采用短连接的请求方式，发送消息。
12.根据本技术的第二方面，提出一种直播业务中消息服务的方法，用于客户端，包括：发送参数请求；获取服务端根据所述参数请求返回的两个集群地址；根据所述两个集群地址分别建立两个长连接；根据所述两个长连接分别获取所述服务端发送的不同消息类型的消息数据。
13.根据一些实施例，所述消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
14.根据一些实施例，所述两个集群地址包括第一主地址和第二主地址，所述根据所述两个长连接分别获取所述服务端发送的不同消息类型的消息数据，包括：基于所述第一主地址建立的长连接，按照第一类型消息接收方式接收消息类型为所述房间消息和所述自定义消息的消息；基于所述第二主地址建立的长连接，按照第二类型消息接收方式接收消息类型为所述聊天消息与所述上下线消息的消息。
15.根据本技术的第三方面，提出一种直播业务中消息服务的系统，包括：服务端，用于执行如第一方面中任一项所述的方法；客户端，用于执行如第二方面中任一项所述的方法。
16.本技术提出一种直播业务中消息服务的方法与系统，消息服务在方案上进行合理的分层及分包设计，根据不同消息类型采用不同的长连接服务来进行消息分发，使业务使用更加合理化；通过引入rocketmq消息中间件来进行消息异步分发，在高并发场景下能有效的降低消息的延迟率，并且通过其应用解耦、流量削峰的优点，使系统的整体性能得到更好的提升。
17.本技术提出一种直播业务中消息服务的方法与系统，在架构设计上，根据业务的不同需求进行合理的定向扩展，通过采用业务处理+数据处理分层的模式，在服务部署时可以更合理的规划不同服务的部署节点数，从而使各服务的利用率达到最大化以及最合理化，这样在企业直播行业里能更好的降低企业的服务部署成本。并且，该方案在实施过程中，因为本身服务间及服务内不同的分层设计，根据业务使用情况来定义服务初始部署节点，后期在消息业务增长或下降的场景下，可以根据业务增长情况进行扩容、缩容且保持成本最优；在应对不同业务需求上，其扩展性及可复用性都比传统模式的表现更突出，后期的服务可维护性更强。应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本技术。
附图说明
18.通过参照附图详细描述其示例实施例，本技术的上述和其它目标、特征及优点将变得更加显而易见。下面描述的附图仅仅是本技术的一些实施例，而不是对本技术的限制。
19.图1示出一示例性实施例的直播业务中消息服务的方法流程图；图2示出一示例性实施例的直播业务中消息服务的系统示意图；图3示出一示例性实施例的直播业务中消息服务的整体架构示意图；图4示出一示例性实施例的连接建立与发送消息时序图。
具体实施方式
20.现在将参考附图更全面地描述示例实施例。然而，示例实施例能够以多种形式实施，且不应被理解为限于在此阐述的实施例；相反，提供这些实施例使得本技术将全面和完整，并将示例实施例的构思全面地传达给本领域的技术人员。在图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。
21.所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本公开的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而没有这些特定细节中的一个或更多，或者可以采用其它的方式、组元、材料、装置等。在这些情况下，将不详细示出或描述公知结构、方法、装置、实现、材料或者操作。
22.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
23.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。
24.本领域技术人员可以理解，附图只是示例实施例的示意图，附图中的模块或流程并不一定是实施本技术所必须的，因此不能用于限制本技术的保护范围。
25.图1示出一示例性实施例的直播业务中消息服务的方法流程图。
26.s101，服务端根据客户端发送的请求参数，获取所处集群信息。
27.根据示例实施例，用户进入直播间后，由客户端发送请求参数，请求服务端获取集群地址。
28.根据一些实施例，服务端针对不同的场景提供不同类型的消息发送方式，从请求来源上主要分为api和sdk两种，其中api方式是服务端对服务端，sdk是服务前端对服务端。
29.s102，服务端根据集群信息向客户端返回两个集群地址。
30.根据示例实施例，服务端根据请求参数获取当前所处集群信息，重点返回两个集群地址，msg主地址和chat主地址。
31.s103，客户端根据两个集群地址分别建立两个长连接。
32.根据示例实施例，客户端通过集成sdk，分别与两个主地址建立长连接。
33.s104，服务端经由两个长连接发送不同消息类型的消息数据，客户端用这两个长连接来接收不同消息类型的消息数据。
34.根据示例实施例，消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
35.根据示例实施例，基于msg主地址建立的长连接，服务端按照第一类型消息发送方式发送消息类型为房间消息和自定义消息的消息；基于chat主地址建立的长连接，服务端按照第二类型消息发送方式发送消息类型为聊天消息与上下线消息的消息。
36.根据示例实施例，基于msg主地址建立的长连接，客户端按照第一类型消息接收方式接收消息类型为房间消息和自定义消息的消息；基于chat主地址建立的长连接，客户端按照第二类型消息接收方式接收消息类型为聊天消息与上下线消息的消息。
37.根据示例实施例，如图3所示，第一类型消息发送方式包括，服务端基于redis的发布订阅方式来与客户端来进行消息推送及接收，客户端在根据msg主地址与服务端建立长连接时，主要是根据平台提供的另一长连接服务来进行，长连接服务与消息服务通过使用同一套redis集群来进行即时通讯。服务端包括提供长连接服务的第一服务端和提供消息服务的第二服务端，其中：第一服务端为订阅方，第二服务端为发布方；第二服务端接收发送消息请求，发送消息。
38.根据示例实施例，如图4所示，第一服务端与第二服务端在消息发送与接收时，通过socket.io（简称sio）发射器进行消息发送，通过socket.io（简称sio）适配器进行消息的订阅。
39.根据一些实施例，提供消息服务的第二服务端接收到发送消息请求后，若为房间消息或者自定义消息，会使用sio发射器来进行消息发送，其内部实际上是对redis的publish命令及发送内容的二次封装。
40.根据一些实施例，如图3所示，发送消息逻辑主要包括：请求参数合法性验证、消息长度校验、应用及频道信息检查、根据不同消息类型封装消息数据、消息合法性验证、通过rocketmq进行消息异步发送（生产者）、返回接口处理结果。
41.根据一些实施例，在本技术中涉及到应用信息、频道信息等基本的数据查询验证操作时，需要从数据库中来查询获取。因此消息服务在设计上采用分层的方式，即业务处理（消息前置层）+数据处理（消息数据层）两层。其中消息前置层主要负责针对不同接口进行业务逻辑编排，当部分逻辑需要从数据库获取数据时，由前置层调用数据层来查询对应数据。而本身数据层在设计上只为前置层提供服务，不会对外，这样能尽可能保证数据的安全性。
42.根据一些实施例，引入rocketmq进行异步消息发送，是出于其具有业务解耦、高可用性、高可靠性等特点，因此在进行实际消息发送时，主要通过异步的方式来进行。即发送消息接口实际上作为消息的生产者，将组装好的消息推送到mq里，然后消息服务针对不同消息类型设置不同的消息消费者来进行实际的消息发送。
43.根据示例实施例，第二类型消息发送方式包括，在按照第二类型消息发送方式发送消息的情况下，服务端是基于nginx的push stream模块来实现的。客户端sdk根据chat主地址与服务端建立长连接时，客户端为订阅方，服务端为发布方；在服务端接收到客户端发送的发送消息的请求的情况下，服务端采用短连接的请求方式向chat服务的pub地址发送消息。
44.本技术提出一种直播业务中消息服务的方法，消息服务在方案上进行合理的分层及分包设计，根据不同消息类型采用不同的长连接服务来进行消息分发，使业务使用更加合理化；通过引入rocketmq消息中间件来进行消息异步分发，在高并发场景下能有效的降低消息的延迟率，并且通过其应用解耦、流量削峰的优点，使系统的整体性能得到更好的提升。
45.本技术提出一种直播业务中消息服务的方法，在架构设计上，根据业务的不同需求进行合理的定向扩展，通过采用业务处理+数据处理分层的模式，在服务部署时可以更合理的规划不同服务的部署节点数，从而使各服务的利用率达到最大化以及最合理化，这样在企业直播行业里能更好的降低企业的服务部署成本。并且，该方案在实施过程中，因为本身服务间及服务内不同的分层设计，根据业务使用情况来定义服务初始部署节点，后期在消息业务增长或下降的场景下，可以根据业务增长情况进行扩容、缩容且保持成本最优；在应对不同业务需求上，其扩展性及可复用性都比传统模式的表现更突出，后期的服务可维护性更强。
46.图2示出一示例性实施例的直播业务中消息服务的系统示意图。
47.如图2所示，直播业务中消息服务的系统包括客户端201，服务端203。
48.根据示例实施例，客户端201，用于发送参数请求，获取服务端203根据参数请求返回的两个集群地址。
49.根据一些实施例，用户进入直播间后，由客户端201发送请求参数，请求服务端203获取集群地址。
50.根据示例实施例，服务端203，用于根据客户端201发送的请求参数，获取所处集群信息，根据集群信息向客户端201返回两个集群地址。
51.根据示例实施例，服务端203根据请求参数获取当前所处集群信息，重点返回两个集群地址，msg主地址和chat主地址。
52.根据一些实施例，服务端203针对不同的场景提供不同类型的消息发送方式，从请求来源上主要分为api和sdk两种，其中api方式是服务端203对服务端203，sdk是服务前端对服务端203。
53.根据示例实施例，客户端201用于根据两个集群地址分别建立两个长连接。
54.根据示例实施例，客户端201通过集成sdk，分别与两个主地址建立长连接。
55.根据示例实施例，服务端203经由两个长连接发送不同消息类型的消息数据。
56.根据示例实施例，消息类型包括：房间消息，自定义消息，聊天消息和上下线消息。
57.根据示例实施例，基于msg主地址建立的长连接，客户端201按照第一类型消息接收方式接收消息类型为房间消息和自定义消息的消息；基于chat主地址建立的长连接，客户端201按照第二类型消息接收方式接收消息类型为聊天消息与上下线消息的消息。
58.根据示例实施例，基于msg主地址建立的长连接，服务端203按照第一类型消息发送方式发送消息类型为房间消息和自定义消息的消息；基于chat主地址建立的长连接，服务端203按照第二类型消息发送方式发送消息类型为聊天消息与上下线消息的消息。
59.根据示例实施例，第一类型消息发送方式包括，服务端203基于redis的发布订阅方式来与客户端201来进行消息推送及接收，客户端201在根据msg主地址与服务端203建立长连接时，主要是根据平台提供的另一长连接服务来进行，长连接服务与消息服务通过使
用同一套redis集群来进行即时通讯。服务端203包括提供长连接服务的第一服务端和提供消息服务的第二服务端，其中：第一服务端为订阅方，第二服务端为发布方；第二服务端接收发送消息请求，发送消息。
60.根据示例实施例，第一服务端与第二服务端在消息发送与接收时，通过socket.io（简称sio）发射器进行消息发送，通过socket.io（简称sio）适配器进行消息的订阅。
61.根据一些实施例，提供消息服务的第二服务端接收到发送消息请求后，若为房间消息或者自定义消息，会使用sio发射器来进行消息发送，其内部实际上是对redis的publish命令及发送内容的二次封装。
62.根据示例实施例，第二类型消息发送方式包括，在按照第二类型消息发送方式发送消息的情况下，服务端203是基于nginx的push stream模块来实现的。客户端201sdk根据chat主地址与服务端203建立长连接时，客户端201为订阅方，服务端203为发布方；在服务端203接收到客户端201发送的发送消息的请求的情况下，服务端203采用短连接的请求方式向chat服务的pub地址发送消息。
63.根据一些实施例，在本技术中涉及到应用信息、频道信息等基本的数据查询验证操作时，需要从数据库中来查询获取。因此消息服务在设计上采用分层的方式，即业务处理（消息前置层）+数据处理（消息数据层）两层。其中消息前置层主要负责针对不同接口进行业务逻辑编排，当部分逻辑需要从数据库获取数据时，由前置层调用数据层来查询对应数据。而本身数据层在设计上只为前置层提供服务，不会对外，这样能尽可能保证数据的安全性。
64.本技术提出一种直播业务中消息服务的系统，消息服务在方案上进行合理的分层及分包设计，根据不同消息类型采用不同的长连接服务来进行消息分发，使业务使用更加合理化；通过引入rocketmq消息中间件来进行消息异步分发，在高并发场景下能有效的降低消息的延迟率，并且通过其应用解耦、流量削峰的优点，使系统的整体性能得到更好的提升。
65.本技术提出一种直播业务中消息服务的系统，在架构设计上，根据业务的不同需求进行合理的定向扩展，通过采用业务处理+数据处理分层的模式，在服务部署时可以更合理的规划不同服务的部署节点数，从而使各服务的利用率达到最大化以及最合理化，这样在企业直播行业里能更好的降低企业的服务部署成本。并且，该方案在实施过程中，因为本身服务间及服务内不同的分层设计，根据业务使用情况来定义服务初始部署节点，后期在消息业务增长或下降的场景下，可以根据业务增长情况进行扩容、缩容且保持成本最优；在应对不同业务需求上，其扩展性及可复用性都比传统模式的表现更突出，后期的服务可维护性更强。
66.应清楚地理解，本技术描述了如何形成和使用特定示例，但本技术不限于这些示例的任何细节。相反，基于本技术公开的内容的教导，这些原理能够应用于许多其它实施例。
67.此外，需要注意的是，上述附图仅是根据本技术示例性实施例的方法所包括的处理的示意性说明，而不是限制目的。易于理解，上述附图所示的处理并不表明或限制这些处理的时间顺序。另外，也易于理解，这些处理可以是例如在多个模块中同步或异步执行的。
68.以上具体地示出和描述了本技术的示例性实施例。应可理解的是，本技术不限于
这里描述的详细结构、设置方式或实现方法；相反，本技术意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。