ビジネスフォームの違いと技術的な課題
まず、ビジネス形態に関しては、従来のインスタントメッセージングのシナリオとは異なり、ライブインタラクションのピークトラフィックは「短時間で迅速な集約」のバーストがあり、トラフィックはホストの開始と終了に続いて急激に変動します。また、ライブ放送のやり取りは部屋に基づいており、従来のグループチャットビジネスやチャットルームビジネスにも数千人、数千人のチャットルームがありますが、ライブ放送ルームの数十万人、数百万人の規模と比べると、まだ重要ではありません。の。また、時間制限やセレブ効果により、生放送での会話や会話への意欲が高まり、結局「この村を逃したらお店がない」かもしれません。大きな部屋のサイズと注目度の高い相互作用によって引き起こされる問題の1つは、メッセージプッシュダウンの同時実行ピークです。ここでは、数字を使用して直感的に感じることができます。ポイントツーポイントのチャットシーンでは、2人が10秒ごとに単語を言う場合、1秒あたりにプッシュされるメッセージの数は実際にはわずか0.1です。グループチャットまたはチャットルームのシーンでは、500人のグループを想定しています。グループの全員が10秒ごとに文を言う場合、1秒あたりにプッシュされる実際のメッセージ数は500/10 * 500 = 25000です。ライブルームの全員が10秒ごとの場合、オンラインで10w人がいるインタラクティブなライブシーンの場合1秒あたり1文で、1秒あたりに生成できるプッシュダウンの実際の数は100000/10 * 100000 = 10億です。もちろん、ここではこの例を使用して理論値を計算し、ライブインタラクションと通常のチャットシーンでの同時実行圧力の違いを理解できるようにします。実際、10万人のライブ放送室は、一般的にそれほど高度なスピーチやインタラクションがないため、実現できたとしても、サーバー側で限定的に選択的に破棄されます。基本的にサーバーの耐久性がこのレベルに達することは不可能であると考えられている一方で、すべてのメッセージをプッシュダウンできたとしても、クライアントは1秒あたり10,000メッセージの受信を処理できません。クライアントの場合、通常は1秒ごとに受信されます。数十のメッセージがすでに制限されています。したがって、ビジネスフォームが異なるため、ライブインタラクションでの高い同時実行性の課題は、従来のインスタントメッセージングシナリオよりもはるかに大きくなります。
ライブインタラクションの高い同時応答
ライブインタラクションの高い同時実行性によってもたらされる技術的な課題に関して、アーキテクチャの観点からのソリューションは何ですか？まず、ライブインタラクションにおける比較的大きな課題である高い同時実行性のプレッシャーを分析しましょう。
オンラインステータスローカリゼーション
実際、ライブインタラクションの同時実行圧力は、主に、メッセージが1つのメッセージからメッセージプッシュダウンリンクで100,000にファンアウトされた後の部分から発生し、メッセージがファンアウトする前の相対的な圧力は大きくありません。次に、最適化の焦点は主にファンアウト後のロジックにあります。通常のメッセージチャットのシナリオでは、ファンアウト後のプッシュロジックは主に次のとおりです。「チャットレシーバーがサーバーに接続されている場所を確認してから、メッセージを配信します。最後に、アクセスサーバーは長い接続を介して配信します。」この方法を使用してライブインタラクティブメッセージのプッシュダウンを処理する場合、一般的なプロセスは次のようになります。
まず、ユーザーがゲートウェイマシンにアクセスしてライブ放送室に入ると、ゲートウェイがユーザーのオンラインステータスを報告します。この時点でユーザーAが弾幕メッセージを送信すると、このメッセージはビジネスロジック処理レイヤーで処理され、ビジネスロジック処理が行われます。維持されたばかりのユーザーのオンラインステータスを照会することにより、レイヤーは、ユーザーAのライブルーム内の他のユーザーがオンになっているゲートウェイを対応して照会し、対応するメッセージをこれらのユーザーが配置されているゲートウェイサーバーに配信します。最後に、ゲートウェイサーバーはそれをにプッシュします。ユーザーのデバイス。
ここでの問題の1つは、通常のチャットシナリオでは、リソースの浪費を回避するために正確な配信を実行するために、中央の「オンライン状態」が通常維持されることです。ロジックレイヤーは、配信の受信者を決定した後、この「オンライン状態」を使用します。対応する受信者がいるゲートウェイマシンにクエリを実行すると、このゲートウェイマシンにメッセージを配信するだけで済みます。
しかし、ライブインタラクティブシーンの場合、このモードを採用すると、10w人の部屋では、各メッセージがオンラインステータスを10w回クエリする必要があります。この大きさは非常に大きいため、この場所がボトルネックになることがよくあります。
では、ライブのインタラクティブシーンでは、この「正確な配信」をどのように最適化する必要がありますか？一緒に考えてみましょう。一般的に言って、多数のユーザーと数十万人のオンラインのライブ放送室でさえ、部屋のユーザーは実際には複数のゲートウェイに比較的「ステートレス」に散らばっています。
ゲートウェイが50あると仮定すると、10ワットの部屋の場合、各ゲートウェイのこのライブルームには平均で2,000人のユーザーがいるはずです。このライブルームのユーザーがどこにいるかを「正確に」確認する必要はありません。ゲートウェイマシンでは、このライブブロードキャストルーム内のすべてのメッセージをすべてのゲートウェイマシンに「配信」するだけでよく、各ゲートウェイマシンは、ローカルの「ルーム内のどのユーザーがこのマシンに接続されているか」を維持するだけで済みます。ゲートウェイマシンは、このマシンの現在のライブブロードキャストルームにいるオンラインユーザーにメッセージをプッシュダウンします。ライブブロードキャストメッセージの最適化されたプッシュダウンアーキテクチャは、次のようになります。
まず、各ゲートウェイマシンは、起動時にグローバルメッセージキューにサブスクライブします。ユーザーがライブブロードキャストルームに入ると、各ゲートウェイマシンのローカルマシンでオンラインステータスを維持します。同様に、ユーザーAがこの時点で通知を送信するとします。画面メッセージ、このメッセージはビジネスロジック処理レイヤーで処理され、ビジネス処理レイヤーによってゲートウェイマシンによってサブスクライブされたグローバルメッセージキューに配信されるため、すべてのゲートウェイマシンがメッセージを受信できます。最後に、各ゲートウェイマシンこのマシンによって維持されているライブルームのオンラインユーザーによると、メッセージはユーザー機器にプッシュダウンされます。
この最適化により、ライブメッセージのファンアウトをビジネスロジック処理レイヤーからゲートウェイレイヤーに延期することと同等であり、ファンアウト後のプッシュダウンは外部の状態サービスに依存する必要がないため、ライブインタラクティブメッセージのプッシュダウン機能を大幅に向上させることができます。
ライブブロードキャストルームでのピアツーピアメッセージのファンアウトプッシュダウンの数が非常に少ない場合（アンカーがユーザーを禁止した後にユーザーに送信されるリマインダーメッセージなど）、ある程度のリソースの浪費がある可能性がありますが、そのようなメッセージの数は比較的多いです。少ないですが、全体的なメリットはまだ比較的大きいです。
マイクロサービス分割
ライブインタラクションの同時実行性の高いシーンでは、アーキテクチャと設計を最適化するだけでは不十分です。たとえば、プッシュダウンメッセージには、スタンドアロンのボトルネックが発生しやすいゲートウェイ帯域幅、PPS、CPUなどの制限もあります。したがって、大規模なライブイベントが発生する場合、ボトルネックが発生しやすいこれらのサービスを水平方向に拡張する必要があります。
さらに、拡張のコストを管理するために、ライブインタラクティブシーンでコアサービスと非コアサービスを区別して、コアサービスのみの拡張をさらにサポートしたいと考えています。同時に、コアサービスについては、「ボトルネックになりやすい」ビジネスと「基本的にボトルネックではない」ビジネスを分離する必要があります。
これらの考慮事項に基づいて、ライブインタラクションのサーバー側全体で「マイクロサービス分割」変換を実行する必要があります。まず、ライブインタラクティブビジネス全体のコアサービスと非コアサービスを分析します。例：弾幕の送信、報酬、ギフト、いいね、メッセージのプッシュダウンの送信、これらはよりコアです。ライブブロードキャストの再生やサードパーティシステムの同期など、これらのサービスがライブブロードキャスト中にコアに干渉することは望ましくありません。インタラクティブなメッセージと動作の送受信。
さらに、コアサービスでは、メッセージの送信と処理は一般にボトルネックになりがちではありません。10w人のライブブロードキャストルームでの1秒あたりのインタラクティブな動作は一般に1,000未満です。このステップでは、ボトルネックは望ましくなく、傾向があります。ニュースプッシュダウン事業はまちまちです。したがって、アクセス層からビジネス処理層へのメッセージの送受信を分離して分割することができます。システム全体がマイクロサービスに変換されると、次のようになります。
コアサービスは、直接影響を受けないように、DBスレーブライブラリまたはメッセージキューを介して非コアサービスから分離されます。ボトルネックが発生しやすい長時間接続されたサービスは個別に展開され、メッセージを個別のチャネルに送信するアップリンク操作から分離されます。このように、アップストリームの動作を分離し、ダウンストリームのプッシュチャネルの影響を回避できる一方で、軽量で独立した長期接続サービスは拡張に非常に便利です。
自動スケーリング
マイクロサービスを分割した後、分割されたサービスを拡張する方法を検討する必要があります。これは、通常、注目度の高いライブブロードキャストがない場合、コスト要因を考慮すると、サービス全体のクラスターサイズは一般に大きすぎないためです。大規模なライブイベントが発生した場合、サービスまたはマシンのいくつかの重要な指標を監視して、熱がボトルネックポイントに近づいたときに容量を拡張できます。プロセス全体は実際には手動で参加する必要がなく、完全に自動化できます。ライブインタラクティブシーンのモニタリングインジケータは、一般に2つのカテゴリに分類できます。
ライブ放送室の人数、メッセージの送信とシグナリングのQPSと時間の消費、メッセージの送受信の遅延などのサービスパフォーマンス指標。
マシンパフォーマンスインジケータは、主に、帯域幅、PPS、システム負荷、IOPSなどを含む一般的なマシンパフォーマンスインジケータです。
収集したビジネスパフォーマンスインジケーターとマシンパフォーマンスインジケーターを、シミュレートされたオンラインライブルームデータと組み合わせて使用して、ストレステストを実行し、スタンドアロン、中央リソース、および依存サービスのボトルネックの重要なポイントを見つけ、自動拡張と縮小をトリガーする対応するインジケーターを作成します。監視しきい値。
自動スケーリングのおおよそのプロセスは次のとおりです。
自動拡大と自動縮小の全体的なプロセスを理解します。拡張中に注意が必要な別の問題があります。ライブインタラクティブニュースのプッシュダウンについては、長期接続サービスにより、部屋とユーザー間の長期接続が維持されます。ここでの問題は、拡張前のマシンの既存の長期接続が高水位であった可能性があるが、新しく拡張されたマシンであるということです。それはユーザー接続を運ばず、長い接続サービスのフロントエンドの負荷分散層では、バックエンドの長い接続入力マシンがすでに多くの接続を運んでいるかどうかに関係なく、それらのほとんどはスケジューリングに通常のラウンドロビンアルゴリズムを使用します。新しい接続要求は依然として古いマシンと新しいマシンに均等に分散されるため、新しいマシンが十分に活用されていない間、古いマシンは時期尚早にボトルネックに到達します。この場合、負荷分散層がカスタムの複雑な平衡アルゴリズムをサポートしていても、トラフィックの不均衡の問題を解決できない可能性があります。多くの場合、ロードバランシングレイヤー自体も拡張する必要があり、カスタムバランシングアルゴリズムはロードバランシングマシンでのみ有効であり、グローバルなスケジューリングとバランシングを実際に実現することはできません。
より良い解決策は、ユーザー接続の入り口を引き継ぎ、最も外側の入り口でグローバルスケジューリングを実行することです。たとえば、長い接続を確立する前に、クライアントは最初にエントリスケジューリングサービスを使用して、この接続に接続する必要があるエントリIPを照会します。このエントリスケジューリングサービスでは、特定のバックエンドアクセスレイヤマシンの特定のビジネスおよびパフォーマンスインジケータに従って、スケジュールの重みをリアルタイムで計算します。負荷が低いマシンは重み値が高く、ポータルスケジューリングサービスによって優先アクセスIPとして発行されます。負荷が高いマシンは重み値が低く、後続の新しい接続は比較的少なくなります。このようにして、基本的に、新しいトラフィックに対する新旧のマシンの負荷の不均衡の問題を解決できます。
概要
いくつかの側面からターゲットを絞った最適化を実行できます。
まず、オンラインステータスのローカライズされたメンテナンスにより、リモートリソースへの依存が減り、単一マシンの処理機能が向上します。
次に、サービス全体を分割し、コアサービスと非コアサービスを区別し、「ボトルネックになりやすい」サービスを分離します。
次に、ビジネスとマシンの指標を収集することにより、サービスを自動的に拡張および縮小する容量評価モデルが確立されます。
最後に、バックエンドマシンの負荷レベルに応じて、全体的な状況がディスパッチされ、サービスエントランスが接続されて、拡張後の新しいマシンと古いマシンの間の新しいアクセストラフィックの不均衡なフローの問題が解決されます。