秀場互動直播是 RTC 技術應用的常見場景，雖然主播 PK 的業務邏輯不算複雜，但由於在標準直播模式和主播 PK 模式的切換過程中容易產生卡頓、黑屏等現象，爲了在優雅實現業務邏輯的同時，最大程度緩解類似的音視頻體驗問題，工程師們八仙過海各顯神通，提出了很多種秀場直播的實現架構，下面我們介紹其中最典型的四種架構。
基礎方案
這是一種最常見的實現方式，標準直播使用推流 SDK，切換成 PK 模式的話，走的是連麥及合流轉碼服務。其他方案的優缺點主要都基於與這一方案進行比較。
可能風險
兼容性：客戶端會集成兩個 SDK，現實中，採用該方案的客戶多會有兩個供應商，一個提供連麥，一個負責直播，這會存在產生產品間兼容性問題的隱患。
卡頓黑屏：由於推流 SDK 和 RTC SDK 是分開的兩個 SDK，由於涉及到資源的申請和釋放，因此，在模式切換時，是比較容易產生卡頓、黑屏等現象的，優化難度較大。
雙流方案
所謂雙流，指的是觀衆端會拉兩個主播的流，而非其他方案的一個流。除了雙流以外，該方案還沒有使用連麥服務中的合流轉碼功能。
方案優點
連麥費用較低：使用單路轉推功能，替代掉合流轉碼功能，由於合流轉碼一般的單價較高，因此，連麥的消費費用會有較明顯的降低。
可能風險
直播雲費用較高：雖然連麥的消費會顯著下降，但由於觀衆端直播流需要拉兩路，因此直播雲消費可能會顯著上升，如果觀衆主播比較大的話，連麥+直播的總消費會較明顯增大。
兼容性：跟標準直播一樣，客戶端集成了兩個 SDK，導致模式間切換的體驗優化比較困難，產品間的兼容性隱患依舊存在。
觀衆體驗：雙流方案，觀衆端的體驗比單流方案是可能有所下滑的，一方面對觀衆端的帶寬要求更高(*2)，另一方面，還存在一定概率的兩個主播的rtmp流時間不太同步的隱患
拓展性：方案的擴展性相對也差些，比如如果未來要做主播觀衆連麥的玩法，終究還是會回到合流轉碼的方式上去。
客戶端合流方案
客戶端合流方案的主要特點就是主播pk畫面的合流由客戶端完成。
方案優點
成本低：把合流放到客戶端做，那就完全節省了這部分消費，因此，這是個成本最低的方案。
切換體驗：由於始終保持着客戶端跟直播雲的上行推流線路，在模式切換時不存在所謂進入搶流模式（兩個不同的上行推流設備，同時往一個直播通道推流，後推的設備會頂掉前面的上行設備，該模式稱之爲直播搶流模式），所以理論上模式間切換的體驗優化會稍稍好做些。
可能風險
帶寬要求：這個方案缺點也比較顯著，把合流放到客戶端，對主播的網絡和手機性能要求都明顯提高，尤其是網絡，現在多了一路推流，等於上行帶寬*2，對直播而言，主播端的推流情況對觀衆體驗的影響是最重要的，主播帶寬要求*2，直播體驗下降的風險必然增加很大。
七牛方案
七牛秀場直播解決方案結合了七牛雲 QRTC 和 Pili。從技術上說，我們可以稱該方案爲純 RTC 秀場直播方案，他拋棄了相對落後的 RTMP 推流模塊，在技術上具備一定先進性。這一方案相比標準方案，唯一存在的風險是在標準直播模式下，會增加一個單路轉推的費用風險，但由於該服務單價極低，因此新增費用相對可控。
方案優點
包體小：客戶端只用了一個 RTC SDK，客戶接入成本相對較低，且因爲少個SDK，最終APP的包體會略有下降。
體驗好：標準直播模式，使用的是先進的 RTC 推流，相比 RTMP推流，RTC 推流抗弱網的表現更好，經測試，RTMP 推流在丟包 10% 情況下卡頓、延時往往就比較顯著了，而 RTC 往往可以到 30% 丟包甚至更大的情況下，依然能有比較流暢的聲畫體驗，這是因爲從技術上說，RTC 是比 RTMP 更先進的音視頻傳輸技術，是當前人類在音視頻傳輸領域進步的典型成果展示。
抗弱網：推流抗弱網對絕大多數的秀場直播而言，其實意義不是很大，因爲專業的主播往往網絡條件比較好，但在戶外等場景，RTC 推流的意義還是非常顯著的。
切換好：由於使用的是一個 RTC SDK，模式切換時，不存在SDK資源申請和釋放的問題，模式切換的體驗優化相對更容易些。
多兼容：該方案除了實時音視頻雲和直播雲，七牛秀場直播方案在RTC SDK上還深度融合了商湯和字節跳動的美顏濾鏡SDK，這一方面幫助客戶規避了產品間兼容性問題，另一方面又可以讓客戶享受到完整的閉環服務，且整個方案代碼已全部開源。
在秀場直播這一場景的七牛解決方案中，實時音視頻雲 QRTC 實現實時連麥互動，主播間連麥、主播與觀衆的音視頻實時互動。通過直播雲 Pili 的直播流分發，以及融合了行業 TOP 美顏濾鏡 SDK，觀衆觀看到經過美顏、濾鏡以及妝容修飾的主播直播間畫面。通過 IM 聊天、點贊、打賞等功能實現了更好的互動。同時，藉助七牛對象存儲 Kodo 實現直播內容的錄製，以及 Dora 實現內容審覈。