こんにちは。Redisの深淵を覗き込みたい君へ。
今日はRedisの「トランザクション」という概念について話そう。
多くのエンジニアが、Redisのトランザクションを「RDB（MySQLなど）のそれと同じもの」だと誤解して使い、後で痛い目を見る。まずはその幻想を捨てよう。Redisのトランザクションは、もっとシンプルで、もっと人間味のある仕組みなんだ。
さあ、肩の力を抜いて、僕と一緒に紐解いていこうか。
—
1. なぜ「トランザクション」が必要なのか？
想像してみてほしい。君が人気ラーメン店の店長だとしよう。
お客さんが「チャーシュー麺」を注文した。君は「麺を茹でる」「スープを注ぐ」「チャーシューを乗せる」という3つの工程をこなさないといけない。
もし、途中で別の注文が割り込んできて、「麺を茹でる」と「スープを注ぐ」の間に「餃子を焼く」という作業が混ざったらどうなる？ 厨房はパニックだよね。
Redisも同じだ。複数のコマンドを「一気に、誰にも邪魔されずに」完了させたいとき、このトランザクションが必要になる。
2. Redisトランザクションの「3つのステップ」
Redisのトランザクションは、「予約」→「詰め込み」→「一括実行」という、非常に明快な流れで進む。
- MULTI: 「ここから注文をまとめるよ！」という宣言（予約）
- コマンド群: 「これも追加して」「あれも追加して」とリストに加える（詰め込み）
- EXEC: 「全部まとめて実行してくれ！」という号令（一括実行）
実際にやってみよう
1. 注文開始を宣言
MULTI
OK (「分かった、リストを作るよ」という返事)
2. 作業をリストに溜め込む（この時点ではまだ実行されない）
SET ramen_status “boiling_noodle”
SET ramen_status “adding_soup”
SET ramen_status “adding_chashu”
3. まとめ実行！
EXEC
1) OK
2) OK
3) OK
見ての通り、`EXEC`を叩くまでは、コマンドはただ「予約リスト」に入っているだけ。`EXEC`を叩いた瞬間に、Redisは他の誰にも邪魔させず、猛スピードで全部を片付けるんだ。
—
3. 「監視」という名の安全装置（WATCH）
ここで一つ、大事な話をしよう。「もし、予約している間に誰かが勝手に材料をいじったらどうする？」
例えば、君がチャーシューを乗せようとした瞬間に、別の店員が「チャーシュー切れました！」と在庫を0にしていたら、君の注文は台無しだよね。
ここで登場するのが `WATCH` だ。これは「この材料を誰かが変えたら、俺の注文はキャンセルしてくれ」という監視予約なんだ。
1. WATCH key: 「このキーを監視するよ」と宣言。
2. MULTI: 注文開始。
3. EXEC: もし監視していたキーが誰かに変更されていれば、Redisは潔く「エラー（nil）」を返して実行を拒否する。
これは「楽観的ロック」と呼ばれる手法で、Redisのパフォーマンスを落とさずに安全を確保する、非常に賢いやり方だね。
—
4. 知っておくべき「Redis流」の注意点
ここが一番重要だ。MySQLなどのデータベース経験者が一番驚くポイントだよ。
- ロールバックはない:
普通のDBは、途中で失敗したら「全部なかったことにする（ロールバック）」ができるよね。でもRedisは違う。「途中でエラーが出ても、成功したところまでそのまま進む」んだ。なぜなら、Redisは「速さ」を何よりも優先する設計だから。だから、プログラム側でミスがないか、しっかり検証してから `EXEC` するのが鉄則だよ。
- DISCARD:
「あ、やっぱり今の注文はなしで！」というときは `DISCARD` を使おう。予約リストを綺麗に消し去ってくれる。
—
最後に：君へのメッセージ
Redisのトランザクションは、決して複雑なものではない。「予約して、確認して、一気にやる」。ただこれだけだ。
大切なのは、「Redisは速さを極めるために、あえて複雑な機能（ロールバックなど）を捨てている」という哲学を理解すること。この本質さえ掴めれば、君はもう初心者じゃない。
もし途中で分からなくなったら、いつでもこの「ラーメン屋の厨房」の例えを思い出してほしい。
君の書くコードが、今日も華麗にRedisの上を駆け抜けることを願っているよ。
それじゃあ、また次の深淵で会おう。
コメント