带货直播系统，实现主播pk三种技术架构

带货直播系统的PK模式是 RTC 技术应用的常见场景，虽然主播PK 的业务逻辑不算复杂，但由于带货直播系统在标准直播模式和主播PK 模式的切换过程中容易产生卡顿、黑屏等现象，为了在优雅实现业务逻辑的同时，最大程度缓解类似的音视频体验问题，工程师们八仙过海各显神通，提出了很多种带货直播系统的实现架构，下面我们介绍其中最典型的三种架构

方案A：

概要说明：

最常见的带货直播系统实现方式，标准直播使用推流SDK，切换成PK模式的话，走的是连麦及合流转码服务；

算是个基准方案，其他方案的优缺点主要都基于跟方案A进行比较

方案风险：

客户端会集成两个SDK，现实中，采用该方案的客户多会有两个供应商，一个提供连麦，一个负责直播，这会存在产生产品间兼容性问题的隐患

由于带货直播系统推流SDK和RTC SDK 是分开的两个SDK，由于涉及到资源的申请和释放，因此，在带货直播系统模式切换时，是比较容易产生卡顿、黑屏等现象的，优化难度较大

方案B：

概要说明：

该方案也可以称之为双流方案，所谓双流，指的是带货直播系统观众端会拉两个主播的流，而非其他方案的一个流；

除了双流以外，该方案还没有使用连麦服务中的合流转码功能

方案优点：

带货直播系统使用单路转推功能，替代掉合流转码功能，由于合流转码一般的单价较高，因此，连麦的消费费用会有较明显的降低

方案风险：

虽然带货直播系统连麦的消费会显著下降，但由于带货直播系统观众端直播流需要拉两路，因此直播云消费可能会显著上升，如果观众主播比较大的话，连麦+直播的总消费会较明显增大

跟标准直播一样，客户端集成了两个SDK，导致模式间切换的体验优化比较困难，产品间的兼容性隐患依旧存在

双流方案，带货直播系统观众端的体验比单流方案是可能有所下滑的，一方面对观众端的带宽要求更高(*2)，另一方面，还存在一定概率的两个主播的rtmp流时间不太同步的隐患

方案的扩展性相对也差些，比如如果未来要做主播观众连麦的玩法，终究还是会回到合流转码的方式上去

方案C：

概要说明：

该方案我们也称之为客户端合流方案，他的主要特点就是主播pk画面的合流由客户端完成；

方案优点：

把合流放到带货直播系统客户端做，那就完全节省了这部分消费，因此，这是个成本最低的方案；

由于始终保持着带货直播系统客户端跟直播云的上行推流线路，在模式切换时不存在所谓进入抢流模式（两个不同的上行推流设备，同时往一个直播通道推流，后推的设备会顶掉前面的上行设备，该模式称之为直播抢流模式），所以理论上带货直播系统模式间切换的体验优化会稍稍好做些

方案风险：

这个方案缺点也比较显著，把合流放到带货直播系统客户端，对主播的网络和手机性能要求都明显提高，尤其是网络，现在多了一路推流，等于上行带宽*2，对直播而言，主播端的推流情况对观众体验的影响是最重要的，主播带宽要求*2，直播体验下降的风险必然增加很大。

————————————————

声明：本文由云豹科技转发自csdn，如有侵权请联系作者删除

原文链接：https://blog.csdn.net/heliang1108/article/details/109228615