New in version 2.2. Redisでは、実際にクライアントと通信をするポート以外に、サービス用チャンネルを開いてすべてのノードはこのチャンネルを使って直接接続しあいます。TCPのベースのポート+4000番が使われるため、クライアント向けに6379番のポートを使用している場合には、10379番を使用します。ノード間の通信には、バンド幅と速度に最適化されたバイナリプロトコルを使用します。クライアントとの通信では通常はアスキープロトコルを使用しますが、いくつか変更があります。ノード同士は、クエリーをプロキシー(転送)することはありません。 ノード間の通信内容¶ 各ノードは、PING/PONGと同時に、自分が通信した上で判断した周辺ノード情報(Gossip/うわさ話)も一緒に送信します。
Your web service is slow and you want to store things into memory for cache. Luckily, it’s pretty easy to do this in your Node.js Express application. Steps First you want to install your Redis module from npm. Also make sure to edit your package.json with the appropriate module and its version. Then include it in the file where your caching your data. You usually want to put this in your “control
How to use pub/sub channels in Redis SUBSCRIBE, UNSUBSCRIBE and PUBLISH implement the Publish/Subscribe messaging paradigm where (citing Wikipedia) senders (publishers) are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into channels, without knowledge of what (if any) subscribers there may be. Subscribers express interest in
Redis is not just a very good in-memory database, it can also double as a message queue. I want to show you our first shot at implementing a queue in Redis that can fulfill all our requirements: reliable, persistent, fast, monitorable. While still being a Gedankenexperiment the basic idea should be a very good starting point. Although we used Go for our implementation, the concept could be transfe
Node におけるスケールアーキテクチャ考察(Scale 編)というエントリーを読んで、RedisはPub/Sub型通信をサポートしているという事を知りました。エントリーでも言及されているように、Pub/Subを使えば Node.js + WebSocket サーバをスケールする際に、中継サーバの役割を果たす事が出来るはずです。 そんな訳で実際に Node.js と Redis を使って Pub/Sub の実験を行なってみました。ユーザが別々のNode.jsサーバに接続していてもWebSocketを通してメッセージのやり取りを出来るようにします。 イメージとしてはこんな感じです。 下準備# Ubuntuの場合は apt-get で1発でインストールする事が出来ます。 $ sudo apt-get install redis npmでredisモジュールをインストールします。 $ npm i
対象読者 node.js/npmはインストール済み macなどの*nixを持っている redisはよくわからない redisのいいところ 小さい！ 持ち運びしやすい！ 良い意味で何もない！ 純粋KVSより少し豊かなほどよい甘み 簡素ですので、パフォーマンスなどに関して色々「狙いやすい」 あの、express作者さんもよく使ってらっしゃいますよ 僕みたいなコンシューマーゲーム難民に是非オススメしたい、組み込み系の薫りとwebっ子っぽいカジュアルな感覚が同居したシンプルDBとなっております。 redis本体 ダウンロードページから最新版(この文章を書いている時点では2.4.4)をダウンロードして、下記のように一行makeと打てば終わりです。 make 続けてインストールするか否かはお任せします。この段階で、「展開ディレクトリ/src/redis-server」がありますので、起動しておきます。
Features Simple HTTP JSON(P) output, and other formats Chunked pub/sub Access Control by IP+mask or HTTP Auth And more... Install $ git clone git://github.com/nicolasff/webdis.git $ cd webdis $ make $ ./webdis & Webdis is a simple HTTP server which forwards commands to Redis and sends the reply back using a format of your choice. Accessing /COMMAND/arg0/arg1/.../argN[.ext] on Webdis executes the c
最速KVS研究第4弾 - なぜか数学者にはワイン好きが多い どこまでも続きます． 目的が全く違う2者ですが，敢えて比較してみました． もちろん，Google LevelDBと似たコンセプトのものとの比較も今後進めますが．．． とりあえず，キー長はmd5ハッシュの長さ固定，バリュー長を変化させ，かつ同時アクセス数をスレッドアクセスで変化させて読み書き時間を測ってみました． まず，バリューの長さが100バイトと短い場合のベンチ． 同時アクセス数を表すスレッド数が少ないときはLevelDBの書き込みが爆速，読み込みはなぜか遅い．．．redisはスレッド数に関わらず安定して読み書きとも中間な感じです． 次，バリューの長さが1000バイトの中間的ベンチ． やはりLevelDBはスレッドが1だと書き込みが最も速く，同時アクセス数が増えると遅くなる． 読み込みの方は，redisよりは遅いものの同時アクセ
どうも、プラットフォームDivでエンジニアをやっている Wataru です。 最近３人目の子供が産まれて、産後自宅勤務をさせてくれた弊社はとてもいい会社だと思います。出産予定のあるエンジニアのかたは是非弊社に転職を。 さて、今回はRedisの紹介をさせて頂きたいと思います。 Redisってすごくマイナーなわけではないのですが、めちゃくちゃ便利なのにあまり注目されていないなーという印象があるので、これを機会に是非使ってみてもらえると嬉しいです。 Redisって何？Redisとは「remote dictionary server」から名前が付けられたオープンソースのkey-valueデータストアです。 MemcacheDB等のKVSとの最大の違いは、格納するバリューがデータ構造というところです。 つまり、リスト・セット・ハッシュなどのデータ構造で格納できるのでバリューに対してアトミックな操作が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
