Redis 内存为什么不宜过大

本文转载自  HULK一线技术杂谈。 近几年来，随着 Redis 的发展壮大，被越来越多的人所熟知，越来越多的企业也使用了Redis。今天我们来分享下 Redis 单实例内存过大遇到的问题以及解决方案。

近两年我们 HULK 云平台承载的Redis日访问量从800+亿增加到了2100+亿，Redis实例数也增长到了5000+。

在这几年的线上业务的使用中表明，Redis这个内存数据库，它的高性能、稳定性都是不用怀疑的。但在运维过程中，我们走过的路，踩过的坑也不少。今天来讨论一下，如果单实例内存过大，如果一旦出问题，那它可能会带给我们的就是灾难性（我想很多公司都遇到过）， 这里列举一下单实例内存过大可能会遇到的一些问题：

先来看一下主库宕机容灾过程，如下图：

在主库宕机的时候，我们最常见的容灾策略为“切主”。具体为从该集群剩余从库中选出一个从库并将其升级为主库，该从库升级为主库后再将剩余从库挂载至其下成为其从库，最终恢复整个主从集群结构。以上是一个完整的容灾过程，而代价最大的过程为从库的重新挂载，而非主库的切换。 

很明显，在这个过程中Redis的内存体积越大以上每一个步骤的时间都会被拉长，实际测试的数据如下（我们自认我们的机器性能比较好）：

最后，有同学可能会说了，我数据量就那么大怎么办。我们的终极大杀器Pika就不得不登台了。

Pika 是DBA和基础架构组联合开发的大容量、高性能、多线程、持久化的类Redis存储系统。Pika中的数据使用磁盘而非内存，多线程的结构设计，保证了在使用磁盘的同时还拥有强劲的性能。它支持多数据结构，完全支持Redis协议。用户无需换驱动，无需改代码，支持从Redis实时同步数据的无缝迁移。如果把业务迁移到新开源的Pika上面，这样就不用太关注内存了，Redis内存太大引发的问题，那也都不是问题了。感兴趣的同学快来试试吧！