本发明属于实时视频互动直播技术领域,具体是一种利用udp特性构建实时流媒体集群调度的方法。
背景技术：
实时流媒体技术通常采用rtp方式传输媒体数据。在集群调度中，当总用户量、单视频流拉流用户量急剧上升时候，非常容易出现流媒体服务器单点流量超标，导致采用媒体数据包被服务器大量丢弃，进而出现用户观看卡顿的现象。如何采用合理的调度算法避免出现此种情况，成为调度算法的核心需求。
现有的算法，通常部署一台专用的监控服务器，实时收集集群内所有流媒体服务节点的cpu、内存、流量等指标，并负责提供用户接入系统的调度依据。但是采集频度很难把控，太高容易出现采集逻辑占用整体过多资源，太低容易出现用户分配不均匀、不合理、转发多等问题，继而造成上述丢包卡顿问题。特别是在用户量瞬间标高的场景，尤为明显。实践中如，在一个千人课堂内，老师邀请学生上线答题，此时课堂内千人学生，会同时去拉取该上线用户的新发布音视频流。调度信息的滞后性，导致调度错误，造成单个媒体服务节点发生突发流量拥塞。
另外，现有的算法在出现单媒体服务节点资源过载时候，只能通过踢出部分服务用户，请求用户重新申请资源，分配用户到新的服务节点的方式降低当前过载节点的资源消耗。但这将导致用户观看端出现黑屏切换、卡顿等现象。
因此，针对目前现有技术中存在的上述缺陷，实有必要进行研究，以提供一种方案，解决现有技术中存在的缺陷，提供更好的资源调度算法，避免用户节点切换，提高用户的观看体验。
技术实现要素：
为了弥补现有技术的不足，本发明提供了一种无资源状态集中实时收集、各媒体节点自身资源实时评估主动任务获取式调度，并利用udp特性构建实时流媒体集群调度的方法。
所述的一种利用udp特性构建实时流媒体集群调度的方法，其特征在于包括以下步骤：
(1)用户发送连接请求到上行节点中，上行节点为接入点，接入点将用户对端开放ip和端口储存到内存数据库服务集群中，然后启动各个下行节点，下行节点为流媒体服务器，下行节点调用接入点的服务器接口，返回自身负载，接入点服务器在收到后记录流媒体服务器当前负载到内存服务器中；
(2)用户推流，发送rtp/rtcp数据到接入点，接入点查询内存数据，获得当前流媒体服务器资源负载，先选择前三个空闲服务器，发送分配请求到所述空闲服务器中；
(3)所述流媒体服务器收到推流请求后，根据自身当前实时负载判定是否进行推流接收服务，并返回，同时返回自身实时负载给接入点服务器，接入点服务器更新实时负载到内存数据库，根据收到服务器情况，选择一个最优服务器，下发任务；
(4)所述流媒体服务器接收确认任务后，再次根据自身当前实时负载判定是否进行推流接收服务并返回，同时返回自身实时负载给接入点服务器，接入点服务更新实时负载到内存数据库，同时收到服务器确认情况，如果成功分配，则开始转发用户后续rtp数据包到确定的流媒体服务器，否则回到上述步骤(1)重新开始分配流程，完成推流用户的一个分配过程；
(5)用户拉指定流a，发送拉流请求到接入点，接入点查询内存数据，获得当前所有正在服务流a的流媒体服务器负载，最多选择前三个空闲服务器，下发任务，并同时发送用户对端开放ip和端口，以及自身的内网ip和同该用户通讯的内网端口，如果当前无法获得空闲服务器，根据最后服务器状态判断都负载过高时候，启动流媒体服务器自动分配和启动流程，完成新服务器扩容，并下发和完成流媒体a的服务器转发，之后重新进行本步骤；
(6)流媒体服务器收到拉流请求后，根据自身当前实时负载判定是否进行拉流推送服务，并返回，同时返回自身实时负载给接入点服务器，如果负载正常，可提供服务，同时记录用户对端开放ip和端口，以及接入点的内网ip和同该用户通讯的内网端口；
(7)接入点服务器更新实时负载到内存数据库，根据收到服务器情况，如果成功分配，则开始转发后续可能的少量rtcp包到该确定服务器，否则回到上述步骤(5)重新开始拉流分配流程，完成拉流用户的一个分配；
(8)拉流流媒体服务器，在收到流a的一个rtp数据包后，遍历当前所有接收服务任务的拉流用户列表，构建rtp下行数据包，并修改rtp数据包udp协议栈中目标ip和端口为之前记录的该用户开放ip和端口，修改发送ip和端口为对应接入点内部ip和端口，将数据包发送到内网网关并将数据包发送到公网，数据包正常到达该确定用户，用户拉到流a并开始解码观看。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述步骤(2)还包括步骤(21)，当服务器资源不足时，启动流媒体服务器自动分配和启动流程，完成新服务器扩容后，重新进行所述步骤(2)。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述步骤(5)中新服务器从当前具有a流的服务器拉取a流。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述步骤(8)中所述内网网关根据数据包和自身的网关内网ip和端口映射表，自动修改发送ip和端口为和确定用户通讯的接入点对应的公网ip和端口。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述步骤(8)中的所述rtp数据包来自于发布流a的用户通过接入点上行转发，或者来自于其他流a的流媒体服务器转发。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于上行节点为接入点，所述接入点组合为接入点集群，用于实现用户rtp/rtcp协议的协商和接入。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于下行节点为流媒体服务节点，组合为流媒体服务节点集群，当下行节点本身发现资源紧张时候，通知到上行节点中的调度模块中。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述的调度模块发起下行节点资源申请命令，新的下行节点收到后立即根据服务用户的目标ip和端口，构建rtp包，发起流媒体数据的转发服务。
所述的利用udp特性构建实时流媒体集群调度的方法，其特征在于所述流媒体服务器、空闲服务器、接入点服务器、新服务器均具有统一出口网关，即服务器集群处于同一内网中。
与现有技术相比，本发明有以下优点：
巧妙的利用rtp包分发单向打通的方式，将下行分离出接入点，继而简化调度，并提高整体的资源利用率，减少用户因资源调度付出的如切断重新申请等代价。本方法不仅可以降低企业流媒体服务成本，提高用户流媒体体验，而且为现代社会发展中涌现出的新应用场景(如在线教育、社交泛娱乐、互动游戏、电商直播、企业协作、金融医疗、iot)等的加速发展提供了技术方案支持。
具体实施方式
一种利用udp特性构建实时流媒体集群调度的方法，包括接入点集群、流媒体服务节点集群和内存数据库服务集群。采用上下行分离的方式实现下行观看的巨量便捷扩展，上行节点为接入点集群，下行节点为流媒体服务节点集群。
具体来看，在接入点集群实现用户rtp/rtcp协议的协商和接入，推流用户的上行数据rtp流都通过接入点集群接收。此类上行流量在整个大用户量媒体集群中占用量相对很少，因此此方式可以使少量接入点便可支持巨量用户的接入。
对于下行(拉流)用户，是整个媒体系统中的主要资源占用者。本方法将下行rtp包在流媒体服务节点中直接发送给用户，不经过接入点，直接发送至用户。在udp封包中直接写入用户的目标地址和端口，将负载限定在自身节点上。流媒体服务节点的动态扩展，不再需要用户连接的切换，避免了用户需要断开重连即重新接入系统重新申请资源的方式，极大的提高了用户体验。
本方法的调度算法复杂度低，避免了集中式实时采集数据逻辑对资源的占用。因为下行节点(流媒体服务节点)的独立性，扩展和收缩的成本几乎可忽略，可以做到任意扩展而拉流无感知。由此，在调度层面只需要在下行节点本身发现资源紧张时候，就不去做更多服务，并返回通知到上行节点中的调度模块，调度模块继而发起下行节点资源申请命令，新的下行节点收到后立即根据服务用户的目标ip和端口，构建rtp包，发起流媒体数据的转发服务。
具体来看整个服务过程：
1.保证所有服务器具有统一出口网关，即服务器集群处于同一内网中。
2.用户发送连接请求到接入点，接入点将用户对端开放ip和端口存储到内存服务器集群。
3.各流媒体服务启动后，调用接入点服务器接口，返回自身负载。接入点服务器，收到后记录流媒体服务器当前负载到内存服务器。
4.用户推流，发送rtp/rtcp数据到接入点。接入点查询内存数据，获得当前流媒体服务器资源负载，选择前三个空闲服务器，发送分配请求到此三个服务器。如果服务器资源不足，启动流媒体服务器自动分配和启动流程，完成新服务器扩容后，重新进行本步骤。
5.流媒体服务器收到推流请求后，根据自身当前实时负载判定是否进行推流接收服务，并返回，同时返回自身实时负载给接入点服务器。
6.接入点服务器更新实时负载到内存数据库，根据收到服务器情况，选择一个最优服务器，下发任务。
7.流媒体服务器接收确认任务后，再次根据自身当前实时负载判定是否进行推流接收服务并返回，同时返回自身实时负载给接入点服务器。
8.接入点服务更新实时负载到内存数据库，同时收到服务器确认情况，如果成功分配，则开始转发用户后续rtp数据包到确定的流媒体服务器。否则回到上述3重新开始分配流程。
9.自此，推流用户的一个分配过程已然完成。
10.用户拉指定流a，发送拉流请求到接入点。接入点查询内存数据，获得当前所有正在服务流a的流媒体服务器负载，最多选择前三个空闲服务器，下发任务，并同时发送用户对端开放ip和端口，以及自身的内网ip和同该用户通讯的内网端口。如果当前无法获得空闲服务器，根据最后服务器状态判断都负载过高时候，启动流媒体服务器自动分配和启动流程，完成新服务器扩容，并下发和完成流媒体a的服务器转发(新服务器从当前具有a流的服务器拉取a流)，之后，重新进行本步骤。
11.流媒体服务器收到拉流请求后，根据自身当前实时负载判定是否进行拉流推送服务，并返回，同时返回自身实时负载给接入点服务器。如果负载正常，可提供服务，同时记录用户对端开放ip和端口，以及接入点的内网ip和同该用户通讯的内网端口。
12.接入点服务器更新实时负载到内存数据库，根据收到服务器情况，如果成功分配，则开始转发后续可能的少量rtcp包到该确定服务器。否则回到上述9重新开始拉流分配流程。
13.自此，拉流用户的一个分配过程已然完成。
14.拉流流媒体服务器，在服务用户时过程如下：在收到流a的一个rtp数据包后(可能来自于发布流a的用户通过接入点上行转发，也可能来自于其他流a的流媒体服务器转发)，遍历当前所有接收服务任务的拉流用户列表，构建rtp下行数据包，并修改rtp数据包udp协议栈中目标ip和端口为之前记录的该用户开放ip和端口，修改发送ip和端口为对应接入点内部ip和端口，将数据包发送到内网网关。内网网关根据数据包和自身的网关内网ip和端口映射表，自动修改发送ip和端口为和确定用户通讯的接入点对应的公网ip和端口，将数据包发送到公网，数据包正常到达该确定用户。
15.自此用户拉到流a并开始解码观看。
使用时，本方法提供一种无资源状态集中实时收集、各媒体节点自身资源实时评估主动任务获取式调度，并巧妙的利用rtp包分发单向打通的方式，将下行分离出接入点，继而简化调度，并提高整体的资源利用率，减少用户因资源调度付出的如切断重新申请等代价。本方法不仅可以降低企业流媒体服务成本，提高用户流媒体体验，而且为现代社会发展中涌现出的新应用场景(如在线教育、社交泛娱乐、互动游戏、电商直播、企业协作、金融医疗、iot)等的加速发展提供了技术方案支持。
从用户体验上来看，应用本方案后，解决了大房间扩展的问题，支持万人互动房；在服务端动态扩容情况中，消除了原有的1～3秒的重连等待；稳定的连接降低了网络流量变化率，同时整体的用户卡顿率等指标有明显改善。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。