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

EasyGBS

于 2021-08-25 17:16:20 发布

阅读量172

点赞数

CC 4.0 BY-SA版权

文章标签： sms

本文链接：https://blog.youkuaiyun.com/EasyGBS/article/details/119915649

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

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

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

微信截图_20201125155017.png

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

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

由于原先的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天的试用期，期间可以进行二次开发或者调用集成，欢迎了解。