Golang 分散マーケットプッシュのパフォーマンスボトルネックを最適化する

[[409249]]

この記事はWeChatの公開アカウント「Coder's Peach Blossom Land」から転載したもので、著者はFengyunです。この記事を転載する場合は、Coder's Peach Blossom Garden の公開アカウントにご連絡ください。

最近、私は市場情報プッシュシステムを最適化しており、皆さんと共有できる最適化の経験がたくさんあります。最も明らかなパフォーマンスの改善はレイテンシです。単一ノードに 80,000 のクライアントがある場合、レイテンシは 1500 ミリ秒から 40 ミリ秒に最適化されます。以下は、イントラネットモッククライアントから取得したストレステストデータです。

サブスクライブするクライアントの数については特にテストを行っていませんが、ネットワークが弱い場合、1 台のマシンに 80,000 のクライアントがあっても問題ありません。現在、柔軟に拡張・拡大できる kubenetes デプロイメントソリューションが使用されています。

アーキテクチャ図

Push-gateway は、いくつかの機能を備えたプッシュゲートウェイです。最初の機能は認証用です。 2 つ目は複数のプロトコルにアクセスするためのものです。 websocket、grpc、grpc-web、sse のサポートを実装しました。 3 番目は、ポリシースケジューリングとアフィニティバインディングを実装することです。

プッシュサーバーは、サブスクリプション関係を維持し、MQ からの新しいメッセージを監視して、ゲートウェイにプッシュするプッシュサービスです。

問題1: 同時マップ操作によるロック競合と遅延

プッシュされたサービスは、通常、ネストされたマップ構造によって表されるサブスクリプション関係を維持する必要があります。これにより、マップの同時実行の競合時にロックの競合と高レイテンシの問題が発生します。

 //xiaorui.cc
 { "topic1" : { "uuid1" : クライアント1、 "uuid2" : クライアント2}、 "topic2" : { "uuid3" : クライアント3、 "uuid4" : クライアント4} ... }

4 つのマップはビジネスに応じて分割されていますが、サブスクリプション関係はネストされています。直接ロックすると他のコルーチンがブロックされ、レイテンシが高くなります。

ロック操作マップは非常に高速であるはずですが、なぜブロックされているのでしょうか?上記で、マップはトピックとクライアントリスト間のサブスクリプション関係を格納するために使用されると述べました。プッシュするときは、トピックのすべてのクライアントを取得して、通知を 1 つずつ送信する必要があります。 (ここでの送信は io.send ではなく chan send であり、各クライアントはバッファリングされた chan にバインドされます)

解決策: 256 個のマップと読み取り/書き込みロックを各ビジネスに分割し、ロックの粒度を 1/256 に減らします。この方法に加えて、当初はクライアントリストを新しいスライスで返すことも試みましたが、これにより GC 負荷が発生し、テストの結果、推奨されませんでした。

 //xiaorui.cc 
 
同期RWMutex
 map[文字列]map[文字列]クライアント
 
これを変更してください
 
 m *シャードマップ.シャードマップ

セグメントマップライブラリはgithub[1]にプッシュされました。興味のある方はぜひご覧ください。

質問2: シリアルメッセージ通知を同時モードに変更する

簡単に言うと、プッシュサービスでトピックと 10,000 個のクライアント Chan 間のマッピングを維持します。トピックからのメッセージが MQ から受信されると、これらの 10,000 個のクライアントチャネルに通知されます。

クライアントの chan 自体に大きなバッファがあり、送信関数もブロックを回避するために select default を使用します。しかし、実際には、chan を連続して送信するのは非常に時間がかかります。チャネルの最下層では、チャネルの goroutine を待機し、それを runq にプッシュするために goready が必要です。

以下は私が書いたベンチマーク[2]で、シリアル操作と同時操作の時間消費を比較するために使用できます。 Mac の CPU 周波数は高いため、Mac 上では効果はあまり顕著ではありませんが、サーバー上では明らかです。

シリアル通知、全クライアントの chan を取得して送信します。

 for _、notifier := range notifiers {
    s.directSendMesg(通知者, メッセージ)
 }

同時送信。ここでは、コルーチンプールを使用して morestack の消費を回避し、sync.waitgroup を使用して非同期待機を実装します。

 //xiaorui.cc 
 
通知:= []*mapping.StreamNotifier{}
 // 変換スライス
for _、notifier := range notifierMap {
    通知者 = append(通知者, 通知者)
 } 
 
 
 // 最適化: 直接マップ構造体
タスクチャンク:= b.splitChunks(通知、バッチチャンクサイズ) 
 
 
 // 同時送信チャネル
wg := sync.WaitGroup{}
 _の場合、チャンク:=範囲taskChunks{
    chunkCopy := chunk // スライスレプリカ
    WG。追加(1)
    b.送信ブロック(
        関数() {
 _の場合、notifier := range chunkCopy {
                b.directSendMesg(通知、メッセージ)
            }
            wg.完了()
        },
    ）
 }
 wg.Wait()

オンライン監視パフォーマンスによると、レイテンシは 200 ミリ秒から 30 ミリ秒に短縮されました。ここでより詳細な最適化を行うことができます。クライアント数が 5,000 未満の場合は、直接シリアルで呼び出すことができます。それ以外の場合は、同時に呼び出すことができます。

問題3: タイマーが多すぎるとCPUオーバーヘッドが増加する

マーケットプッシュにはハートビート検出やタスク時間制御が多数ありますが、それらはすべてタイマーに依存しています。 Go 1.9 以降、単一の timerproc が複数の timerproc に変更され、ロックの競合が減少しました。ただし、クアッドヒープデータ構造の時間計算量は依然として複雑であり、高精度によって発生するツリーおよびロック操作は依然として頻繁に発生します。

したがって、ここでは上記の問題を解決するためにタイムホイールが使用されます。データ構造は単純なループ配列とマップに変更され、時間精度は第2レベルに弱められています。時間差はビジネス上許容範囲内です。

Golangタイムホイールのコードはgithub[3]にプッシュされています。タイムホイールの多くのメソッドは、golang のタイムネイティブライブラリと互換性があります。興味のある方はぜひご覧ください。

問題4: 複数のコルーチンがチャネルを読み書きするときに送信クローズパニックが発生する

解決策は非常に簡単です。チャネルを直接使用しないでください。代わりに、トリガーをカプセル化します。クライアントが閉じられているときは、積極的にチャンを閉じないでください。代わりに、トリガー内の ctx を閉じて、トピックとトリガー間のマッピングを直接削除します。

 //xiaorui.cc 
 
 // トリガー構造
StreamNotifier構造体型{
    GUID文字列
    キュー チャン インターフェース{} 
 
 
    閉じた int32
    ctx コンテキスト.コンテキスト
    キャンセルコンテキスト.CancelFunc
 } 
 
 
 func (sc *StreamNotifier) IsClosed() bool {
    sc.ctx.Err() == nilの場合{
戻る 間違い 
    }
戻る 真実 
 } 
 
 ...

質問5: grpcスループットパフォーマンスの向上

grpc は http2 プロトコルに基づいて実装されており、http2 自体はストリームの多重化を実装しています。一般的に、イントラネット内の 2 つのノードは、パフォーマンスの問題が発生することなく、単一の接続でネットワーク帯域幅全体を使用できます。ただし、golang で実装された grpc には、さまざまなロック競合の問題があります。

最適化するにはどうすればいいですか?ロック競合の競合の可能性を回避するために、複数の grpc クライアントを開きます。テストの結果、qps は 80,000 から約 200,000 に大幅に改善されました。

以前に書かれたgrpcパフォーマンステスト[4]を参照してください。

問題6: コルーチンの数を減らす

イベントを待機するコルーチンが多すぎると、メモリを消費するだけでコルーチンをスケジュールできず、実行時のパフォーマンスも低下しないので問題ないと考える人もいます。この記述は間違いです。スケジュール設定できず、メモリを占有するだけのように見えますが、GC に大きなオーバーヘッドが発生します。したがって、アイドルコルーチンをあまり多く開かないでください。たとえば、大きなコルーチンプールを開かないでください。

プッシュアーキテクチャでは、プッシュゲートウェイからプッシュサーバーへの接続は、少数の接続だけでなく、数十のストリームを必要とします。私たちは、12 を超えるストリームで実行される大量のメッセージを独自に実装し、通知をスケジュールします。 golang grpc ストリーミングの実装では、各ストリーミング要求でイベントを待機するためのコルーチンが必要です。したがって、ストリームチャネルを共有すると、コルーチンの数も削減できます。

質問7: GCの問題

頻繁に作成される構造の場合、キャッシュには sync.Pool が使用されます。一部のビジネスキャッシュは、以前はリンクリストを使用して保存されていました。新しいデータが継続的に更新されると、新しいオブジェクトが絶えず作成され、GC に影響します。したがって、ホットキャッシュを実装するには、再利用可能な循環配列が使用されます。