Redisは、キーを指定して値を読み書きする、メモリ中心のデータストアです。文字列だけでなく、属性をまとめるハッシュや、順番に取り出すリストなどの操作を備えています。キャッシュ、セッション、仕事の待ち行列であるキューに利用できます。
たとえば記事サイトでは、本文の正本をMySQLへ置き、人気記事の集計結果をRedisで再利用する構成にできます。役割は「DBと別に置かれる速い箱」で終わらず、何の状態を保存しているかで考えると理解しやすくなります。
キャッシュ・セッション・キューでは失ったときの影響が違う
| 用途 | 保存するものの例 | 消えたときに必要になること |
|---|---|---|
| キャッシュ | DBから作った公開記事の一覧 | 正本から再計算する。再計算の集中にも備える |
| セッション | ログイン状態や入力途中の状態 | 再認証や入力の復元。未保存の内容を失う場合がある |
| キュー | まだ終わっていない画像変換の仕事 | 未処理分を特定して再実行する。失ってよいとは限らない |
この違いがあるため、Redisのデータを一括して「消えても困らない」と扱うことはできません。セッションやジョブをキャッシュと同じ追い出し対象にすると、負荷が高いときに必要な状態を失うおそれがあります。
一方、「Redisは重要なデータを保存できない」という制約でもありません。必要な検索や整合性、耐久性、復旧方法を満たせるかが判断の基準です。PostgreSQLなどの表・SQL・制約を中心とするDBとは、データのモデルや操作方法が異なります。
有効期限と容量上限は別の仕組み
キーに有効期限を設定すると、期限が過ぎた値を使わないようにできます。RedisのTTLコマンドは残り秒数を返し、-1は期限なし、-2はキーがない状態です。通常のSETで上書きすると以前の期限が外れるため、「最初に期限を付けたから十分」とは限りません。
容量が増えたときは、maxmemoryと追い出し方針を確認します。noevictionでは容量を増やす書込みなどがエラーになり、既存値の読取りはできます。allkeys-lruなら最近使われていないキーを近似的に選び、volatile-lruなら期限付きキーを対象にします。期限付きだから消失から保護されるわけではありません。
64ビット版のmaxmemory 0はRedisのこの設定で上限を設けない意味です。物理メモリが無限になるわけではないので、実行環境の容量も含めて監視します。名前の接頭辞や論理DB番号を分けるだけでは、インスタンス全体の容量方針を分離できません。
再起動と永続化をどう考えるか
ディスクへ保存する方法には、時点の内容を記録するRDBスナップショットと、書込みを記録するAOFがあります。再起動後に戻せる内容は、保存設定・同期のタイミング・保存先が残るかで変わります。「再起動で必ず消える」「既定なら必ず消えない」のどちらも、設定を見ずには判断できません。
永続化は、キャッシュを作り直す手間を減らすだけの機能ではありません。重要な状態を残す設計にも関わります。ただし、同じディスクへの記録だけではディスク障害や誤削除に備えられないため、バックアップと復旧確認は別に必要です。
具体的な保存・期限切れ・ジョブの取出し・再起動の比較は、Redisをキャッシュ・セッション・キューで使う記事に実行結果とともに掲載しています。
採用する版のライセンスも確認する
2026年9月21日に確認した公式一覧では、Redis 7.2系以前はBSD-3-Clause、7.4はRSALv2またはSSPLv1、8以降はRSALv2・SSPLv1・AGPLv3のいずれかを選ぶ形です。旧版の説明を別の版や商用サービスへそのまま当てはめず、利用対象と条件を照合します。