やあ。Redisの世界へようこそ。
Redisを単なる「キャッシュ」だと思っているなら、それは大きな勘違いだ。Redisは、データの流れを自在に操る「情報の交差点」なんだよ。
今日は、Redisが誇る最強のデータ構造の一つ、「Stream（ストリーム）」について話そう。まるで終わりのないテープのようにデータが流れてくるこの仕組みを、どうやって読み解き、どうやって仲間と分担して処理するのか。
難しく考える必要はない。日常の風景に例えて、その本質を解き明かしていこう。
—
1. Stream（ストリーム）とは何か？
Streamは、「時系列で流れてくるメッセージの貯蔵庫」だ。
イメージしてみてほしい。君の家のポストに、次々と届く手紙（メッセージ）の束がある。古い手紙から順に並んでいて、誰かが取り出すまでそこに留まっている。これがStreamの正体だ。
2. XREAD：一人で黙々と読み解く
まずは、一番シンプルな「読み取り」からだ。`XREAD`は、ポストの中身を上から順に読み取るコマンドだ。
「mystream」というポストの、一番最初から手紙を全部読んでくれ！という命令
XREAD STREAMS mystream 0
- 0：これは「最初のメッセージから全部くれ」という合図だ。
- $：もし「新しい手紙が届くまで待機して、届いたらすぐ教えて！」という場合は、`0`の代わりに`$`を指定する。これを「ブロッキング読み取り」と呼ぶ。
これは、「一人で全てのメールを処理する」スタイルだ。だが、もし手紙が1秒間に1000通届いたらどうなる？ 一人ではパンクしてしまうよね。そこで登場するのが、「コンシューマーグループ」だ。
—
3. XREADGROUP：チームで分担して処理する
ここからがプロの領域だ。`XREADGROUP`は、「チームで手紙をさばく」ための仕組みだよ。
例えば、君のチームにAさんとBさんがいるとする。
1. グループを作る: まず「処理チーム」という名前のグループを作る。
2. 分担する: Aさんが「次は私の番！」と言って手紙を取ると、Bさんにはその手紙は渡されない。
3. 責任を持つ: Redisは「誰がどの手紙を処理中か」をしっかり記録している。
実行の流れを見てみよう
1. コンシューマーグループを作成する
グループ名「mygroup」、ストリーム名「mystream」、0は最初からという意味
XGROUP CREATE mystream mygroup 0 MKSTREAM
2. グループとして読み取る
「mygroup」の「consumer-A」が、「mystream」から新しい手紙を読み込む
XREADGROUP GROUP mygroup consumer-A STREAMS mystream >
- `>`：これが魔法の記号だ。「まだ誰にも渡されていない、新しい手紙だけをちょうだい」という意味だよ。
—
4. 伝説のエンジニアからのアドバイス：なぜこれが必要なのか？
ここを理解すれば、Redisの基本はバッチリだ。なぜわざわざグループを作るのか？ それは「確実性（Reliability）」のためだ。
もし、Aさんが手紙を処理している途中にPCが壊れたらどうなる？
普通ならその手紙は消えてしまう。しかし、Redisには「PEL（Pending Entries List）」という未処理リストがある。
「処理中ですよ」という印をRedisが預かってくれているから、万が一Aさんが失敗しても、Bさんが「あの手紙、まだ終わってないみたいだから代わりにやるよ」と引き継げるんだ。これが、システムが止まらないための秘訣だよ。
—
まとめ：ここをマスターすれば怖いものなし
- XREAD：一人で黙々と、あるいはリアルタイムで通知を受けたいときに使う。
- XREADGROUP：チームで負荷を分散し、かつ「処理の抜け漏れ」を防ぎたいときに使う。
RedisのStreamは、単なるデータの箱じゃない。「システムがどれだけ忙しくても、一通の手紙も落とさない」という設計思想そのものなんだ。
最初は難しく感じるかもしれないけれど、まずは自分の手でコマンドを叩いてみてほしい。Redisと対話しているうちに、データの流れが見えてくるはずだよ。
何か詰まったら、いつでも聞きに来るといい。君がエンジニアとして一歩先へ進むのを、いつでも応援しているよ。
コメント