0

次のように、内部の仕組みに redis を使用するように socket.io を構成できるため:

var RedisStore = require('socket.io/lib/stores/redis')
, redis  = require('socket.io/node_modules/redis')
, pub    = redis.createClient()
, sub    = redis.createClient()
, client = redis.createClient();

io.set('store', new RedisStore({
  redisPub : pub
, redisSub : sub
, redisClient : client
}));

このRedisStoreの内部を見て、socket.ioが挿入および削除しているデータを確認するにはどうすればよいですか? 次のように、node-redis からインストールされた redis インスタンスを使用するように socket.io 構成を設定しました。

redis  = require('redis')

しかし、socket.io アクティビティが行われている様子は見られず、socket.io が実際に redis を使用しているかどうか疑問に思います。Express と Connect を構成して redis を MemoryStore として使用するため、Cookie が redis に保存されていることがわかりますが、socket.io に関連するものは何も表示されません。

4

1 に答える 1

1

ローカルの redis node.js 開発/デバッグでは、これを行います。

バックグラウンドで redis サーバーを起動し、同じ tty で cli モニターを実行します。

redis-server &
redis-cli monitor -h host -p port

そのままにしておくことができます-ローカルのデフォルトを使用している場合はオフにします。

また、すべてのマスター コマンドをエコーし​​、現在の redis サーバーのメモリ保持データを ./dump.rdb にデフォルト設定されたテキスト ファイルに同期する redis スレーブを実行することもできます。ファイルは redis にロードして、テキスト エディターで表示できます。

 redis-cli --slave -h host -p port
 vim ./dump.rdb

基本的な node.js Passport セッション Cookie は次のようになります。

sess:L2C4MPtAUmlO4zHGkXnq4icuÃ@U@Z{"cookie":{"originalMaxAg  null,"expiresÀhttpOnly":true,"path":"/"}passport L}

さらに内部を確認するために、アプリをステップ実行して、ノード コードと redis ドライバーが相互作用する領域にブレークポイントを配置することができます。

これを使用して、関数をステップ実行し、制御フロー中の状態の変化を観察することで、ハンドシェイク プロセスを監視したり、不正なデータ交換やソケットの問題などを確認したりできます。

このジョブのノード アプリは node-inspector です。

これにより、Chrome 開発ツールと同様のデバッグ環境で実行されているアプリを表示できます。そこでは、ブレークポイントを設定して一時停止したり、関数にステップ インおよびステップ アウトしたり、次のブレークポイントまたは例外が一時停止をトリガーするまで時間を進めたりすることができます。

npm -g install node-inspector

複数のプロジェクトで使用する場合は、「-g」グローバル スイッチを使用してインストールします。

端末ウィンドウでオプションなしでプログラムを実行すると、次の出力が生成されます。

~/passaic-streaming git:weekend-refactor ❯❯❯
Node Inspector v0.7.0
Visit http://localhost:8080/debug?port=5858 to start debugging.

構成変数または ENV 変数を使用して HOST、PORT、DEBUG-PORT を構成できます (パラメーターとして渡される DEBUG_PORT、ポート 5858 は、実行中のノード プロセスと Web アプリを実行しているブラウザーとの間のソケット接続をセットアップします)。

現在、node.js コードをデバッグ モードで実行するには 3 つの方法があります。これは、node-inspector を最初に実行した後に行います。

node --debug-brk app.js

node --debug app.js

node app.js  // then send a SIGUSR1 to the node process:

// pgrep node
// kill -s USR1 PID

モジュールの最初の行でコードを停止するように指示するため、すべてが機能するまで、最初のコマンド「--debug-brk」を使用します。

    browser http://localhost:8080/debug?port=5858

アプリのサイズによっては、読み込みに少し時間がかかる場合があります。ただし、コードをステップ実行するためのソース タブとコンソール タブが表示されます。

「--debug」は高速アプリで正常に機能します。エンドポイントにヒットするか、トランザクションを実行するか、ブレークポイントで手動で一時停止するように指示するだけでよい場合があります。

一部のノード スクリプトは速すぎて node-inspector リスナーにキャッチされません。ソース コードにブレークポイントを設定するまでは、最初の行でブレークするのが便利な場合があります。したがって、コマンドです。

'node debugger';次のような領域の周りに線を引くこともできます:

 // connect to Redis for sessionStore

  node debugger;    // node-inspector will pause here.

  redisClient = redis.createClient(
    options.PORT, options.HOST, options.REDIS_OPTIONS));

デバッグ モードでアプリを起動せずに SIGUSR1 を使用する必要がある主な理由は、node.js クラスター API を使用している場合です。

クラスタリングを使用して複数のノード プロセスを作成しているアプリを監視しようとする場合、ノード < 0.11.x でデバッグしようとすると、ソケットで次の問題が発生します。

Failed to open socket on port 5858, waiting 1000 ms before retrying
Failed to open socket on port 5858, waiting 1000 ms before retrying

不安定なノード バージョンでは、child_process.fork コマンドはデバッガー ポート 5858+1 でリッスンします。つまり、使用しているワーカーに応じて 59、60 などです。

今のところ、ノード 0.10.x では、クラスター化されたアプリでワーカーの状態を検査する必要がある場合、「--debug」モードではなくノードを起動し、代わりに kill USR1 シグナルをプロセスに送信する必要があります。

redis を使用してノードから強制的にログアウトするには、node_redis ドライバーをデバッグ モードにします。

redis = require('redis');
redis.debug_mode = true; //turn on debug mode

また、次のように開始して connect-redis ミドルウェアを使用する場合:

DEBUG=* node app.js

次に、connect-redis の出力が次のように表示されます。

connect:redis SETEX "sess:FVDBpNoFDFIOkynFDLcpM6St" ttl:604799 
{"cookie":{"originalMaxAge":604799991,"expires":"2014-03-08T22:38:32.620Z","httpOnly":true,"path":"/"},"passport":{"user":"52edfdfdf3da2rer0c06eb34"}} +50ms

最後に、StrongOps/Strongloop のチームは、コマンド ライン ツール ノード インスペクターの一部を組み込みました。

npm install -g strong-cli

slc debug app.js

node-inspector を起動し、Web ブラウザを開いて適切なインスペクタを開き、最新のノード バージョンではクラスタリングを認識します。

于 2014-03-01T22:33:43.200 に答える