プッシュ通知に行く

VKontakteモバイルアプリケーション（公式ではないにしても）を昨年使用した場合、この資料は今回のプッシュ通知の動作に関する小さなデータを明らかにします。 プッシャーはGoで実装され、1日あたり最大90億のプッシュを4つのターゲットプラットフォーム（GCM、APNS、MPNS、WNS）に送信します。



この投稿では、銃の全体的なアーキテクチャ、問題とその回避策、負荷、ソリューションのパフォーマンスについて話すことにしました。 たくさんの手紙と小さなコード。



アーキテクチャは単純です。何らかのイベントが発生し、それについてN番目の受信者に通知する必要があり、プッシュのコンテンツがパーソナライズされます。 プッシュのパックが各受信者（接続されているすべてのデバイス）に対して形成され、送信キューに追加されます。

pusherkaは、これらのプッシュをそこから取り出し、必要に応じて送信し、統計を更新する必要があります。



外部APIを介してのみキューから出ることができます。外部APIは、要求されたプラットフォームのみに大砲のパックを提供します（これは以下で必要です）。 すべてのプラットフォームは1つのプロセスで処理され、タイプをどのようにどのように処理するかをすでに知っているハンドラーにプッシュを分散します。





スキームは単純化されています。対応する接続​​数は、スキームのように1つずつではなく、グループ化されたブロックを行き来する必要があります。

APIからプッシュを取得する

プッシュを取得する唯一の方法はHTTPSアクセスを備えた外部APIであるため、受信は単純にhttp.Clientを介して動作し、キープアライブをサポートするためにMaxIdleConnsPerHostを増やします。 この共通のhttp.Clientを共有するいくつかのゴルーチンは、常に新しいAPIを使用してプッシュを行います。 完全なパックが（1〜3kプッシュのオーダーで）到着した場合-次のリクエストがすぐに送信され、必要なものよりはるかに小さい場合は、リクエストは少しの間停止します。

ここでは、1石で2羽の鳥を捕まえます。キューに入れるか、速度が低下し始めた外部ノードに問題がある場合は、負荷を減らします。 要求がまったく通過しない、またはハングしない場合は、一定期間（約2〜3分）後にすべての接続を閉じて、新しいhttp.Clientオブジェクトを作成します。



その結果、処理用の新鮮なデータの一定のストリームを取得し、ターゲットプラットフォーム全体で適切なキュー（通常のバッファチャネル）に分散します。

同時に、キューの満杯が監視され、キューが非常に強く詰まると（50％以上）、メーリングリストはAPIにこのタイプを要求しなくなります。

送信者をプッシュする

プッシングロジックはプラットフォームによって異なりますが、何らかの方法でプラットフォームをワーカープールに統合する共通のインターフェイスを実装します。



これらのプールのサイズは、受信したプッシュのチャネルのサイズを監視する一般的な接続マネージャーによって管理されます。 占有率がチャネル容量の10％を超える場合、マネージャーは、プッシュの受信者として登録されている特定のプラットフォームおよびモバイルアプリケーションの構成で許可されている制限内でプールを拡張します。

アプリケーションの価値が高いほど、より多くの可能性があります:)あらゆる種類のサードパーティアプリケーションにプッシュを送信する必要がなかったとしても、証明書や現在のアプリケーション登録を追跡しているわけではありません。



プールの容量は、段階的に（一度に1つではなく、パックで）増加し、2つのエクステンション間の最小時間を使用して、新しく作成されたエクステンションが動作リズムに入るようにします。 構成では、大規模な問題の場合、最大制限が非常に高く設定されます（残りの部分が必要以上に引き出されたため、配信遅延が始まる前に、なんとかして銃の80％が壊れました）。



たくさんの接続がありますが、umilit -nを1万個以上の記述子レベルに上げる必要があります。 さて、Goでは、次のように制限をすぐに許容最大値に引き上げます。

var rLimit syscall.Rlimit if err := syscall.Getrlimit(syscall.RLIMIT_NOFILE, &rLimit); err != nil { return nil, err } if rLimit.Cur < rLimit.Max { rLimit.Cur = rLimit.Max syscall.Setrlimit(syscall.RLIMIT_NOFILE, &rLimit) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定のターゲットプラットフォーム（gcmなど）の一般的なチャネルは、登録された各アプリケーションの多くのチャネル（およびそれらを処理するためのワーカープール）に分割されます。 特別なゴルーチンは、特定のアプリケーションのチャネルを介して大砲の着信ストリームを散乱させます。 これは、特定のアプリケーションのワーカーを作成するプールのスケーリングの出番です。 成長する場所がない場合、2つの選択肢があります。アプリケーションの問題は、私たちにとって重要かどうかです。

重要なアプリケーションの場合、着信プッシュチャネルのレイクを停止するだけで、詰まり始め、APIからプッシュを受信するワーカーに表示され、リクエストから特定のプラットフォームを削除するだけです。 そして、プッシュは他のプッシャーに再配布されるか、キューが拡大し始めます。これは既にモニタリングで確認できます。

また、アプリケーションが特に重要ではなく、アプリケーションの制限が使い果たされた場合、悲しいことに、プッシュは処理されずに破棄されます（ただし、これらの破棄は統計に表示されます）。



特定のアプリケーションに関する問題の数（不正な証明書、サーバーへの接続の切断、送信時のタイムアウトなど）に関する内部統計も（アプリケーション内で）保持され、「忍耐」を超えると、そのようなアプリケーションは一時的な禁止を受け取ります-すべてのプッシュは破棄されます禁止期間全体を処理します。

これは、サードパーティ製の1日アプリケーションまたは突然普及するアプリケーションで、通常の証明書がなく、ターゲットプラットフォームに対してより多くのプッシュ制限を生成する場合に非常に便利な機能です。 これらのアプリケーションの代表者に自分たちで手紙を書いて、プッシーを正常に受け取るために自宅でこの部分を終えるのが良いとほのめかした場合がありました。



もちろん、キープアライブと証明書キャッシングの名前ですべてを行う必要があります。そうしないと、常に相互作用エラーが発生し、再接続する方法がないため、アプリケーションが即座に利害関係を獲得します。



すべてのワーカーには、障害が発生した場合に内部転送バッファーがあります。これは致命的ではないと見なされます（たとえば、要求タイムアウト、または502応答コード）。 次のようになります。

 for { select { case push := <-mainChan: send(push) case push := <-resendChan: send(push) default: // ... } } func send(push Push) { if !doSmth(push) { resendChan <- push } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

selectのいくつかのオプションから選択する順序が保証されていないため、両方のチャネルから順番に選択されます。 これを超えて、再送信の数、再送信前のタイムアウトにはまだ制限がありますが、これはすでに資料の範囲を超えています。

APNS

何よりも（今のところ？）、リンゴ生産のプッシュは作業が異なり、リモート側との通信はバイナリパケットを送信するtls接続を介して行われます。



ドキュメントによると、エラーメッセージ（古い認証や誤って生成されたリクエストなどが発生した場合）は、後で同じ接続を経由するはずです。

なぜなら 各リクエストに対する回答（通常は存在しません）の待機が遅すぎるため、送信済みのプッシュのリストと確認済みではないプッシュのリスト（list.Listを使用）にすべての送信済みプッシュと少しの追加情報を追加する必要があります。 そして、答えを待ちます。 待つ時間もあまり明確ではありません。 この場合、待機時間は2秒に選択されました（発生しなかったため、十分ではありませんでした）。



応答を受信すると、何らかのエラーが発生したか、すべてが正常である（各パケットで送信される）プッシュ識別子を見つけます（はい。そのような回答オプションがあります）。 したがって、指定されたものへのすべてのプッシュは、配信時に確認済みと見なすことができます。具体的には、このプッシュは破棄されるか、再送信されます。 指定した後のすべてのプッシュは、次のエラーメッセージまで、またはタイムアウト後にリストに残ります。 2秒以上ラインに横たわっているプッシュバッグは「タイムアウト」と見なされます。



さらに、Appleサーバーへの個別の接続もあります。これを介して、未登録のアプリケーションのデータを含む着信パケットを受信します。 クライアントアプリケーションごとに1つの個別のgorutinkaによって処理されます。



その結果、受信チャネル間でのプッシュの無限転送、未確認および再送信のキューが得られます（これはプッシュごとに繰り返し発生する可能性があります）。



これに、ドキュメントに記載されていないエラーが発生する場合があることを追加できます。 または（最も一般的な）接続は、エラー通知なしで切断されます。 美しさは）



実装は、モバイルプロセッサi7-4500Uを搭載したラップトップ（もちろんテストの名前で）で1日あたり約14億apnのプッシュ（これはすべてではなく、配信または廃棄の数だけです）（1ピークあたり1秒あたり約3万〜3万3千）をポンプします。



しかし、最近学んだように、Appleは他のユーザーと同様に、httpリクエストを介してこのスキームを実装する予定です。 見てみましょう。

Gcm

最も適切なプラットフォーム。 労働者の論理は、文字通り1〜2日で書かれており、それ以来単純に機能しています。 MaxIdleConnsPerHost（数千）でさらにhttp.Clientを作成し、POST要求を送信します。 サーバーは迅速に応答し、ドキュメントは優れています。 ピーク時には、1秒あたり100kのプッシュに近づきます。

XMPPはオプションを試しませんでしたが、時間がありますので、試します。 しかし、「それは動作します-触れないでください。」

MPNS、WNS

これはすべてのオプション、特にMPNSの最悪です。 ここでは、1〜2秒間の応答を待っています（単に言葉はありません！）、エラーのあるxmlの代わりにstackracesを受け取ります（これは、1〜2秒待った後）。



最悪の部分は、時々そのような答えはプッシュが受信されなかったという意味ではないということです。 そして、私たちの側から再送信すると、デバイスに2つの同一の大砲が到着します。 そして、結局のところ、人々は原則として彼らの不在よりも2プッシュに動揺しています。



それとは別に、証明書を使用して送信するために必要なTLS再ネゴシエーションについて説明する価値があります（証明書がないとすぐに送信制限に達する）が、Goではサポートされておらず、通常どこでも飲まれます。



これを行うには、cgoラッパーを介してcurl経由でプッシュを送信する必要があります。 しかし、ソリューションの安定性はまあまあです。数百万のリクエストごとに、システムライブラリ内のどこかでsigsegvをキャッチする機会があります。 この問題を一時的に解決するために、cgoを介したcurlの操作は、同じGoの別の小さな（〜400行）アプリケーションに移動しました。これは、原則= push "http server => https curl tls renego client" => MSサーバーで動作します。

そのようなアプリケーションを備えた別の小さなプールが起動され、そのマネージャーの監視が低下します。 これらの中間プロキシは、外部サーバーの応答でメインプッシュに応答し、応答時間、プロキシ応答コード（外部サーバーの応答コードに加えて）など、デバッグおよび統計用のヘッダーにギャグを追加します。 これにより、不安定な環境で確実にプッシーを送信できます。



ところで、MaxIdleConnsPerHostの代わりに、CURLOPT_MAXCONNECTSをさらに設定することを忘れないでください。そうしないと、CPUで再び離陸しません。



ただし、このプラットフォームでは、2つの異なる独立した要求（およびWNSの3つ）によってプッシュおよびバッジテキスト（アプリケーションアイコンの数）を設定する必要があります。 上記の待機時間とグリッチに2を掛けて（3）進んでください...

統計収集

どのように連携しても、統計が必要です。 そして、詳細であればあるほど良いです。

キュー充填コード（APIの前のコード）、APIメソッドの動作、および配布アプリケーション自体の両方が監視されます。



主な特徴は送信時間です：プッシュ生成の瞬間から特定のサイトのサーバーへの確認された送信までに経過する時間。 高速GCMおよびAPNSの場合、処理時間全体の平均時間は約60〜100ミリ秒です。MPNS/ WNSの場合はすべて幸運です。MSサーバーを動作速度より速く送信することはできません。



以下の統計が維持されます。

• 有効期限が切れた送信済み、拒否済み、送信時にエラーを返した数（トークンを送信し、送信キューに残っている間はトークンを破棄し、送信を試みずにエラーを取得し、接続をリセットする必要があります）;
• 処理時間：各プラットフォームおよび各アプリケーションの最小/最大/平均
• プロセスの稼働時間、cpuの使用（ユーザー、システム、io、アイドルで分割）、開いているファイル記述子の数、メモリ消費（rss）、gcの合計実行時間、および最後の起動の最小/最大/平均

これらはすべて同じAPIで収集され、バッチで送信されます。



ただし、各ゴルーチンからのプッシュごとに統計情報を保持するのは非常に高価です（そして、数千もあります）。 したがって、すべてのワーカーは最初にローカルで統計を収集し、たまに（数秒に1回）共通の場所にそれをマージします。 サンプルコード：

 type Stats struct { sync.RWMutex ElapsedTime ... Methods ... AppID ... ... } addStatsTicker := time.Tick(5 * time.Second) for { select { case <-addStatsTicker: globalStats.Lock() gcm.stats.Lock() mergeStatsToGlobal(&gcm.stats) cleanStats(&gcm.stats) gcm.stats.Unlock() globalStats.Unlock() case push := <-mainChan: //   ,      gcm.stats.Lock() statsMethodIncr(&gcm.stats, push.Method) statsAppIDIncr(&gcm.stats, push.AppID) gcm.stats.Unlock() send(push) // ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

選択的ロギング

一般的な統計に加えて、銃を使用すると、選択した銃を処理する際のすべての重要な手順を記録できます。



特別なフラグを持つプッシュがキューから送信される場合、このプッシュを処理するためのすべてのアクションはロガーのデバッグチャネルに送信され、ロガーはこれらのログをすべてAPIに送信します。 成功/エラーのファクトだけでなく、すべての重要な詳細も収集されます：選択時の主要な分岐、変数とバッファの値、ミリ秒の正確さの正確な時間。 これらすべてにより、これらのログ自体の問題点を「正確に把握することができます。昨日誰かがそのようなときにプッシュしなかった」、「2人が同じようになった」などの問題があります。

これはすべて、「ローカル」ログに追加されるものであり、一般に、銃が実行されているマシンの制限を残しません。



そのようなもの。 これらはすべて何万ものゴルーチンで問題なく機能します。



PS多分後で、舞台裏にたくさん残されています...



PPS ここから撮影されたホリネズミの写真。