10分テックトーク：ジョムンとラオンのCache & Redis の動画を見てまとめました。

キャッシュを使用する理由

• 時間的局所性：以前アクセスしたデータに再びアクセスする確率が高い
• 空間的局所性：隣接した場所のデータに継続的にアクセスする確率が高い

キャッシュ戦略パターン

読み取り戦略

Look Aside Pattern キャッシュにデータがない場合、DBからデータを取得する戦略。 利点：キャッシュに問題が発生した場合、リクエストをDBに委任できる 欠点：キャッシュとDB間のデータ整合性の維持が困難。初回クエリ時にDB過負荷が発生

Read Through Pattern 常にキャッシュからデータを読み取る戦略。 利点：キャッシュとDB間のデータ整合性を保証 欠点：キャッシュがダウンするとアプリケーションに問題が発生

書き込み戦略

Write Around 書き込み迂回。キャッシュに直接書き込まず、DBに書き込む。 読み取り戦略と組み合わせて使用する場合、キャッシュミスが発生した際にキャッシュストアにも書き込む。 利点：パフォーマンスが良い。不要なデータをキャッシュに載せず直接書き込むためリソースを節約できる。 欠点：キャッシュとDB間に接続点がないため整合性の維持が困難

Write Back キャッシュに先に書き込み、後でDBに反映する。大量の書き込み操作を一括でスケジューリングする。 利点：書き込み回数のコストを削減できる 欠点：キャッシュのデータ消失の可能性

Write Through 全てのデータ書き込みをCacheを経由して行う。 利点：データ整合性が保証される。 欠点：必ず2回の書き込みが常に行われるためパフォーマンスを考慮する必要がある。

キャッシュ使用時の注意事項

1. 頻繁に使用されるが変更されないデータ
2. 消失しても大きな問題がないデータ
3. データベースと併用する場合、データ整合性の問題を考慮する必要がある

Redis (Remote Dictionary)

Key-value構造。HashMapに類似。 メモリベースのkey-value store。 キャッシュの実装方法にはMemcached、Redis、ローカルメモリベースなどがある。 一時的な作業キュー、リアルタイムチャット、メッセージブローカーとしても活用される。

特徴

• Get/Setの場合10万TPS処理が可能。
• 多様なデータ構造を提供（Collection）
• Key: string
• Value: Hash, List, Set, Sorted Set
• Single Thread
• 一度に1つのコマンドのみ処理
• Race conditionが（ほぼ）発生しない
• Persistence：メモリに保存されたデータをディスクに永続化できる。
  • RDB（Redis Database Backup）：圧縮して保存するためサイズが小さい。スナップショットを取る。
  • AOF（Append Only File）：insert、update、deleteが発生するたびにログファイルに記録。サイズが大きく復元所要時間が長い。

Redisを上手に使う

1. データ型に応じた適切なデータ構造の使用 sorted setのソート機能を活用すれば、SQLのORDER BY（ソート）、DISTINCT（重複除去）を一度に解決できる。

2. O(N) コマンドに注意 KEYS/FLUSHALL、FLUSHDB、DELETE Collections、Get All Collectionsのような O(N) コマンドを実行すると、シングルスレッドのRedisが他のコマンドを処理できなくなる可能性がある。

3. メモリ管理 メモリフラグメンテーション（内部フラグメンテーション、外部フラグメンテーション）が発生。使用可能な空間が十分であっても新しいメモリ空間の割り当てが不可能になる。 そのためRSS（Resident Set Size）モニタリングが必要。

4. 目的の明確化 キャッシュ用なのかストレージ用なのかを明確に区分し、Persistent機能をオフにできる場合はオフにすべきである。

References

• https://www.youtube.com/watch?v=tVZ15cCRAyE

クイズ