redis這個內存數據庫，它的高性能、穩定性都是不用懷疑的，但我們塞進redis的數據過多，內存過大，那如果出問題，那它可能會帶給我們的就是災難性。
這幾年的線上業務表明，redis這個內存數據庫，它的高性能、穩定性都是不用懷疑的，但我們塞進redis的數據過多，內存過大，那如果出問題，那它可能會帶給我們的就是災難性(我想很多公司都遇到過) 這里列舉一下，我們遇到的一些問題：
主庫宕機? ? ? ? ? ? （推薦學習：Redis視頻教程）
先來看一下主庫宕機容災過程，如下圖：
在主庫宕機的時候，我們最常見的容災策略為“切主”。具體為從該集群剩余從庫中選出一個從庫并將其升級為主庫，該從庫升級為主庫后再將剩余從庫掛載至其下成為其從庫，最終恢復整個主從集群結構。
以上是一個完整的容災過程，而代價最大的過程為從庫的重新掛載，而非主庫的切換。
解決辦法
解決辦法當然就是極力減少內存的使用了，一般情況下，我們都是這么做的：
1 設置過期時間
對具有時效性的key設置過期時間，通過redis自身的過期key清理策略來降低過期key對于內存的占用，同時也能夠減少業務的麻煩，不需要定期清理了
2 不存放垃圾到redis中
這簡直就是廢話，但是，有跟我們同病相憐的人么?
3 及時清理無用數據
例如一個redis承載了3個業務的數據，一段時間后有2個業務下線了，那你就把這兩個業務的相關數據清理了唄
4 盡量對數據進行壓縮
例如一些長文本形式的數據，壓縮能夠大幅度降低內存占用
5 關注內存增長并定位大容量key
不管是DBA還是開發人員，你用redis，你就必須關注內存，否則，你其實就是不稱職的，這里可以分析redis實例中哪些key比較大從而幫助業務快速定位異常key(非預期增長的key，往往是問題之源)
6 pika
如果實在不想搞的那么累，那就把業務遷移到新開源的pika上面，這樣就不用太關注內存了，redis內存太大引發的問題，那也都不是問題了。
更多Redis相關技術文章，請訪問Redis視頻教程欄目進行學習！
