CN110891183A - 频道共享方法、设备和计算机可读存储介质 - Google Patents

频道共享方法、设备和计算机可读存储介质 Download PDF

Info

Publication number
CN110891183A
CN110891183A CN201811056927.1A CN201811056927A CN110891183A CN 110891183 A CN110891183 A CN 110891183A CN 201811056927 A CN201811056927 A CN 201811056927A CN 110891183 A CN110891183 A CN 110891183A
Authority
CN
China
Prior art keywords
channel
streaming media
media server
channels
utilization rate
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.)
Granted
Application number
CN201811056927.1A
Other languages
English (en)
Other versions
CN110891183B (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.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Priority to CN201811056927.1A priority Critical patent/CN110891183B/zh
Publication of CN110891183A publication Critical patent/CN110891183A/zh
Application granted granted Critical
Publication of CN110891183B publication Critical patent/CN110891183B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385Channel allocation; Bandwidth allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本发明公开了一种频道共享方法、设备和计算机可读存储介质,该方法包括:检测多个流媒体服务器的资源使用率;从所述多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据所述第一流媒体服务器中多个频道的点播情况;根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道;从所述多个流媒体服务器中选出资源使用率不超过所述预设阈值的第二流媒体服务器,在所述第二流媒体服务器上创建所述至少一个频道对应的临时频道。根据本发明的技术方案,能够自动从资源使用率较高的流媒体服务器上发现热点频道,并通过在资源使用率较低的流媒体服务器上创建热点频道的临时频道,来分担热点频道的压力,从而平衡资源使用率较高和较低的流媒体服务器的负载。

Description

频道共享方法、设备和计算机可读存储介质
技术领域
本发明涉及通信技术领域,尤其涉及一种频道共享方法、设备和计算机可读存储介质。
背景技术
IPTV(交互式网络电视)业务中,直播业务是视频类的基础业务,其分发方式主要有组播、单播和单播加直播三种方式。其中直播业务通过组播进行发送时,流媒体服务器将组播码流发送到上联交换机组播源,用户请求服务时到组播源拉直播码流不受流媒体服务器能力限制,但是相应的对网络设备要求较高;直播业务通过单播发送时需要服务器提供直播码流给用户,对网络设备要求较低,但是相对的对流媒体服务器要求较高。
IPTV业务系统中基于单播或是单播加组播的直播服务模型中,系统通过集中部署多套流媒体服务器来增强该系统的直播服务能力。如果对同一个频道在每套流媒体服务器上都要从编码器接收一路直播码流的话,就需要多路编码器势必会导致运营成本过高;相反如果多套流媒体服务器只接收一路直播码流的话,但是由于每个频道的用户关注程度不一样,会导致各个流媒体服务器间负载不均衡,尤其是热点频道所在流媒体服务器可能会由于能力不足无法正常提供用户直播服务,这样的话不仅影响用户播放体验,同时还会影响运营商对于系统综合能力认可。虽然组播频道可以满足用户直播服务不受流媒体服务器能力限制的影响,但是一旦用户从组播进入时移的时候还是只能由频道所在流媒体提供服务,其他设备由于没有分片录制无法提供服务。
可见,热点频道导致了系统内流媒体服务器间负载不均衡的问题。
发明内容
本发明的主要目的在于提出一种频道共享方法、设备和计算机可读存储介质,旨在解决热点频道导致的流媒体服务器间负载不均衡的问题。
为实现上述目的,本发明提供了一种频道共享方法,包括:检测多个流媒体服务器的资源使用率;从所述多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据所述第一流媒体服务器中多个频道的点播情况;根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道;从所述多个流媒体服务器中选出资源使用率不超过所述预设阈值的第二流媒体服务器,在所述第二流媒体服务器上创建所述至少一个频道对应的临时频道。
为实现上述目标,本发明还提供一种频道共享设备,所述频道共享设备包括处理器、存储器和通信总线;所述通信总线用于实现处理器和存储器之间的连接通信;所述处理器用于执行存储器中存储的频道共享程序,以实现以下步骤:检测多个流媒体服务器的资源使用率;从所述多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据所述第一流媒体服务器中多个频道的点播情况;根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道;从所述多个流媒体服务器中选出资源使用率不超过所述预设阈值的第二流媒体服务器,在所述第二流媒体服务器上创建所述至少一个频道对应的临时频道。
为实现上述目标,本发明还提供一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有一个或者多个程序,所述一个或者多个程序可被一个或者多个处理器执行,以实现前述的频道共享方法的步骤。
根据以上技术方案,可知本发明的频道共享方法、设备和计算机可读存储介质至少具有以下优点:
根据本发明的技术方案,能够自动从资源使用率较高的流媒体服务器上发现热点频道,并通过在资源使用率较低的流媒体服务器上创建热点频道的临时频道,来分担热点频道的压力,从而平衡资源使用率较高和较低的流媒体服务器的负载。
附图说明
图1是根据本发明的一个实施例的频道共享方法的流程图;
图2是根据本发明的一个实施例的频道共享方法的流程图;
图3是根据本发明的一个实施例的频道共享方法的示意图;
图4是根据本发明的一个实施例的频道共享设备的框图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
在后续的描述中,使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明,其本身没有特有的意义。因此,“模块”、“部件”或“单元”可以混合地使用。
如图1所示,本发明的一个实施例中提供了一种频道共享方法,包括:
步骤S110,检测多个流媒体服务器的资源使用率。
步骤S120,从多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据第一流媒体服务器中多个频道的点播情况。
步骤S130,根据多个频道的点播情况,从多个频道中选出至少一个频道作为热点频道。
在本实施例中,首先IPTV管理平台会下发资源使用阀值给各个流媒体服务器,当下属的流媒体服务器资源综合使用率超过了该阀值时,管理平台就会将数据表中记录频道点播频率较高的几个频道将其设置为热点频道。
步骤S140,从多个流媒体服务器中选出资源使用率不超过预设阈值的第二流媒体服务器,在第二流媒体服务器上创建至少一个频道对应的临时频道。
在本实施例中,然后通过频道中继的方式自动创建临时频道到其他的流媒体服务器上,保证各个流媒体服务器均可以提供热点频道的直播和时移服务。且提供给用户服务时管理平台会根据负载均衡模块上报上来的各流媒体服务器资源综合使用率,选择资源占用相对空闲的流媒体服务器提供直播服务。
本实施例的IPTV业务系统自动实现,无需人工干预对数据设备没有特殊要求,但是存在一定的延时需要触发服务器资源阀值并形成热点频道后才可以均衡到各个流媒体服务器提供服务。
如图2所示,本发明的一个实施例中提供了一种频道共享方法,包括:
步骤S210,获取每个流媒体服务器的多个参数,在多个参数均不超过预设数值时,将多个参数代入预设公式计算每个流媒体服务器的资源使用率,在多个参数中任一项超过预设数值时,将每个流媒体服务器的资源使用率设置为预设固定值。
在本实施例中,实现了对流媒体服务器资源综合能力的统计,根据当前统计流媒体服务器的出入向网口流量使用率、磁盘读写IO使用率,以及设备的CPU和内存使用率进行加权计算出来,为管理平台通过负载均衡选择哪个流媒体服务器提供了依据。
在本实施例中,频道作为热点频道提供直播服务时都会提及到通过负载均衡来选择流媒体服务器提供服务,其中负载均衡是以统计的每个流媒体服务器的资源综合使用率为依据的,具体计算方法如下:
参数S5代表流媒体服务器流量占用比=(服务器当前网口入向流量+当前网口出向流量)/为该服务器分配的最大流量除了当前网口出入向流量外磁盘IO读写使用率、服务器的CPU使用率以及内存使用率也需要体现到服务器的综合能力中,这里分别用参数S6、S7、S8代表;对应的流媒体服务器的综合使用率S9计算公式为:
如果S7、S8、S9都小于90%,则S9=S6*60%+S7*20%+S8*10%+S9*10%;
如果S7、S8、S9有一个值大于或是等于90%,则S9=95%,不在对外提供用户服务;
上面公式中的60%、20%、10%、10%为当前服务器流量占用比、磁盘IO读写使用比、CPU利用率和内存利用率在综合利用率中的折合系数,这些折合系数是根据IPTV系统运行在服务器上各自的重要程度情进行逻辑分析所得。同时为了保证系统稳定运行,会设置了一定阀值当S7、S8、S9中有使用率达到90%以上的话不在继续对外提供用户服务,而是优先保证当前用户服务质量。同时服务器综合能力的上报需要设置定时器,这里是每隔30S上报一次服务器的当前流量、磁盘读写IO、CPU使用率和内存使用率,通过上报上来的数值计算出各个流媒体服务器的综合能力使用率,从而选择使用率较低的服务器提供用户服务。
本实施例中,没有将CPU使用率、内存使用率以及磁盘IO使用率单独计算,而是通过实际用户模型的呼叫测试得出上面各个参数值对于系统重要程度结合系统硬件上的性能瓶颈得出各个参数折合系统,同时算法中考虑到了像系统CPU、内存等使用率接近系统使用上限情况下的异常保护,使得各个流媒体服务器能够有效、稳定的、最大限度的提供其资源能力。
步骤S220,从多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据第一流媒体服务器中多个频道的点播情况。
步骤S230,在预设的时间段内对多个频道的点播次数进行采样,并将时间段划分为多个采样颗粒,取点播次数超过预设次数的采样颗粒为有效采样颗粒,根据多个频道对应的有效采样颗粒的数量,判断多个频道是否为热点频道。
在本实施例中,添加了统计功能,用于统计频道的热度,根据频道当天一段时间内的播放频率来确认频道是否是热门频道。
为了统计频道是否具备形成热点频道的触发条件,需要单独流程进行处理,设置了两个定时器,在定时器1触发时会进行热点频道是否满足创建条件的一个判断,满足条件热点频道会创建,但是热点频道会在定时器2时判断是否仍是热点,不是的话会被删除,具体流程如下:
设置一个定时任务,每天6点启动该定时任务用于统计频道是否满足形成热点条件。该统计需要记录到IPTV系统的数据表中,该表由四个字段组成,第一个字段为字符类型字段S1,记录热点频道cid;第二个字段为数组型字段S2,记录每天内频道点播频率;第三个字段为数组型字段S3,记录各个流媒体服务器上热点频道当前状态;第四个字段为布尔值S4,取值为0和1,1代表该频道已经形成热点频道。采样周期内,会记录每个采样颗粒度内提供服务的频道次数,直到每个采样颗粒度时间过后根据判断条件记录该采样颗粒度有效值到S2中,如果是有效采样颗粒的话记录01,反之记录00,通过一个采样周期内采样颗粒度值来确认频道是否满足形成热点条件。S2频道点播频率计算方法:统计每天6点到次日凌晨1点内频道点播次数,并设置采样周期为1h,采样颗粒度为15min,如果每个颗粒度内一个频道被点播次数超过5次的话,认为该采样颗粒是有效的,在一个采样周期1h包含的采样颗粒度中有2个或是以上颗粒有效的话,判定该频道为热点频道。如果频道具备形成热点条件后,管理平台会将频道中继到其他流媒体服务器上,频道中继成功的话会记录频道在各个流媒体服务器上的状态到S3中,同时只要有一个流媒体服务器上中继频道创建成功的话就会将记录热点频道状态的参数S4置为1。频道不满足热点频道创建条件时不会创建热点频道,其热点频道状态参数S4仍为0。还要设置一个定时器,每天凌晨1点时启动将前一天形成的热点频道在数据表中删除,以便新的一天形成新的热点频道。
本实施例中热点频道不是仅仅通过点播次数来判断,防止出现有些频道在一个时间点内点播用户较多,但是其他时间段无人播放的情况,而是以点播频率来判定频道是否是热点频道,而且这里像采样周期、采样颗粒度、以及每个颗粒内点播次数均是可灵活配置的。
步骤S240,从多个流媒体服务器中选出资源使用率不超过预设阈值的第二流媒体服务器,在第二流媒体服务器上创建至少一个频道对应的临时频道。
在本实施例中,如图3所示,用户到节点请求频道直播服务,其上负载均衡模块向数据库DB发起资源查询请求,返回一个可服务的流媒体服务器SS1提供用户服务,流媒体提供用户服务会将资源使用情况上报给DB判断资源是否超过阀值,如果超过进入热点频道自动创建流程。触发热点频道创建时节点上的负责均衡模块会向DB查询数据库表记录,判断频道所在流媒体服务器上是否存在点播频率超过阀值的频道进行热点频道的创建。热点频道创建时节点的负载均衡模块会向DB发送消息申请创建临时频道所需的资源。DB将查询到的非热点频道所在的流媒体资源进行上报节点,由节点发起临时频道的创建,存在的资源的流媒体服务器SS2临时频道创建成功,反之流媒体服务器SS3资源不足创建失败会每个1S继续重建。创建失败的热点频道会继续创建直到下个采样周期,如果该频道在新采样周期内不满足热点频道创建条件后该临时频道会创建失败不会再在该流媒体服务器上进行创建。
步骤S250,在创建作为热点频道的单播频道时,将单播频道的频道出向地址设置为上联交换机可接收的组播源地址,使单播频道的码流发送至上联交换机;
步骤S260,在获取对单播频道的直播请求时,在单播频道所在流媒体服务器外的其他流媒体服务器上创建组播频道,组播频道使用来自上联交换机的码流播放给用户。
在本实施例中,对于已知热点频道,可以直接在业务管理门户进行节点内组播频道的创建,该频道创建时频道出向填写上联交换机可接收到的组播源地址,将单个流媒体服务器上的频道码流通过上连交换机组播到其他流媒体服务器上,实现热点频道的共享,但是该方式需要提前规划好组播组地址,对网络设备有一定的要求。本实施例的技术方案虽然对数据设备要求相对较高,但是可以提前人工识别出热点频道进行预置,这样用户请求该频道播放时就可以实现负载均衡由多个服务器共同提供服务。
本实施例技术方案的一个具体示例中,人工识别到的热点频道并创建的流程如下:首先人工识别出热点频道,并在业务管理门户上创建单播频道,但是频道出向地址填写的是上联交换机可接收的组播组地址。频道创建好之后,组播码流会发送到上联交换机,通过限制TTL值只允许该组播码流发送到流媒体服务器所接上联交换机,同时允许IPTV系统内的其他流媒体服务器去交换机拉组播码流创建个节点内组播频道。当直播用户请求服务时,其他流媒体服务器上会创建节点内组播频道,码流来自主频道发送到上联交换机上的组播码流,频道创建好之后,管理平台会根据负载均衡选择其中一个资源利用率相对较低的服务器来提供服务。
其中,根据单播频道所在流媒体服务器外的其他流媒体服务器的资源使用率,从其他流媒体服务器中选择一个流媒体服务器创建组播频道。
在本实施例中,IPTV系统中频道直播服务流程也有所优化,用户直播请求时会判断是否是热点频道,不是的话单播频道只能由频道所在流媒体服务器提供服务,组播频道由组播源发送码流给用户,如是热点频道的话会根据流媒体资源综合使用率来选取空闲的一块流媒体服务器提供服务,如下:流媒体服务器接收用户发送的直播服务请求时,会获取请求直播服务器请求中包含的频道直播源地址。如果获取到的频道直播源地址是发送到交换机上的组播源地址的话,该频道为组播频道,频道出向码流已经发送到网络设备的组播源,用户可以直接到网络设备的组播源去下拉码流。如果频道是单播频道但是获取的频道直播源地址是发送到交换机上的组播源地址的话,该频道应该是人工创建的热门频道,该类型频道码流会通过组播的方式发送到上联网络设备,用户请求播放时会根据负载均衡选择资源利用率低的提供服务。如果获取到的频道直播源地址是单播地址的话,说明频道是单播频道,需要查询数据表确认该频道是否是热点频道。经查询数据库确认该单播频道不是热点频道的话,用户发送直播请求时只能由频道所在的流媒体提供服务。如果用户请求的该频道已经形成热点频道的话,此时直播用户发送请求时,负载均衡模块会判断选取所有流媒体服务器中资源空闲的提供服务。
根据本实施例的技术方案,通过对频道创建流程上的改进和创新,优化了原来的组播出频其直播服务可以不受频道所在流媒体服务器能力限制但是直播切换到时移后仍要受频道所在流媒体服务器读写IO限制的缺陷,实现了热点频道可以由节点内各个流媒体服务器提供直播和时移的请求,充分发挥各个流媒体服务器的能力。首先人工能够判断出是热点频道的可以在业务门户上将频道设置为热点频道,不能区分是否是热点频道的话本专利中也提供了通过策略来判断是否具备创建热点频道的条件,具备的话会自动创建为热点频道。本实施例实现了热点频道在系统内各个流媒体服务器间的共享,热点频道创建好之后本文又考虑到了服务侧通过计算各个流媒体服务器的综合使用率,来作为负载均衡依据更加合理的选择其中的一台服务器提供服务的方法;这样更加趋于合理化,使服务器资源统计更加准确,保证了资源的充分稳定的利用。其他类似方案也在本专利要求的包含范围之内。
如图4所示,本发明的一个实施例中提供了一种频道共享设备,频道共享设备包括处理器410、存储器420和通信总线430;
通信总线430用于实现处理器410和存储器420之间的连接通信;
处理器410用于执行存储器420中存储的频道共享程序,以实现以下步骤:
检测多个流媒体服务器的资源使用率。
从多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据第一流媒体服务器中多个频道的点播情况。
根据多个频道的点播情况,从多个频道中选出至少一个频道作为热点频道。
在本实施例中,首先IPTV管理平台会下发资源使用阀值给各个流媒体服务器,当下属的流媒体服务器资源综合使用率超过了该阀值时,管理平台就会将数据表中记录频道点播频率较高的几个频道将其设置为热点频道。
从多个流媒体服务器中选出资源使用率不超过预设阈值的第二流媒体服务器,在第二流媒体服务器上创建至少一个频道对应的临时频道。
在本实施例中,然后通过频道中继的方式自动创建临时频道到其他的流媒体服务器上,保证各个流媒体服务器均可以提供热点频道的直播和时移服务。且提供给用户服务时管理平台会根据负载均衡模块上报上来的各流媒体服务器资源综合使用率,选择资源占用相对空闲的流媒体服务器提供直播服务。
本实施例的IPTV业务系统自动实现,无需人工干预对数据设备没有特殊要求,但是存在一定的延时需要触发服务器资源阀值并形成热点频道后才可以均衡到各个流媒体服务器提供服务。
如图4所示,本发明的一个实施例中提供了一种频道共享设备,频道共享设备包括处理器410、存储器420和通信总线430;
通信总线430用于实现处理器410和存储器420之间的连接通信;
处理器410用于执行存储器420中存储的频道共享程序,以实现以下步骤:
获取每个流媒体服务器的多个参数,在多个参数均不超过预设数值时,将多个参数代入预设公式计算每个流媒体服务器的资源使用率,在多个参数中任一项超过预设数值时,将每个流媒体服务器的资源使用率设置为预设固定值。
在本实施例中,实现了对流媒体服务器资源综合能力的统计,根据当前统计流媒体服务器的出入向网口流量使用率、磁盘读写IO使用率,以及设备的CPU和内存使用率进行加权计算出来,为管理平台通过负载均衡选择哪个流媒体服务器提供了依据。
在本实施例中,频道作为热点频道提供直播服务时都会提及到通过负载均衡来选择流媒体服务器提供服务,其中负载均衡是以统计的每个流媒体服务器的资源综合使用率为依据的,具体计算方法如下:
参数S5代表流媒体服务器流量占用比=(服务器当前网口入向流量+当前网口出向流量)/为该服务器分配的最大流量除了当前网口出入向流量外磁盘IO读写使用率、服务器的CPU使用率以及内存使用率也需要体现到服务器的综合能力中,这里分别用参数S6、S7、S8代表;对应的流媒体服务器的综合使用率S9计算公式为:
如果S7、S8、S9都小于90%,则S9=S6*60%+S7*20%+S8*10%+S9*10%;
如果S7、S8、S9有一个值大于或是等于90%,则S9=95%,不在对外提供用户服务;
上面公式中的60%、20%、10%、10%为当前服务器流量占用比、磁盘IO读写使用比、CPU利用率和内存利用率在综合利用率中的折合系数,这些折合系数是根据IPTV系统运行在服务器上各自的重要程度情进行逻辑分析所得。同时为了保证系统稳定运行,会设置了一定阀值当S7、S8、S9中有使用率达到90%以上的话不在继续对外提供用户服务,而是优先保证当前用户服务质量。同时服务器综合能力的上报需要设置定时器,这里是每隔30S上报一次服务器的当前流量、磁盘读写IO、CPU使用率和内存使用率,通过上报上来的数值计算出各个流媒体服务器的综合能力使用率,从而选择使用率较低的服务器提供用户服务。
本实施例中,没有将CPU使用率、内存使用率以及磁盘IO使用率单独计算,而是通过实际用户模型的呼叫测试得出上面各个参数值对于系统重要程度结合系统硬件上的性能瓶颈得出各个参数折合系统,同时算法中考虑到了像系统CPU、内存等使用率接近系统使用上限情况下的异常保护,使得各个流媒体服务器能够有效、稳定的、最大限度的提供其资源能力。
从多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据第一流媒体服务器中多个频道的点播情况。
在预设的时间段内对多个频道的点播次数进行采样,并将时间段划分为多个采样颗粒,取点播次数超过预设次数的采样颗粒为有效采样颗粒,根据多个频道对应的有效采样颗粒的数量,判断多个频道是否为热点频道。
在本实施例中,添加了统计功能,用于统计频道的热度,根据频道当天一段时间内的播放频率来确认频道是否是热门频道。
为了统计频道是否具备形成热点频道的触发条件,需要单独流程进行处理,设置了两个定时器,在定时器1触发时会进行热点频道是否满足创建条件的一个判断,满足条件热点频道会创建,但是热点频道会在定时器2时判断是否仍是热点,不是的话会被删除,具体流程如下:
设置一个定时任务,每天6点启动该定时任务用于统计频道是否满足形成热点条件。该统计需要记录到IPTV系统的数据表中,该表由四个字段组成,第一个字段为字符类型字段S1,记录热点频道cid;第二个字段为数组型字段S2,记录每天内频道点播频率;第三个字段为数组型字段S3,记录各个流媒体服务器上热点频道当前状态;第四个字段为布尔值S4,取值为0和1,1代表该频道已经形成热点频道。采样周期内,会记录每个采样颗粒度内提供服务的频道次数,直到每个采样颗粒度时间过后根据判断条件记录该采样颗粒度有效值到S2中,如果是有效采样颗粒的话记录01,反之记录00,通过一个采样周期内采样颗粒度值来确认频道是否满足形成热点条件。S2频道点播频率计算方法:统计每天6点到次日凌晨1点内频道点播次数,并设置采样周期为1h,采样颗粒度为15min,如果每个颗粒度内一个频道被点播次数超过5次的话,认为该采样颗粒是有效的,在一个采样周期1h包含的采样颗粒度中有2个或是以上颗粒有效的话,判定该频道为热点频道。如果频道具备形成热点条件后,管理平台会将频道中继到其他流媒体服务器上,频道中继成功的话会记录频道在各个流媒体服务器上的状态到S3中,同时只要有一个流媒体服务器上中继频道创建成功的话就会将记录热点频道状态的参数S4置为1。频道不满足热点频道创建条件时不会创建热点频道,其热点频道状态参数S4仍为0。还要设置一个定时器,每天凌晨1点时启动将前一天形成的热点频道在数据表中删除,以便新的一天形成新的热点频道。
本实施例中热点频道不是仅仅通过点播次数来判断,防止出现有些频道在一个时间点内点播用户较多,但是其他时间段无人播放的情况,而是以点播频率来判定频道是否是热点频道,而且这里像采样周期、采样颗粒度、以及每个颗粒内点播次数均是可灵活配置的。
从多个流媒体服务器中选出资源使用率不超过预设阈值的第二流媒体服务器,在第二流媒体服务器上创建至少一个频道对应的临时频道。
在本实施例中,如图3所示,用户到节点请求频道直播服务,其上负载均衡模块向数据库DB发起资源查询请求,返回一个可服务的流媒体服务器SS1提供用户服务,流媒体提供用户服务会将资源使用情况上报给DB判断资源是否超过阀值,如果超过进入热点频道自动创建流程。触发热点频道创建时节点上的负责均衡模块会向DB查询数据库表记录,判断频道所在流媒体服务器上是否存在点播频率超过阀值的频道进行热点频道的创建。热点频道创建时节点的负载均衡模块会向DB发送消息申请创建临时频道所需的资源。DB将查询到的非热点频道所在的流媒体资源进行上报节点,由节点发起临时频道的创建,存在的资源的流媒体服务器SS2临时频道创建成功,反之流媒体服务器SS3资源不足创建失败会每个1S继续重建。创建失败的热点频道会继续创建直到下个采样周期,如果该频道在新采样周期内不满足热点频道创建条件后该临时频道会创建失败不会再在该流媒体服务器上进行创建。
在创建作为热点频道的单播频道时,将单播频道的频道出向地址设置为上联交换机可接收的组播源地址,使单播频道的码流发送至上联交换机;
在获取对单播频道的直播请求时,在单播频道所在流媒体服务器外的其他流媒体服务器上创建组播频道,组播频道使用来自上联交换机的码流播放给用户。
在本实施例中,对于已知热点频道,可以直接在业务管理门户进行节点内组播频道的创建,该频道创建时频道出向填写上联交换机可接收到的组播源地址,将单个流媒体服务器上的频道码流通过上连交换机组播到其他流媒体服务器上,实现热点频道的共享,但是该方式需要提前规划好组播组地址,对网络设备有一定的要求。本实施例的技术方案虽然对数据设备要求相对较高,但是可以提前人工识别出热点频道进行预置,这样用户请求该频道播放时就可以实现负载均衡由多个服务器共同提供服务。
本实施例技术方案的一个具体示例中,人工识别到的热点频道并创建的流程如下:首先人工识别出热点频道,并在业务管理门户上创建单播频道,但是频道出向地址填写的是上联交换机可接收的组播组地址。频道创建好之后,组播码流会发送到上联交换机,通过限制TTL值只允许该组播码流发送到流媒体服务器所接上联交换机,同时允许IPTV系统内的其他流媒体服务器去交换机拉组播码流创建个节点内组播频道。当直播用户请求服务时,其他流媒体服务器上会创建节点内组播频道,码流来自主频道发送到上联交换机上的组播码流,频道创建好之后,管理平台会根据负载均衡选择其中一个资源利用率相对较低的服务器来提供服务。
其中,根据单播频道所在流媒体服务器外的其他流媒体服务器的资源使用率,从其他流媒体服务器中选择一个流媒体服务器创建组播频道。
在本实施例中,IPTV系统中频道直播服务流程也有所优化,用户直播请求时会判断是否是热点频道,不是的话单播频道只能由频道所在流媒体服务器提供服务,组播频道由组播源发送码流给用户,如是热点频道的话会根据流媒体资源综合使用率来选取空闲的一块流媒体服务器提供服务,如下:流媒体服务器接收用户发送的直播服务请求时,会获取请求直播服务器请求中包含的频道直播源地址。如果获取到的频道直播源地址是发送到交换机上的组播源地址的话,该频道为组播频道,频道出向码流已经发送到网络设备的组播源,用户可以直接到网络设备的组播源去下拉码流。如果频道是单播频道但是获取的频道直播源地址是发送到交换机上的组播源地址的话,该频道应该是人工创建的热门频道,该类型频道码流会通过组播的方式发送到上联网络设备,用户请求播放时会根据负载均衡选择资源利用率低的提供服务。如果获取到的频道直播源地址是单播地址的话,说明频道是单播频道,需要查询数据表确认该频道是否是热点频道。经查询数据库确认该单播频道不是热点频道的话,用户发送直播请求时只能由频道所在的流媒体提供服务。如果用户请求的该频道已经形成热点频道的话,此时直播用户发送请求时,负载均衡模块会判断选取所有流媒体服务器中资源空闲的提供服务。
根据本实施例的技术方案,通过对频道创建流程上的改进和创新,优化了原来的组播出频其直播服务可以不受频道所在流媒体服务器能力限制但是直播切换到时移后仍要受频道所在流媒体服务器读写IO限制的缺陷,实现了热点频道可以由节点内各个流媒体服务器提供直播和时移的请求,充分发挥各个流媒体服务器的能力。首先人工能够判断出是热点频道的可以在业务门户上将频道设置为热点频道,不能区分是否是热点频道的话本专利中也提供了通过策略来判断是否具备创建热点频道的条件,具备的话会自动创建为热点频道。本实施例实现了热点频道在系统内各个流媒体服务器间的共享,热点频道创建好之后本文又考虑到了服务侧通过计算各个流媒体服务器的综合使用率,来作为负载均衡依据更加合理的选择其中的一台服务器提供服务的方法;这样更加趋于合理化,使服务器资源统计更加准确,保证了资源的充分稳定的利用。其他类似方案也在本专利要求的包含范围之内。
本发明的一个实施例中提供了一种计算机可读存储介质,计算机可读存储介质存储有一个或者多个程序,一个或者多个程序可被一个或者多个处理器执行,以实现以下步骤:
检测多个流媒体服务器的资源使用率。
从多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据第一流媒体服务器中多个频道的点播情况。
根据多个频道的点播情况,从多个频道中选出至少一个频道作为热点频道。
在本实施例中,首先IPTV管理平台会下发资源使用阀值给各个流媒体服务器,当下属的流媒体服务器资源综合使用率超过了该阀值时,管理平台就会将数据表中记录频道点播频率较高的几个频道将其设置为热点频道。
从多个流媒体服务器中选出资源使用率不超过预设阈值的第二流媒体服务器,在第二流媒体服务器上创建至少一个频道对应的临时频道。
在本实施例中,然后通过频道中继的方式自动创建临时频道到其他的流媒体服务器上,保证各个流媒体服务器均可以提供热点频道的直播和时移服务。且提供给用户服务时管理平台会根据负载均衡模块上报上来的各流媒体服务器资源综合使用率,选择资源占用相对空闲的流媒体服务器提供直播服务。
本实施例的IPTV业务系统自动实现,无需人工干预对数据设备没有特殊要求,但是存在一定的延时需要触发服务器资源阀值并形成热点频道后才可以均衡到各个流媒体服务器提供服务。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
上面结合附图对本发明的实施例进行了描述,但是本发明并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本发明的启示下,在不脱离本发明宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本发明的保护之内。

Claims (10)

1.一种频道共享方法,其特征在于,包括:
检测多个流媒体服务器的资源使用率;
从所述多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据所述第一流媒体服务器中多个频道的点播情况;
根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道;
从所述多个流媒体服务器中选出资源使用率不超过所述预设阈值的第二流媒体服务器,在所述第二流媒体服务器上创建所述至少一个频道对应的临时频道。
2.根据权利要求1所述的方法,其特征在于,所述根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道,包括:
在预设的时间段内对所述多个频道的点播次数进行采样,并将所述时间段划分为多个采样颗粒,取点播次数超过预设次数的采样颗粒为有效采样颗粒,根据所述多个频道对应的有效采样颗粒的数量,判断所述多个频道是否为所述热点频道。
3.根据权利要求1所述的方法,其特征在于,所述检测多个流媒体服务器的资源使用率,包括:
获取每个流媒体服务器的多个参数,在所述多个参数均不超过预设数值时,将所述多个参数代入预设公式计算所述每个流媒体服务器的资源使用率,在所述多个参数中任一项超过所述预设数值时,将所述每个流媒体服务器的资源使用率设置为预设固定值。
4.根据权利要求1所述的方法,其特征在于,还包括:
在创建作为所述热点频道的单播频道时,将所述单播频道的频道出向地址设置为上联交换机可接收的组播源地址,使所述单播频道的码流发送至所述上联交换机;
在获取对所述单播频道的直播请求时,在所述单播频道所在流媒体服务器外的其他流媒体服务器上创建组播频道,所述组播频道使用来自所述上联交换机的所述码流播放给所述用户。
5.根据权利要求4所述的方法,其特征在于,在所述单播频道所在流媒体服务器外的其他流媒体服务器上创建组播频道,包括:
根据所述单播频道所在流媒体服务器外的其他流媒体服务器的资源使用率,从所述其他流媒体服务器中选择一个流媒体服务器创建所述组播频道。
6.一种频道共享设备,其特征在于,所述频道共享设备包括处理器、存储器和通信总线;
所述通信总线用于实现处理器和存储器之间的连接通信;
所述处理器用于执行存储器中存储的频道共享程序,以实现以下步骤:
检测多个流媒体服务器的资源使用率;
从所述多个流媒体服务器中选出资源使用率超过预设阈值的第一流媒体服务器,检测根据所述第一流媒体服务器中多个频道的点播情况;
根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道;
从所述多个流媒体服务器中选出资源使用率不超过所述预设阈值的第二流媒体服务器,在所述第二流媒体服务器上创建所述至少一个频道对应的临时频道。
7.根据权利要求6所述的设备,其特征在于,在所述根据所述多个频道的点播情况,从所述多个频道中选出至少一个频道作为热点频道中,所述处理器执行所述频道共享程序,以实现以下步骤:
在预设的时间段内对所述多个频道的点播次数进行采样,并将所述时间段划分为多个采样颗粒,取点播次数超过预设次数的采样颗粒为有效采样颗粒,根据所述多个频道对应的有效采样颗粒的数量,判断所述多个频道是否为所述热点频道。
8.根据权利要求6所述的设备,其特征在于,所述检测多个流媒体服务器的资源使用率中,所述处理器还执行所述频道共享程序,以实现以下步骤:
获取每个流媒体服务器的多个参数,在所述多个参数均不超过预设数值时,将所述多个参数代入预设公式计算所述每个流媒体服务器的资源使用率,在所述多个参数中任一项超过所述预设数值时,将所述每个流媒体服务器的资源使用率设置为预设固定值。
9.根据权利要求6所述的设备,其特征在于,所述处理器还执行所述频道共享程序,以实现以下步骤:
在创建作为所述热点频道的单播频道时,将所述单播频道的频道出向地址设置为上联交换机可接收的组播源地址,使所述单播频道的码流发送至所述上联交换机;
在获取对所述单播频道的直播请求时,在所述单播频道所在流媒体服务器外的其他流媒体服务器上创建组播频道,所述组播频道使用来自所述上联交换机的所述码流播放给所述用户。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有一个或者多个程序,所述一个或者多个程序可被一个或者多个处理器执行,以实现权利要求1至5中任一项所述的方法的步骤。
CN201811056927.1A 2018-09-11 2018-09-11 频道共享方法、设备和计算机可读存储介质 Active CN110891183B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811056927.1A CN110891183B (zh) 2018-09-11 2018-09-11 频道共享方法、设备和计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811056927.1A CN110891183B (zh) 2018-09-11 2018-09-11 频道共享方法、设备和计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN110891183A true CN110891183A (zh) 2020-03-17
CN110891183B CN110891183B (zh) 2022-11-01

Family

ID=69745497

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811056927.1A Active CN110891183B (zh) 2018-09-11 2018-09-11 频道共享方法、设备和计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN110891183B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022063079A1 (zh) * 2020-09-28 2022-03-31 中国移动通信有限公司研究院 多播数据的处理方法、核心网网关、业务服务器及终端

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101080001A (zh) * 2007-06-22 2007-11-28 中兴通讯股份有限公司 网络电视系统中用于实现媒体内容均衡的装置及其方法
WO2008119267A1 (fr) * 2007-04-03 2008-10-09 Huawei Technologies Co., Ltd. Système de distribution de média, appareil et procédé de lecture de média en continu
CN101431653A (zh) * 2008-12-03 2009-05-13 中兴通讯股份有限公司 一种创建和点播频道的方法、系统及装置
CN101895406A (zh) * 2010-06-23 2010-11-24 中兴通讯股份有限公司 一种移动流媒体的直播服务提供方法及系统
CN102572530A (zh) * 2011-12-30 2012-07-11 中兴通讯股份有限公司 流媒体业务频道调整方法及系统
CN104427354A (zh) * 2013-08-28 2015-03-18 中兴通讯股份有限公司 一种直播媒体共享的方法、流媒体服务器及节点子系统
CN106161120A (zh) * 2016-10-08 2016-11-23 电子科技大学 动态均衡负载的分布式元数据管理方法
CN106817629A (zh) * 2016-12-20 2017-06-09 北京华为数字技术有限公司 一种媒体信息传输方法、装置及系统
CN107436813A (zh) * 2017-08-03 2017-12-05 郑州云海信息技术有限公司 一种元数据服务器动态负载均衡的方法及系统
CN107948762A (zh) * 2016-10-13 2018-04-20 华为技术有限公司 直播视频的传输方法、装置和系统

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008119267A1 (fr) * 2007-04-03 2008-10-09 Huawei Technologies Co., Ltd. Système de distribution de média, appareil et procédé de lecture de média en continu
CN101080001A (zh) * 2007-06-22 2007-11-28 中兴通讯股份有限公司 网络电视系统中用于实现媒体内容均衡的装置及其方法
CN101431653A (zh) * 2008-12-03 2009-05-13 中兴通讯股份有限公司 一种创建和点播频道的方法、系统及装置
CN101895406A (zh) * 2010-06-23 2010-11-24 中兴通讯股份有限公司 一种移动流媒体的直播服务提供方法及系统
CN102572530A (zh) * 2011-12-30 2012-07-11 中兴通讯股份有限公司 流媒体业务频道调整方法及系统
CN104427354A (zh) * 2013-08-28 2015-03-18 中兴通讯股份有限公司 一种直播媒体共享的方法、流媒体服务器及节点子系统
CN106161120A (zh) * 2016-10-08 2016-11-23 电子科技大学 动态均衡负载的分布式元数据管理方法
CN107948762A (zh) * 2016-10-13 2018-04-20 华为技术有限公司 直播视频的传输方法、装置和系统
CN106817629A (zh) * 2016-12-20 2017-06-09 北京华为数字技术有限公司 一种媒体信息传输方法、装置及系统
CN107436813A (zh) * 2017-08-03 2017-12-05 郑州云海信息技术有限公司 一种元数据服务器动态负载均衡的方法及系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022063079A1 (zh) * 2020-09-28 2022-03-31 中国移动通信有限公司研究院 多播数据的处理方法、核心网网关、业务服务器及终端

Also Published As

Publication number Publication date
CN110891183B (zh) 2022-11-01

Similar Documents

Publication Publication Date Title
KR100685163B1 (ko) 적응적 액세스 확률 팩터를 통한 무선 베어러 최적화 방법
KR100559979B1 (ko) 이동통신 시스템에서의 메시지 전송방법
US20090147786A1 (en) Multicast service processing method and access equipment
CN112512100B (zh) 基于切片优先级的amf重定向方法和新增管理网元
CN101330658A (zh) 在提供广播或多播服务的多个操作模式间进行选择的方法
EP1650989A1 (en) Method for providing an MBMS service in a wireless communication system
CN106817701B (zh) 资源分配方法及装置
CN101350763A (zh) 一种资源管理方法、系统和网络设备
US9026089B2 (en) Data volume reporting for multimedia broadcast/multimedia service groups
US8509242B2 (en) Method and device for controlling data flows at communication terminals
CN103458466A (zh) 流量控制装置与方法以及网络流量管理系统与方法
CN100550759C (zh) 业务准入方法、抢占方法及通信装置
CN112543508A (zh) 面向5g网络切片的无线资源分配方法及网络架构
US20070263625A1 (en) Access Control for Multicast channel Request
CN114071168A (zh) 混流直播流调度方法及装置
CN110891183B (zh) 频道共享方法、设备和计算机可读存储介质
CN111901881A (zh) 一种传输方法及装置
CN113014672B (zh) 一种消息推送方法、装置、电子设备及存储介质
CN106101468B (zh) 传输链路的确定方法及装置
CN101909194B (zh) 提供频道切换服务的方法、系统及频道切换服务器
CN101695044A (zh) 一种流媒体服务节点及其负载均衡方法
US20050174965A1 (en) Network optimization based on service behavior
CN106304348A (zh) 群组用户设备之间资源共享方法及基站
CN109963333B (zh) 基于服务区的组播资源分配方法及装置
CN114363392B (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
GR01 Patent grant
GR01 Patent grant