弾幕システムアップデートの血と涙

2016年はライブ放送の波が高まった最初の年であり、多くのインターネット企業がライブ放送コンテンツモジュールに取り組み始めました。現在の会社で私が最初に引き受けた仕事は、生放送事業における集中砲火システムの最適化でした。同社の生放送事業の変化に伴い、弾幕システムも初期バージョンから3～4バージョンにわたって最適化されていった。このプロセスは約1年続きました。この記事では、まず当社の初期の弾幕システムから始め、アップデートプロセス全体の「血と涙」を紹介します。

初期の弾丸スクリーンシステム

1. 基本状況

1. PHP + Gatewayフレームワークで書かれた

2. すべてのクライアントIDはRedisに保存されます

3. 当初、LVSシステムの後ろに3台のマシンが設置され、サービスを提供した。

4. マルチプロセスモードを使用して複数のワーカープロセスを開き、メッセージ配信コンテンツを処理します。

2. 既存の問題

1. メモリ使用量が膨大です。 1 台のマシン (4 コア、8G 構成) で約 500 のクライアントをサポートすると、メモリ制限に達します。

2. メッセージが送信されるたびに、各マシンは Redis から対応する部屋のすべてのクライアント ID を取得する必要があります。同時実行性が高い場合、Redis の単一プロセス処理効率とイントラネット帯域幅がボトルネックになります。

3. 単一マシンの同時処理能力は、メッセージ処理のワーカープロセスの数によって制限されます。同時にあまりにも多くのプロセスを開始すると、システム リソースが無駄になります。

4. 1 つの部屋に 2,000 人以上が集まると、メッセージの遅延が 1 分程度に達する可能性があり、これは非常に深刻な問題です。

3. 一時的な変化

解決すべき問題は非常に緊急であったため、論理的な変更とビジネス レベルのトレードオフをすぐに行いました。

1. Redis インスタンスは 2 台のマシンに分割され、1 台のマシンに 4 つのインスタンスが配置され、Redis への負荷が分散されました。

2. メッセージ処理ワーカープロセスのロジックにいくつかの変更が加えられ、単位時間あたりにブロードキャストされるメッセージ数が制限され、超過したメッセージは破棄されるようになりました。

3. ライブ放送が完了し、オンデマンド状態になった部屋では、トラフィックを迂回するための追加の集中砲火システムが有効になります。

4. メッセージ処理のために 1 つの部屋を複数の部屋に分割します。

4. 変換後の効果

1. Redisの圧力が大幅に軽減される

2. 単一マシンのIOパフォーマンスの圧力が軽減される

3. 同じ数のマシンでより多くのライブ放送ルームをホストできる

[[215183]]

しかし、根本的な問題は解決されていません。圧力の問題を一時的に解決した後、時間をかけて堰堤システムを再分析し、分析された要件に従って新しい堰堤システムを再構築する必要があります。

新しい弾丸スクリーンシステム

1. 新しい箇条書きコメントシステムが直面する課題

1. 一つの部屋に入る人数が比較的多い。弊社のライブ配信状況により、1つの部屋に5万人から10万人が同時にオンラインになることがあります。

2. 生放送コンテンツ等の理由により、一定期間内に利用者数が急増する。

3. できるだけリアルタイムで到着する必要があります。遅延が大きすぎると、インタラクションのリアルタイム性が大幅に低下します。

4. 各メッセージを配信するには、多数の長い接続が必要です。

5. 多数の長い接続を維持するためのメカニズム。

6. 運用プロセス中に、ユーザーブラックリスト、IP ブラックリスト、敏感な単語などのニーズに対処する必要があります。

2. 新しい弾丸スクリーンシステムの要件

1. メモリ管理は PHP の欠点であるため、高い同時実行性と長期的な安定性が求められ、頻繁な更新やメンテナンスを必要としないシステムには最適な選択肢ではありません。したがって、適切な言語を選択することが必須です。

2. 分散型サポートにより迅速な水平拡張が可能になり、1 つの部屋で最大 10 万人をサポートできます。

3. サードパーティのメッセージ（ギフト情報、システム通知など）をシステムにすばやく簡単に送信できます。

4. ローカル メモリ管理を使用して、ルーム内のクライアント接続を記録し、データのやり取りとクエリ時間を大幅に節約します。

5. メッセージブロードキャストを同時にサポートし、ブロードキャストの効率を向上します。

3. 新弾幕システムバージョンの変更方法

1. 開発言語として、現在人気があり、高い並行性のサポートが優れている Golang を選択します。

2. 開発言語を使用してクライアント接続を管理し、各マシンは受信した接続要求のみを管理します。

3. 室内同時ブロードキャスト ロジックを使用して、複数の人に同時にブロードキャストします。

新しい弾丸スクリーンシステムの改造経験

次に、モジュールの詳細を分析し、さらにモジュールの上位層のスケジューリング ロジックを分析します。

1. 部屋の管理

RoomInfo構造体型{
 RoomID 文字列 // 部屋ID
 Lock *sync.Mutex //ルーム操作ロック
Rows []*RowList // 部屋の複数の行のスライス
長さ uint64 //現在の部屋にあるノードの総数
LastChangeTime時刻。時間// 最終更新時間
}
 RowList構造体型{
 Nodes []*Node //ノードリスト
}

各部屋には独自の ID があるため、クライアントが接続を確立すると、ロビー ルームに配置されます。次に、クライアントはRoomID自体を送信すると、対応する部屋に再接続されます。各接続が確立されると、ノードにパッケージ化され、行に配置されます。

型 Node 構造体 {
ルームID文字列
クライアントID int64
接続 *websocket.Conn
 UpdateTime時間。時間 
 LastSendTime時刻。時刻// メッセージが最後に送信された時刻
IsAlive ブール値
DisabledRead bool //発言権限が無効になっているかどうか
}

各ノードには、接続が成功したかどうかを示す IsAlive があります。接続が切断された場合、またはその他の理由でサービスが強制的に停止された場合、このフラグの状態は変更されます。その後、接続は時間指定の処理メカニズムによって閉じられ、メモリからクリアされます。行の本質は、長さが事前に設定されたノード スライスのグループです。

メッセージを送信する場合、スライスの各グループはコルーチンを使用してメッセージを順番に送信します。同じ部屋内の接続はスライスにグループ化され、同時に送信できます。送信時には、同時状況で同じ接続に 2 つのメッセージが混在するのを防ぐために、ロックを使用して部屋全体をロックします。

2. メッセージ管理

var messageChannel map[文字列]chan nodeMessage
関数init() {
 messageChannel = make(map[string]chan nodeMessage)
 }
 func sendMessageToChannel(roomId string, nm nodeMessage) エラー {
 //部屋が存在しない場合は作成します
cの場合、ok:=messageChannel[roomId];わかりました {
 ｃ
 }それ以外{
 //ルームチャンネルを作成
messageChannel[roomId] = make(chan nodeMessage, 1024)
メッセージチャンネル[ルームID]
 //ルームインスタンスを作成する
部屋のオブジェクト:=&部屋の情報{}
 roomObj.RoomID = 部屋ID
部屋オブジェクト。行= make([]*RowList, 0, 4)
 roomObj.Lock = &sync.Mutex{}
 // 部屋を監視するための新しいコルーチンを作成する
daemonReciver(messageChannel[roomId], roomObj)を実行します。
タイマーForClean(messageChannel[roomId])
 //ロビーの場合は、ロビークリーンアップコルーチンを開始します
部屋ID == ""の場合{
 CleanHall(roomObj) に移動します
}
 }
ゼロを返す
}

上記は弾幕情報を送信するためのコードの一部です。まず、各部屋には独自のメッセージ チャネルがあります。これらのチャネルはすべて、RoomID をキーとして messageChannel というマップに記録されます。メッセージを受信するたびに、それを直接チャネルに投げ込むだけです。 (これは後でデーモン コルーチンによって処理されます) ルーム チャネルがない場合は、ルーム チャネルを作成し、各ルームに対して一連のコルーチンを開始します。

3. サーバー管理

ここでの解決策は比較的簡単です。実は、上の階層、つまり部屋の上にチャットルームを設けることです。すべてのサーバーはここにアクティブに接続し、各サーバーが受信した情報はこの部屋内の他のマシンにブロードキャストされます。

4. ガーディアンコルーチン管理

ガーディアン コルーチンは、部屋内の情報の正常な配布と部屋の接続の正常な管理を確保するために、多くの些細な問題を処理します。各デーモン コルーチンの機能は次のとおりです。

1. メッセージ送信コルーチン: 各ルームに 1 つずつ装備されており、ルームに送信するメッセージをチャネルから取得し、各 RowList のメッセージ送信メカニズムを同時に呼び出します。

2. ルームソートコルーチン: 切断やルーム変更など、ノードの状態を変更する動作があるため、定期的にノードをソートしたり、現在のルームに関係のないノードを削除したりして、メッセージ送信の効率を向上させるルームソートコルーチンがあります。

[[215184]]

5. テスト関連

動作環境: クラウドホスト 8コア 16Gインスタンス

オペレーティングシステム: Centos7 (システム最適化やパラメータ調整なし)

テスト内容: 1 台のマシンが 15,000 個の Websocket 接続を確立し、メッセージを送信し、指定された部屋に入ります (すべての接続が同じ部屋に入ります)。クライアントが部屋に入り、メッセージを送信します。このメッセージは、機密語、IP、およびユーザーのブラックリストによって処理され、すべてのノードにブロードキャストされます。

テスト結果:

CPU使用率: 5%未満に保つ

メモリ使用量: 2GB (オペレーティング システムのオーバーヘッドを含む)

ネットワーク使用量: ピーク値は約10Mb/s

伝送効率: 15,000 ノードのブロードキャスト、約 100 ミリ秒 - 110 ミリ秒。

テスト結果に基づいて計算:

ピーク時の処理能力が約 60 ～ 70K の 8 コア 16G マシンでは、何の負担もなく 50K を同時に実行することが完全に可能です。

6. さらなる共有

現在、この弾幕システムの基本機能をオープンソース化しようとしています。一部抜粋しており、現在のアドレスは https://github.com/logan-go/roomManager です。興味のある読者はリンクから確認することができます。

まとめ

連射システムは、ライブ/オンデマンド ビデオにさらにインタラクティブなエンターテイメント コンテンツを追加し、初期の Station A および Station B から、現在の主流のビデオ Web サイト アプリにまで発展しました。弾幕システムを健全かつ効率的に管理する方法も、現在のビデオ業界が注意を払う必要がある技術的な仕事です。