【テクニカル・上級編】 MULTIコマンド – Redis

Redisの「MULTI/EXEC」という幻想と、その背後にある非同期の真実

多くの開発者は、`MULTI` を見るとRDBMSのトランザクションを想起する。しかし、もし君がRedisを「RDBMSの代わり」として扱っているなら、それは最初の誤解だ。

Redisにおける `MULTI/EXEC` は、ACIDの「A（Atomicity）」を担保するためのメカニズムではあるが、その実装は君が想像するような「ロックとログ」による重厚な代物ではない。これは、シングルスレッドイベントループというRedisの心臓部を、いかにして「分断させないか」という極めて戦略的なキューイング機構なのだ。

今日は、Redisの内部アーキテクチャの深淵から、このトランザクションの正体を解剖する。

—

1. 「キュー」という名のメモリ・レイテンシの罠

`MULTI` を発行した瞬間、Redisサーバのクライアントオブジェクトは `CLIENT_MULTI` フラグを立てる。以降、君が送るコマンドは即座には実行されず、クライアントごとの `multiState` 構造体に積まれていく。

ここで注意すべきは、「コマンドの構文解析はキューイング時に行われる」という点だ。

MULTI
SET key value # 構文が正しければ QUEUED
INCR # 引数が足りない等の構文エラーがあれば、EXEC時に全てが破棄される

内部的には、`multiCmd` 構造体の配列としてメモリ上に確保される。つまり、大量のコマンドを `MULTI` で囲むと、それは実行されるまでの間、Redisのヒープメモリを消費し続けることを意味する。大規模なバッチ処理で `MULTI` を過信して数万件のコマンドを詰め込むのは、メモリ不足（OOM）を誘発する愚策だ。

2. 楽観的並行性と「WATCH」の冷徹な事実

Redisのトランザクションはロックを行わない。代わりに `WATCH` コマンドを用いた「楽観的並行制御（OCC）」を採用している。

`WATCH` されたキーが `EXEC` の前に変更されると、Redisは `multiState` をクリアし、トランザクションを `nil` として失敗させる。これは、Redisの各キーが持つ `watched_keys` リストを走査するだけの非常に軽量な処理だ。

しかし、ここがアーキテクトの腕の見せ所である。
「WATCHは、書き込み競合が極めて少ない環境でのみ輝く」

競合が激しい環境で `WATCH` を乱用すれば、クライアントはリトライの無限ループに陥り、CPUリソースは「変更検知」の走査だけで浪費される。もし君のシステムで高い競合が発生しているなら、`MULTI/EXEC` ではなく、Luaスクリプトを選択すべきだ。

3. Luaスクリプトこそが「真のトランザクション」である理由

なぜ伝説的なエンジニアたちが、`MULTI/EXEC` よりもLuaスクリプトを推奨するのか。理由は明白だ。

1. アトミック性の担保: Luaスクリプトは実行中、他のあらゆるコマンドをブロックする。`MULTI/EXEC` が「一括実行」であるのに対し、Luaは「サーバサイドでの一連の処理の不可分実行」である。
2. ネットワークレイテンシの排除: `MULTI` はコマンドごとにクライアントとサーバ間の往復（またはパイプラインによるバッファリング）を要するが、Luaは一つのスクリプトを送るだけで完結する。
3. 条件分岐と計算: `MULTI` はキューイング中に値を見ることができない。つまり、「Aの値が10以上ならBをインクリメントする」といった条件付き処理は、`WATCH` を使わない限り不可能だ。しかし、Luaならばサーバサイドで値を読み、その場でロジックを完結できる。

4. 運用における限界突破の知見：アトミック性の代償

最後に、プロフェッショナルとして警告しておく。
`MULTI` ブロック内でのコマンド実行が成功しても、Redisの永続化（AOF/RDB）のタイミングによっては、システムクラッシュ時にデータ整合性が揺らぐ可能性がある。

特に、`appendfsync everysec` を設定している場合、トランザクションの原子性はRedisプロセスレベルでは保証されても、OSの書き込みバッファレベルでは絶対ではない。

結論として：

単なる一括処理: `MULTI` で十分だ。だが、キューの長さを監視せよ。
競合を伴うロジック: `WATCH` を使う前にLuaを検討せよ。
パフォーマンスの極限: `WATCH` の走査コストを理解し、キーの設計を分散させよ。

Redisは「魔法の杖」ではない。そのシングルスレッドの特異性を理解し、データ構造を設計する者だけが、この超高速なデータストアを真に制御できる。

次回のチューニング時には、`INFO commandstats` で `multi` コマンドのレイテンシを注視することをお勧めする。そこに、君のアーキテクチャの真実が刻まれているはずだ。