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数据库使用入门教程栏目进行学习！
