redis的单机、哨兵、集群模式对比

redis作为集中式的数据库中间件，它具有持久化的能力，但是需要容许少量数据的丢失。

单机版

生成环境不建议使用，有单点故障风险。一旦单台结点出现故障，可能会导致整个服务不可用

sentinal哨兵模式

另外引入一台结点redis sentinal（哨兵），会与其他的redis结点保持长连接（心跳机制），它实时地感应到其他redis结点的状态，客户端进行访问时，会向redis sentinal询问可用的redis服务结点，redis sentinal会返回可用的redis结点的信息。客户端获取到信息后再去访问对应的redis结点，并且会将连接信息保存到本地。

当可用的redis结点信息发生变化的时候，redis sentinal会调整对应的结点关系（主从关系），然后向客户端发送一个change通知，告诉它redis结点发生变化，客户端就会重新想redis sentinal发送请求获取新的结点信息。

当redis结点中有多个主从复制，客户端如何知道何时将请求发给哪个master呢？
客户端本地维护了一个分片机制，它通过redis sentinal明确地知道有两个master结点，通过对master机器的IP值进行hash，将数据按照不同的策略路由到不同的master结点。
它有一些缺点：

• 它需要在客户端做比较复杂的分片逻辑。增加了客户端与redis结点之间的耦合
• 随着业务的发展，我们以前定义的redis结点不够用的需要新增redis结点的时候，会设计到数据迁移的过程，这个过程是比较繁琐的。

集群cluster模式

多个redis结点，redis会自动竞选出master和slave结点，并且集群中的每个redis都和其他多台redis有网状结构，redis能清晰地直到我的主/从是谁，我们其他分片的主从信息，也就是每个redis结点中都有维护整个集群结构的信息，这都是基于redis-cluster的数据同步和paxos的竞争算法来实现的。

当客户端访问其中的一个结点时，就能获取整个集群结点的信息，并保存到本地。若有结点宕机，集群会自动进行调整更新信息，然后每个结点维护一份新的信息，此时客户端按照旧的集群信息访问到一个不属于新的集群管理范围的key的时候，redis会发送一个reask请求，通知客户端获取新的集群信息

当redis4宕机后，redis会发送一个reask请求，通知客户端获取新的集群信息

集中模式对比

• 生产环境中不要使用单机版
• 哨兵模式是由客户端本地来维护redis结点之间的信息，而集群模式是由结点来维护所有结点之间的连接关系
• sentinal哨兵模式存在缺陷，在水平拓展redis结点的情况下，需要客户端在本地维护分片机制（客户端与redis结点之间存在耦合），并且如果此时需要再继续进行拓展，那么就会有一个数据迁移的过程，这个过程是繁琐的。
• 而集群模式却不需要客户端来进行分片机制的维护，并且每个客户端中都维护了整个集群网络的信息，进行客户端与redis集群之间的解耦，并且更加易于拓展。