Redisの「シングルスレッド」という神話と、その極限の設計思想
世間では「Redisはシングルスレッドだから速い」という言葉が、半ば宗教のように語られている。しかし、アーキテクトの視点から言えば、それは本質を捉えていない。
Redisが真に優れているのは、「シングルスレッドで動くから速い」のではない。「スレッド間のコンテキストスイッチとロック競合という、現代のマルチコアCPUにおける最大の『癌』を排除したからこそ、圧倒的なスループットを実現できた」という点にある。
今日は、その設計の深淵に触れ、なぜこのアプローチが現代の分散システムにおいても最強の武器であり続けるのかを解き明かす。
—
1. I/O多重化：イベントループの完成形
Redisの心臓部は `ae.c` で実装されているファイルイベントループだ。これは `epoll` (Linux) や `kqueue` (BSD) といった、OSレベルのI/O多重化メカニズムを抽象化したものに過ぎない。
多くのエンジニアが誤解しているが、Redisのシングルスレッドは「CPUを1つしか使わない」ことを意味するのではない。「アプリケーション層でのコンテキストスイッチをゼロにする」ための戦術だ。
なぜロックを排除したのか
マルチスレッド環境でのデータ構造（ハッシュテーブルやスキップリスト）の保護には、ミューテックスやスピンロックが必須だ。しかし、ロックは以下のコストを強制する。
- コンテキストスイッチ: スレッドがOSによってプリエンプトされる際のレジスタ保存/復帰コスト。
- キャッシュ汚染: 複数のコアが同一メモリ領域にアクセスしようとする際のL1/L2キャッシュのコヒーレンシ維持（MESIプロトコル）によるパフォーマンス低下。
Redisはこの「競合のオーバーヘッド」を計算から消し去った。この決定こそが、インメモリという超高速な領域で、他の追随を許さないレイテンシの安定性を生んでいる。
—
2. なぜ「6.0」でマルチスレッドを導入したのか？
「Redisはシングルスレッドである」という前提は、バージョン6.0で大きく変容した。しかし、勘違いしてはならない。Redisは「コマンド実行」をマルチスレッド化したわけではない。
マルチスレッド化されたのは、「ネットワークI/O（ソケットの読み書き）」のみだ。
/ 概念的な実装: I/Oスレッドの役割 /
// メインスレッドはコマンドの実行（計算・メモリ操作）のみに専念する
// ネットワークからのパケット読み込みや、書き出しのシリアライズは別スレッドに委譲する
void handle_io_thread_tasks() {
// ネットワークI/Oをマルチスレッドで捌くことで、
// メインスレッドのボトルネックだった「シリアライズ・デシリアライズ」を分離。
// これにより、コマンド実行効率を最大化する。
}
この設計の妙は、「最もCPUコストがかかるコマンド実行部分はシングルスレッドのまま維持し、飽和しやすいI/Oパスのみを並列化した」点にある。これにより、競合を生まないというRedisの最大の設計原則を維持しつつ、現代のネットワーク帯域（10Gbps/100Gbps）を使い切るキャパシティを手に入れたのだ。
—
3. アーキテクトが知るべきメモリの「断片化」と「局所性」
シングルスレッドでメモリを操作する際、最も恐ろしいのは「大きなオブジェクトの操作」だ。`DEL` コマンドで数百万要素を持つハッシュを削除すれば、その瞬間、イベントループはブロッキングされる。
これを回避するために導入されたのが `lazyfree` だ。
- 同期削除: `DEL key` -> メモリ確保を解放するまで待機（イベントループ停止）
- 非同期削除: `UNLINK key` -> キーへの参照を切り離し、別スレッドで `zfree` を実行（イベントループ継続）
この「メインスレッドの処理時間をいかに短く保つか」という執念こそが、Redisを伝説的なデータベースたらしめている。
—
4. 限界を突破するための提言
もし君がRedisを限界まで使い倒そうとしているなら、以下の点に注目してほしい。
1. CPUアフィニティを考慮せよ:
Redisのプロセスを特定の物理コアにピン留めすることで、L3キャッシュのヒット率が劇的に向上する。OSのタスクスケジューラに任せてはいけない。
2. `slowlog` の解釈を変えろ:
`slowlog` は単なるログではない。イベントループが「どの程度止まったか」の指標だ。0.1msの停止も無視してはならない。それはシステム全体のレイテンシの揺らぎ（テールレイテンシ）に直結する。
3. コマンドの計算量を意識せよ:
`O(N)` のコマンド（`KEYS`, `SMEMBERS`, `HGETALL`）は、たとえデータ量が小さくても、将来的なスケーラビリティに対する「時限爆弾」だ。常に `O(1)` か `O(log N)` の操作のみで完結するデータ設計を行え。
—
結び
Redisは、複雑さを極限まで排除したことで最強になった。
マルチスレッドの複雑な同期処理に逃げず、OSのI/Oモデルを徹底的に活用し、シングルスレッドの限界を計算だけで突破する。
エンジニアリングとは、単に技術を使うことではない。「何をやらないか」を定義し、残ったコア部分を極限まで研ぎ澄ますことにある。Redisのアーキテクチャは、その最も美しい体現の一つだ。
次は、君がこのアーキテクチャの上で、いかに無駄のないクエリを叩き込むか。それが問われている。
コメント