キャッシュとしてのRedis
Redisはキャッシュとしてもデータベースとしても使えます。
両者の違い：
- キャッシュされたデータは重要ではなく、全データ量ではありません
- アクセスが変わるとキャッシュされるデータも変わります
- キャッシュはホットデータのみを保持
- データベースからデータが失われることはありません。
- スピードのためのキャッシュ、スピードと永続性のためのデータベース
- 電源が切れると、メモリー内のデータは簡単に失われます。
- キャッシュとしてのredisは、一般的にRDBを使用します。
- AOFを使用したデータベースとしてのredis
キャッシュはホットデータのみを保持
** 理由
メモリのサイズには制限があります。
ビジネスによってRedisのデータがどのように変化するか
ビジネスロジックによる変更
キーの有効性
鍵の有効期限はアクセス時間より長くないこと。
書き込みが発生すると、キーの有効期限が明らかになります。
鍵の有効期限のカウントダウン時間を設定 EXPIRE key seconds
*** 期限切れキーの削除ポリシー
- 受動的削除：期限切れの鍵を読み書きする場合、不活性削除ポリシーが起動され、期限切れの鍵が直接削除されます。
- アクティブ削除：不活性削除ストラテジーではコールドデータがタイムリーに削除されることを保証できないため、Redisは定期的に期限切れのキーのバッチをアクティブに削除します。
- 現在使用されているメモリがmaxmemoryの制限を超えた場合、アクティブ・クリーンアップ・ポリシーをトリガーします。
事業運営に伴う変化
メモリは有限であるため、アクセスが変化すると、コールドデータのチューニングが不要になります。
Redis
Redisの永続性には、スナップショットコピーとログの2種類があります。
RDB
** スナップショットの記録はポイント・イン・タイムです。
スナップショットを取るとき、redisはスナップショットを実行する子プロセスを開始します。
子プロセスにデータへのポインタのセットをスナップショットするには fork を使います。
forkは書き込み時にコピーされるため、子プロセスの生成時にはコピーは発生しません。
**セーブ
保存タイミングを使用：例：シャットダウンメンテナンス
save は同期保存操作で、指定された時点で Redis インスタンス内のすべてのデータのスナップショットを取得し、RDB ファイルとしてディスクに保存します。
save はすべてのクライアントをブロックします。
** bgsave save**
forkを呼び出して子プロセスを作成
** 関連する構成
** メリット
データの復元は比較的速い - JAVAのシリアライゼーションに似ています。
** デメリット
ジッピングはサポートされていません。dump.rdbのコピーは常に1つだけです。
タイムポイントごとにデータを失いやすい
AOF
AOFは、Redisのファイルへの書き込みのロギングです。
redisでは、RDBとAOFの両方がオンになっている場合、AOFのみがデータ復旧に使用されます。
4.0以前：オフセットコマンドの削除、重複コマンドのマージ -最終的に純粋なコマンドログファイルを生成
4.0以降：RDBが古いデータをAOFファイルに追加 -AOFはハイブリッドで、高速なRDBを使用し、ログをフルに使用
** 関連する構成
appendonly yes
appendfilename "appendonly.aof"
自動aof-rewrite-percentage 100
自動aof-rewrite-最小サイズ 64mb
aof-use-rdb-preambleイエス
書き込みポリシーappendfsync always - 書き込み後にフラッシュします。 appendfsync everysec - 書き込み後、毎秒フラッシュします。
appendfsync no - バッファに書き込み、いっぱいになったらフラッシュします。
** メリット
データ損失が比較的少ない
** デメリット
4.0以前のAOFボリュームは無限に大きい
redisはインメモリデータベースであり、書き込み操作はIOをトリガーします。
