前回遠心分離機について書いてから時間が経ちました。この期間には多くの変更がありました。以前の記事（ 1、2 ）で説明されていたものの多くは忘却に沈みましたが、プロジェクトの本質と考え方は同じままでした-それはWebブラウザーから接続されたユーザーにリアルタイムメッセージを送信するためのサーバーです。サイトでイベントが発生し、ユーザーの一部に即座に通知する必要がある場合、このイベントを遠心分離機に投稿し、目的のチャネルにサブスクライブしているすべての関心のあるユーザーに送信します。最も単純な形式で、これを図に示します。

プロジェクトは、Tornado非同期Webサーバーを使用してPythonで記述されています。サイトのバックエンドがPythonで書かれていない場合でも使用できます。現時点での遠心分離機についてお話したいと思います。

Pythonパッケージのインストールに精通している場合、実際にプロジェクトを試すのは簡単です。 virtualenv内：

$ pip install centrifuge

打ち上げ：

 $ centrifuge

その後、開始したばかりのCentrifugeプロセスの管理インターフェースがhttp：// localhost：8000で利用可能になります。

この記事のために、 Heroku-habrifuge.herokuapp.comで Centrifugeインスタンスを起動しました。パスワードはhabrahabrです。あなたの誠実さと慎重さを願っています-デモは、すべてを壊し、他の人がプロジェクトを評価するのを妨げる試みから決して保護されません。すべての結果を持つ無料の恐竜で起動しました。もちろん、Herokuはこの種のアプリケーションをホストするのに最適な場所ではありませんが、デモンストレーションの目的のためには最適です。

少なくともPythonのオープンソースの世界では、Centrifugeの類似物はないと言うなら、私は真実からそれほど遠くないと思います。私がそう思う理由を説明しようと思います。リアルタイムイベントをサイトに追加する方法は多数あります。思い浮かぶものから：

自立型非同期サーバー。
クラウドサービス（pusher.com、pubnub.com）;
gevent（gunicorn、uwsgi）;
Nginxモジュール/拡張機能。
BOSH、XMPP。

JavaScriptにはMeteorがあり、Derbyはまったく異なるアプローチです。また、すばらしいFayeもあります。これは、JavaScriptまたはRubyバックエンドとシームレスに統合されるサーバーです。しかし、これはNodeJSとRubyのソリューションです。遠心分離機は、上記のアプローチの最初を実行します。スタンドアロンの非同期サーバー（およびクラウドサービス）の利点は、既存のバックエンドのコードと哲学を変更する必要がないことです。これは、たとえば標準のPythonライブラリにパッチを適用するなど、Geventを使用することを決定するとすぐに発生します。別個のサーバーを使用するアプローチにより、既存のバックエンドアーキテクチャにリアルタイムメッセージを簡単かつ簡単に統合できます。

短所-同様のアーキテクチャの出力は、少し「切り捨てられた」リアルタイムであることが判明しました。 Webアプリケーションは、イベントを生成するクライアントからのHTTPリクエストに耐える必要があります。新しいイベントは最初にバックエンドに到達し、検証され、必要に応じてデータベースに保存され、その後のみCentrifugeに送信されます（pusher.com、pubnub.com、その他）。ただし、ほとんどの場合、この制限はWebのタスクには影響しません。1人のクライアントが非常に多くのイベントを生成する動的なリアルタイムゲームは、この問題の影響を受ける可能性があります。そのような場合、おそらく、リアルタイムアプリケーションとバックエンドの緊密な統合が必要です。おそらくgevent-socketioのようなものです。サイト上のイベントがクライアントではなく、バックエンド自体によって生成される場合、この場合、上記の欠如は役割を果たしません。

Pythonのオープンソースの世界にはCentrifugeの類似物がないと言っても、Webソケットとポリフィルを介してメッセージを送信するスタンドアロンサーバーの実装が他にないという意味ではありません。箱から出して、実際に使用するほとんどの問題を解決するようなプロジェクトは見つかりませんでした。

検索エンジン「 python real-time github 」と入力すると、同様のサーバーの例へのリンクが多数表示されます。しかし！これらの結果のほとんどは、問題を解決するためのアプローチを示しているだけであり、さらに深くなることはありません。 1つのプロセスが欠落しているため、何らかの方法でアプリケーションをスケーリングする必要があります-プロジェクトドキュメントで、この目的でPUB / SUBブローカーを使用する必要があると言われている場合-Redis、ZeroMQ、RabbitMQ-これは事実ですが、自分で実装する必要があります多くの場合、このような例はすべて、新しい接続オブジェクトが追加され、この接続セットからすべてのクライアントに新しいメッセージが送信される、タイプセットのクラス変数に限定されます。

遠心分離機の主な目標は、現実世界の問題をすぐに解決できるようにすることです。詳細に対処する必要があるいくつかのポイントを見てみましょう。

ポリフィル

Webソケットだけでは十分ではありません。信じられない場合は、Socket.ioの開発者の1人から「Websuckets」という名前で話を聞いてみてください。ここにスライドがあります。そして、ここにビデオがあります：

もちろん、Webソケットの使用が重要なプロジェクト（再び、動的なリアルタイムゲーム）があります。遠心分離機はSockJSを使用して、古いブラウザーのWebソケットをエミュレートします。これは、xhr-streaming、iframe-eventsource、iframe-htmlfile、xhr-polling、jsonp-pollingなどのトランスポートを使用してIE7までのブラウザーをサポートすることを意味します。このために、SockJSサーバーの素晴らしい実装-sockjs-tornadoが使用されます。

また、「クリーン」なWebソケットを使用して、SockJSプロトコルでの対話をラップせずに遠心分離機に接続できることにも注意してください。

リポジトリには、シンプルで直感的なAPIを備えたJavaScriptクライアントがあります。

スケーリング

複数のプロセスを開始できます-それらはRedis PUB / SUBを使用して相互に通信します。遠心分離機は、何百万人もの訪問者がいる巨大なサイト内に設置されるふりをしていないことに注意したい。おそらく、そのようなプロジェクトでは、同じクラウドサービスまたは独自の開発という別のソリューションを見つける必要があります。しかし、大多数のプロジェクトでは、RedisのPUB / SUBメカニズムで接続されたバランサーの背後にあるいくつかのサーバーインスタンスで十分です。たとえば、1つのインスタンス（この場合はRedisは不要）があり、平均メッセージ送信時間が50ミリ秒未満で、1000の同時接続に問題なく耐えることができます。

ちなみに、Mail.Ru Groupイントラネットで使用されているCentrifugeの1週間の操作用のGraphiteのグラファイトを次に示します。青い線はアクティブな接続の数、緑の線はミリ秒単位のメッセージ送信の平均時間です。真ん中は週末です。 :)

認証と承認

遠心分離機に接続することにより、プロジェクトの秘密鍵に基づく対称暗号化を使用してトークン（HMAC）を生成します。このトークンは接続時に検証されます。また、接続すると、ユーザーIDと、オプションでユーザーに関する追加情報が送信されます。したがって、遠心分離機は、プライベートチャネルへの接続を処理するためにユーザーについて十分に認識しています。このメカニズムは、本質的にJWT （JSON Web Token）と非常によく似ています。

最近の革新の1つに注目したいと思います。以前の記事で述べたように、クライアントがプライベートチャネルをサブスクライブすると、CentrifugeはアプリケーションにPOSTリクエストを送信し、そのようなIDを持つユーザーが特定のチャネルに接続できるかどうかを尋ねます。これで、サブスクリプション時に、Webアプリケーションがまったく関与しないプライベートチャネルを作成できます。チャンネルに好きな名前を付け、最後に特殊文字＃の後に、このチャンネルの購読を許可されているユーザーのIDを記述します。 ID 42のユーザーのみがこのチャンネルにサブスクライブできます。

 news#42

そして、あなたはこのようにそれをすることができます：

 dialog#42,56

これは、ID 42および56の2人のユーザー向けのプライベートチャネルです。

最近のバージョンでは、接続の有効期限メカニズムも追加されました-ほとんどのプロジェクトでは必要ないため、デフォルトではオフになっています。このメカニズムは実験的であると考えるべきです。

おそらく、プロジェクト開発の過程で、2つの最も難しい決定がありました：複数のプロセス間で状態を同期する方法（最終的に、Redisを使用する最も簡単な方法が選択されました）と、非アクティブ化（禁止、削除）される前に遠心分離機に接続するクライアントの問題Webアプリケーション。

ここでの難点は、Centrifugeがプロジェクト設定とプロジェクト名前空間以外のすべてを永続的なストレージに保存しないことです。そのため、無効なクライアントを確実に切断する方法を考え出す必要がありましたが、CentrifugeおよびWebアプリケーションのダウンタイムが発生する可能性があるため、これらのクライアントの識別子またはトークンを保存する機能はありませんでした。この方法は最終的に発見されました。ただし、実際のプロジェクトに適用することはまだ可能でないため、実験的な状態です。解決策が理論的にどのように機能するかを説明しようとします。

前に説明したように、ブラウザーからCentrifugeに接続するには、接続アドレスに加えて、いくつかの必須パラメーター（現在のユーザーIDとプロジェクトID）を渡す必要があります。また、接続パラメーターには、Webアプリケーションのバックエンドにあるプロジェクトの秘密鍵に基づいて生成されたHMACトークンが必要です。このトークンは、クライアントから渡されたパラメーターの正確性を確認します。

問題は、以前にそのようなトークンを受け取ったクライアントは、問題なく将来トークンを使用できることです。つまり、パブリックチャネルにサブスクライブし、そこからメッセージを読み取ります。メッセージは最初にバックエンドを通過するため、書かないことをお勧めします！これは、多くの公開サイトの通常の状況です。ただし、追加のデータ保護メカニズムが必要であると確信しました。

そのため、接続時に必要なパラメーターの中で、 timestamp

パラメーターが表示されました。これらはUnix秒（ str(int(time.time()))

）です。このtimestamp

、トークン生成にも関係します。つまり、接続は次のようになります。

 var centrifuge = new Centrifuge({ url: 'http://localhost:8000/connection', token: 'TOKEN', project: 'PROJECT_ID', user: 'USER_ID', timestamp: '1395086390' });

プロジェクトの設定に、質問に答えるオプションが表示されました。新しい接続が正しいと見なされる秒数です。遠心分離機は、期限切れの化合物を定期的に検索し、検証のために特別なリスト（実際に設定）に追加します。一定の時間間隔で、Centrifugeは検証を必要とするユーザーIDのリストとともにアプリケーションにPOSTリクエストを送信します。応答するアプリケーションは、このチェックに合格しなかったユーザーIDのリストを送信します。これらのクライアントはすぐに遠心分離機から強制的に切断され、クライアント側で自動再接続は行われません。

しかし、それほど単純ではありません。クライアントのJavaScriptなどを修正した「攻撃者」は、強制的に追い出された後、すぐに再接続する可能性があります。接続パラメータのtimestamp

がまだ有効な場合、接続は受け入れられます。ただし、次の検証サイクルでは、接続の有効期限が切れた後、同じメカニズムによってそのIDがWebアプリケーションに送信され、ユーザーは無効であると言われ、その後は永久に切断されます（ timestamp

が既に切れているため）。つまり、クライアントが公共チャンネルから読み続ける機会がある時間にはわずかなギャップがあります。しかし、その値は設定可能です-実際の非アクティブ化の後、ユーザーがしばらくの間チャンネルからメッセージを読むことができるなら、それはまったく怖くないと思います。

おそらく、スキームを使用すると、このメカニズムを理解するのがはるかに簡単になります。

展開する

リポジトリには、Centrifugeの展開に使用する実際の構成ファイルの例があります。スーパーバイザー（監督者）の下でNginxのCentOS 6で実行します。仕様ファイルがあります-CentOSがあれば、それに基づいてrpmをビルドできます。

モニタリング

Centrifugeの最新バージョンには、さまざまなメトリックをUDP経由でGraphiteにエクスポートする機能があります。メトリックは、StatsDのように、所定の時間間隔で集約されます。テキストの上には、Graphiteのグラフを含む画像がありました。

遠心分離機に関する以前の記事で、ZeroMQを使用していることを伝えました。コメントは全会一致でした-ZeroMQは不要です。Redisを使用してください。Redisのパフォーマンスは頭で十分です。最初は少し考えて、RedisをオプションのPUB / SUBバックエンドとして追加しました。そして、このベンチマークがありました：

本当に驚きました。なぜZeroMQがRedisよりも私のタスクにとってそれほど悪いのですか？この質問に対する答えがわかりません。インターネットを検索した後、著者はZeroMQが高速のリアルタイムWebに適していないと文句を言っている記事を見つけました。残念ながら、私はすでにこの記事へのリンクを失っています。その結果、ZeroMQはCentrifugeで使用されなくなり、メモリとRedisの2つのエンジンのみが残ります（最初はCentrifugeの1つのインスタンスを実行し、RedisとそのPUB / SUBが不要な場合に適しています）。

上記のgifでわかるように、Webインターフェイスは消えていません。プロジェクトの作成、設定の変更、および一部のチャネルでのメッセージの監視に引き続き使用されています。それを介して、たとえばメッセージを発行するなど、コマンドを遠心分離機に送信することもできます。一般的に、それは以前でしたが、突然あなたが知らない場合、私はそれを繰り返すことにしました。

他の変更から：

BSDの代わりにMITライセンス。
名前空間のリファクタリング：これは、プロトコルの個別のエンティティとフィールドではなく、コロン（ public:news

）で区切られたチャネル名の単なるプレフィックスです。
JavaScriptクライアントの改善。
ujsonモジュールを追加インストールすると、JSONでの作業を大幅に高速化できます。
GitHubの遠心組織-CentrifugeのPythonクライアントに加えてプロジェクトに関連するリポジトリを使用-プロジェクトをHerokuおよび隣接ライブラリの最初のバージョンにデプロイする方法の例があります-Djangoと統合するための小さなラッパー（パラメーターの生成を簡素化します）接続、遠心分離機にメッセージを便利に送信する方法があります）;
変更/追加に応じてドキュメントを修正/拡張。
他の多くの変更がchangelogに反映されます。

HabréのブログMail.Ru Groupで既に述べたように、Centrifugeは企業イントラネットで使用されています。実際のメッセージは、社内ポータルに使いやすさ、色、ダイナミクスを追加しました。ユーザーは、コメントを投稿する前にページを更新する必要はありません（更新する必要も、更新する必要もありません...）-それは素晴らしいことではありませんか？

おわりに

他のソリューションと同様に、遠心分離機を賢く使用する必要があります。これは特効薬ではありません。それは概してメッセージブローカーにすぎないことを理解する必要があり、その唯一のタスクは顧客との接続を維持してメッセージを送信することです。

クライアントへのメッセージの配信保証を待たないでください。たとえば、ユーザーがページを開いてラップトップをスリープ状態にした場合、タイプライターを「起動」すると、遠心分離機への接続が再び確立されます。ただし、ラップトップがスリープモードのときに発生したすべてのイベントは失われます。また、ユーザーはページを更新するか、自分でバックエンドから失われたイベントをロードするためのロジックを追加する必要があります。また、ほぼすべてのオブジェクト（接続、チャネル、メッセージ履歴）がRAMに保存されるため、その消費を監視することが重要です。オープンファイル記述子のオペレーティングシステムの制限を忘れてはならず、必要に応じて増やしてください。特定の状況でどのチャンネルを作成するかを考える必要があります-プライベートまたはパブリック、履歴ありまたは履歴なし、このストーリーの長さなど。

上で述べたように、サイトにリアルタイムを追加する方法はたくさんあります。賢明に選択する必要があります。場合によっては、別の非同期サーバーを使用するオプションはあまり有利ではないでしょう。

PS春の終わりに、私はサンクトペテルブルクでのパイソン開発者の会議に参加しましたPiter Py。レポートの1つでは、Celeryワーカーで非同期に実行されたタスクの準備ができたというインスタントユーザー通知について説明しました。スピーカーは、これらの目的のためにトルネードとWebソケットのみを使用すると述べました。これに続いて、Djangoとどのように連携するか、どのように開始するか、どのような承認を行うかについていくつかの質問が続きました...

遠心分離機-コメントを投稿する前にページを更新しなくなりました