やあ。Redisの世界へようこそ。
Redisといえば「高速なキャッシュ」というイメージが強いかもしれないけれど、今のRedisは単なる「速い棚」じゃない。「時系列データ」を完璧に扱うための、非常に強力なエンジンの顔も持っているんだ。
それが今回紹介する「Redis Streams（ストリーム）」だ。
難しい技術用語は一旦置いておこう。まずは、これが何者なのかを君の日常に例えてみるね。
—
Redis Streamsは「伝言板付きのタイムライン」だ
想像してみてほしい。君がカフェの店長だとしよう。
お客さんから注文が入るたびに、壁の「伝言板」に注文内容をメモしていく。
1. XADD: 「注文が入りました！」と伝言板に書き込む（追記する）。
2. XREAD: お店の子が伝言板を見て、溜まっている注文を確認する（読み取る）。
3. XREADGROUP: 複数人のスタッフで手分けして、注文をさばく。
4. XACK: 「この注文、調理完了したよ！」とチェックを入れる（確認応答）。
Redis Streamsは、まさにこの「書き込まれた順序を絶対に守り、誰がどの作業を終えたかを管理できるノート」なんだ。
—
1. 注文を書き込む：XADD
まずは伝言板に書き込んでみよう。“ は「時間を自動でIDにしてね」という意味だ。
「orders」というストリームに、コーヒーとケーキの注文を書き込む
XADD orders item “coffee” price 500
結果: “1700000000000-0” のようなIDが返ってくる（これがタイムラインの目印だ）
2. 注文を読み取る：XREAD
次に、溜まっている注文を読んでみよう。
ストリームの最初から、最新の注文を読み取る
XREAD STREAMS orders 0
0を指定すると、最初から全部読み取れる。
3. チームでさばく：XREADGROUP
ここがプロの腕の見せ所だ。スタッフが何人もいる場合、同じ注文を二人が調理したら困るよね？ そこで「グループ」を作って、「誰がどの注文を担当したか」をRedisに管理させるんだ。
「kitchen」というグループを作り、0番目から読み込みを開始させる
XGROUP CREATE orders kitchen 0 MKSTREAM
これで、スタッフAとスタッフBが同じグループに入れば、Redisが「Aにはこの注文、Bにはこの注文」と、被らないように仕事を割り振ってくれるようになる。
4. 仕事の完了を報告する：XACK
スタッフが料理を出したら、必ず報告させよう。これを忘れると「まだ調理中」とみなされて、永久に注文が残ってしまう。
IDを指定して、注文を完了させる
XACK orders kitchen 1700000000000-0
5. 迷子になった注文を探す：XPENDING
「あれ、この注文まだ完了してないんじゃない？」と心配になったらこれだ。
完了報告がない（PENDINGな）注文を一覧表示する
XPENDING orders kitchen
—
なぜこれが「最強」なのか？
初心者の方は、「リスト（List）やセット（Set）じゃダメなの？」と思うかもしれない。でも、Streamsには決定的な違いが3つあるんだ。
1. IDが時系列順（タイムスタンプ）: 過去のどの時点からでも再生できる。
2. ACK（確認応答）機能: 処理中にサーバーが落ちても、どのデータまで処理が終わっていたかを記録しているから、データの取りこぼしが起きない。
3. グループ管理: 1つのデータを複数のワーカーで安全に分担できる。
最後に：整理整頓も忘れずに
ログは無限に増えるとサーバーのメモリを食いつぶす。古くなったデータは `XTRIM` でサクッと削除しよう。
最近の1000件以外は消して、スッキリさせる
XTRIM orders MAXLEN ~ 1000
—
君へのアドバイス
Redis Streamsは、「メッセージの配送を絶対に失敗したくない」というシビアな現場でこそ真価を発揮する。
最初は難しく感じるかもしれないけれど、まずは `XADD` で書いて、`XREAD` で読んでみる。それだけでいい。そこから少しずつ「グループ化」や「ACK」を取り入れていけば、君のシステムは一気にプロフェッショナルな堅牢さを手に入れるはずだよ。
ここをマスターすれば、君はもうRedisの初学者じゃない。
データの流れを支配する、立派なアーキテクトへの第一歩を踏み出したんだ。
さあ、何か作ってみようか？応援しているよ。
コメント