聊聊五种 Redis 部署模式

这篇文章，分享自己职业生涯经历的五种 Redis 部署模式，希望对大家有所启发。

1 单实例

这是 Redis 最简单、最基础的部署方式，即：整个 Redis 服务运行在单个服务器 和单个进程中。

笔者第一次在生产环境使用 Redis ，是在艺龙红包系统中，使用 Redis 实现分布式锁。

因为上线时间要求比较着急，运维说有一个实例可以不用申请，可以直接用，于是就采用了单实例的模式。笔者还特意和运维说假如 Redis 挂了，就通过 Linux 定时任务重新启动。

单实例模式的优点显而易见：简单（部署、配置、维护） ，但缺点同样突出：服务器宕机，服务将完全不可用，同时内存大小受限于服务器。

在艺龙红包系统初版上线后，团队架构师向我介绍了Redis的高可用方案------主从复制+哨兵集群模式。这种部署模式通过主从数据同步实现数据备份，配合哨兵集群的自动故障检测与主从切换能力，能够有效保障服务的高可用性。

如图所示的架构中：

通过这种改造，红包系统的缓存架构获得了质的提升：不仅避免了单点故障风险，还实现了读写分离，整体系统的稳定性和可用性都得到了显著增强。即便在突发故障情况下，也能保证红包业务持续稳定运行。

「主从 + 哨兵」模式非常健壮，但假如缓存数据量非常大，这种模式就有瓶颈了，于是需要多组 Redis 实例才能满足业务需求。

艺龙的流式计算服务的计算过程大量依赖存这种多 Redis 实例模式，如下图：

我们可以采用一致性哈希算法实现数据分片：

流式计算的 Redis 集群都仅仅采用单主集群模式，存在一定的高可用风险，比如某个分片挂掉了，整个系统就会出现问题。

解决方案其实也很简单：

架构图就变成下图的缓存部署架构（神州专车订单缓存部署架构）：

当我们再来看「分片集群 + 一致性 Hash」这种模式时，虽然看起来很完美，但是有一个隐形的缺点：

当新增分片时，如何做到数据可以平滑迁移到新的分片节点？

解决这种问题最有效的方案是：预分配槽位 。

笔者曾经介绍过专车的分库分表算法，假设现在需要将订单表平均拆分到 4 个分库 shard0 ，shard1 ，shard2 ，shard3 。

首先将 [0-1023] 平均分为4个区段：[0-255]，[256-511]，[512-767]，[768-1023]，然后对字符串（或子串，由用户自定义）做 hash， hash 结果对 1024 取模，最终得出的结果 slot 落入哪个区段，便路由到哪个分库。

我们可以将分库分表的预分配理论应用到 Redis 分片集群中，见下图：

大名鼎鼎的开源项目 Codis 也是使用预分配的技巧，「分片集群 + 预分配」既可以保留分片集群的可扩展的优势，也可以通过预分配槽位的技巧实现较为平滑的数据迁移，但数据迁移还是非常考验架构师的功底。

有没有一种方案可以支持所有的特性呢？

有的，它来了，它就是：官方 Redis Cluster 。

笔者在花生好车和科大讯飞都使用过 Redis Cluster 这种模式。

Redis Cluster 集群具有如下几个特点：

集群完全去中心化，采用多主多从；
每一个分区都是由一个Redis主机和多个从机组成，分片和分片之间是相互平行的。
Redis Cluster 无需部署哨兵集群，集群内 Redis 节点通过 Gossip 协议互相探测健康状态，在故障时可发起自动切换。
Redis Cluster将数据分为16384个槽位，每个节点负责管理一部分槽位。
当客户端向 Redis Cluster 发送请求时，Cluster 会根据键的哈希值将请求路由到相应的节点。具体来说，Redis Cluste r使用 CRC16 算法计算键的哈希值，然后对16384 取模，得到槽位编号。
Redis Cluster 提供了「配套」的 SDK，只要客户端升级 SDK，就可以和 Redis Cluster 集成，SDK 会帮你找到 key 对应的 Redis 节点进行读写，还能自动适配 Redis 节点的增加和删除，业务侧无感知。

Redis Cluster 从功能来讲，已经趋近于完美，在提供高可用性的同时，实现了数据分片和负载均衡，适用于大规模数据存储和高性能要求的场景。但是配置和运维相对复杂，以及一些复杂的多键操作可能受到限制。

在 Redis 的部署模式演进过程中，从单实例到 Redis Cluster，我们看到了不同架构的优缺点。

但没有一种方案是完美的银弹，每种模式都有其适用场景和局限性。

所以，我们需要理解业务需求，权衡性能、扩展性和运维成本，才能做出最佳的选择。