Redis配置那事儿，怎么弄着能随时扩展，不用重头来过

主要基于Redis官方文档关于持久化、复制、集群的核心思想,并结合常见的云服务商最佳实践进行阐述）

得明白一个核心道理：想让Redis能随时扩展，关键不在于扩展那一刻的操作，而在于平时的“基本功”，就像盖房子，地基打得牢，往上加楼层才稳当，对于Redis来说，这个“地基”就是数据的安全性和服务的可用性，如果数据动不动就全丢了，或者服务动不动就彻底瘫痪,那谈扩展就没有任何意义。

第一件要紧事是把数据持久化做好，保证数据不会因为服务器断电或重启就消失，Redis提供了两种主要方式（来源：Redis持久化文档），一种是RDB，你可以把它理解为“拍快照”，Redis会定期将内存里所有的数据整个打包成一个文件，存到硬盘上，这个方式的优点是恢复起来很快，文件也比较紧凑，缺点是如果两次快照之间服务器宕机，这段时间的数据就没了，另一种方式是AOF，像是“写日记”，Redis会把每一个写命令都记录下来，追加到一个文件里，当Redis重启时，重新执行一遍这个“日记”里的所有命令，就能恢复数据，这种方式数据安全性高，最多损失一秒的数据（如果配置为每秒同步一次的话），但文件通常会比RDB大,恢复速度也慢一些。

最稳妥的做法是两者同时开启（来源：Redis生产环境推荐配置），用AOF来保证数据不丢失，作为数据恢复的首选，定期创建一个RDB文件，这个文件既可以作为一个额外的备份，也可以用于快速恢复某个历史时间点的数据，或者方便地把数据迁移到另一台机器上，这样，即使当前这台主服务器彻底坏了，你手里也有一份足够新的、可靠的数据副本,这是能够进行扩展的前提。

有了可靠的数据副本，接下来要解决的是服务不间断的问题，这就是主从复制（来源：Redis复制文档）要干的事，你至少需要两台服务器，一台是主服务器，负责处理所有的写操作；另一台或多台是从服务器，它们几乎是实时地从主服务器那里复制数据，平常，读请求可以分流到从服务器上，减轻主服务器的压力，更重要的是，一旦主服务器出故障了，你可以手动（或者借助工具自动地）快速将一台从服务器“提拔”成新的主服务器，这样应用程序只需要修改一下连接地址，就能继续提供服务，实现了高可用，这个从服务器，就是你未来进行“垂直扩展”（升级单机性能）或“水平扩展”（增加服务器数量）的种子。

当你的数据量变得非常大，一台机器的内存再也装不下时，或者写操作频繁到一台机器处理不过来时，就必须进行水平扩展了，这就是Redis集群（来源：Redis集群教程）的用武之地，Redis集群的功能是把整个数据集自动分割成16384个槽位，然后把这些槽位合理地分配给你集群里的多个主节点，每个主节点只负责存储一部分数据，对于客户端来说，它可以从集群获取一份“槽位分布图”，当它要读写一个键时，自己能算出这个键属于哪个槽位,应该连接哪个节点去操作。

配置Redis集群听起来复杂，但它的好处是根本性的，它实现了真正的分布式存储，数据可以突破单机内存限制，它内置了高可用，每个分片的主节点都可以有从节点跟着，主节点挂了，从节点会自动接替，最关键的是，扩展起来相对平滑，当你想增加新的节点来分担压力时，只需要将现有某些节点上的一部分槽位和对应的数据迁移到新节点上即可，这个过程是在线进行的，集群仍然可以正常提供服务，只是正在迁移的那部分数据可能会有短暂的延迟，这比你手动分片，然后停机、导数据、改配置再重启要优雅得多。

还有一些配置技巧能让扩展更顺畅，给你的Redis实例配上一个有意义的、清晰的“别名”，而不是让应用程序直接连接服务器的IP地址，这样当你在后台把数据从一个服务器迁移到另一个服务器时，只需要改变这个别名指向的新地址就行了，应用程序完全无感知,这通常需要一个额外的服务发现组件或者负载均衡器来实现。

想要Redis能随时扩展，不用每次都伤筋动骨，你需要三步走：第一，用RDB和AOF打好数据持久化的底子，确保数据安全，第二，搭建主从复制，实现读写分离和高可用，为扩展准备好“备胎”，第三，在需要应对海量数据时，采用Redis集群方案，它提供了自动分片和故障转移，使得增加或减少节点变得可控和平滑，养成使用连接别名等好习惯，将变化封装在后台，这一切的核心思想就是：将数据、服务与具体的服务器解耦,让你的系统变得有弹性。