EasyGBS如何通过sms模块分布式部署解决起播卡顿的问题?

文章介绍了如何通过将EasyGBS原有的单一CMS+SMS架构中的SMS拆分为分布式服务,以缓解大量摄像头通道接入导致的起播卡顿现象。利用redis进行负载均衡,修改前端播放地址的反向代理,实现播放流畅度的提升。提供部分关键代码示例,并鼓励读者试用EasyGBS平台进行进一步了解。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

部分现场由于接入摄像头通道的数量过多,会出现起播时卡顿的现象。目前EasyGBS采用的单一CMS+SMS架构。用户希望将SMS拆分为分布式服务,从而解决起播卡顿的问题。

微信截图_20201125155017.png

GB28181协议起播流程如下,这里不再赘述。分布式SMS部署是指当用户开始播放流时,由底层负载均衡算法,将Invite请求发送给不同的SMS服务器。该架构理论上能够很大程度的减轻单一SMS播放的负载,提高播放流畅度。

image.png

根据以上的流程,我们来设计代码实现该功能。

由于原先的CMS和SMS间的通信是有redis实现的。因此在新增SMS服务时仅仅需要将所有SMS服务注册到同一的redis数据库即可。负载均衡由redis内部实现。同时因为是不同主机的SMS服务,需要修改前端各类播放地址的反向代理地址。

以下为部分代码参考:

mediaTypeArr := make([]string, 0)
if playMediaTypeAllMediaType != "" {
   mediaTypeArr = strings.Split(playMediaTypeAllMediaType, ",")
   if len(mediaTypeArr) >= 6 {
      if mediaTypeArr[0] == "1" {
         data["FLV"] = wrapURLWithLiveToken(flvURL, c)
      }
      if mediaTypeArr[1] == "1" {
         data["RTMP"] = rtmpURL
      }
      if mediaTypeArr[2] == "1" {
         data["RTSP"] = rtspURL
      }
      if mediaTypeArr[3] == "1" {
         data["HLS"] = wrapURLWithLiveToken(hlsURL, c)
      }
      if mediaTypeArr[4] == "1" {
         data["WS_FLV"] = wrapURLWithLiveToken(ws_flvURL, c)
      }
      if mediaTypeArr[5] == "1" {
         data["WEBRTCS"] = wrapURLWithLiveToken(webrtc, c)
      }
   }
}

EasyGBS平台支持直接下载试用,如果大家对EasyGBS的其他功能还想做进一步了解,可以直接进行试用,我们都会为大家提供为期30天的试用期,期间可以进行二次开发或者调用集成,欢迎了解。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值