みんな大好き。キャッシュ。
RDBでは遅い処理を劇的に早くしてくれるアレですね。
大量リクエストを捌かなければいけない本番環境では如何にキャッシュを上手に使えるかがスループットを大きく左右します。
でも、Redis 本番障害から学んだコードレビューの勘所にあるとおり、キャッシュサーバは運用を一つ間違うと途端に地雷化してしまうものでもあります。
そこで、キャッシュサーバの鉄則を伝授しましょう。（偉そう）
1. キャッシュサーバがダウンしても、システムにパフォーマンス以外の影響があってはならない。
2. 有効期限(TTL)が指定されてないデータを保存してはいけない。
というものです。キャッシュはあくまでもキャッシュ。いつ消えても問題ないデータしか保存してはいけません。
キャッシュサーバがダウンしたから、システムが全停止したというのはキャッシュとして間違った使い方をしている証拠です。
（もちろん、パフォーマンスが下がって部分的にタイムアウトが発生することはあるでしょうが）
これを担保するためにも、開発サーバではランダムな期間ごとに全データを削除する、もっと言うとサーバをダウンさせるようにすると良いです。キャッシュ（サーバ）が存在していることに依存したコードが書けなくなります。
Redis 本番障害から学んだコードレビューの勘所にもある、よくありがちな「キャッシュサーバのつもりがいつの間にかストレージとして使われていた」問題はこれで防げていたでしょう。
Redisをストレージとして使う必要がある。のであれば、ストレージとして設計をした別Redisを立てて役割を分けるべきです。
キャッシュサーバ用Redisに突っ込むデータはTTL指定必須。TTL指定ができないデータのみストレージ用Redisに入れるようにします。
当然ストレージ用ですから二重化（レプリケーション）必須だし、ディスクへの退避設定(AOF)、定期バックアップの仕組みも必要でしょう。…とここまでくると大変なので、結局はRDBやS3などのファイルストレージにオリジナルを保存して、キャッシュを用Redisにコピーする。という運用にしたほうが簡単だとは思いますが、どうしてもストレージ用Redisが必要ならそうするべきです。
キャッシュを上手に手なづけて、良いサービスライフを。