- standalone类型架构
用于可穿透业务场景，如后端有DB存储，脱机影响不大的应用。
2、redis主从
假设我们生产环境使用了一台redis，redis挂了怎么办？如果等到运维重启redis，并恢复好数据，可能需要花费很长时间。那么在这期间，我们的服务是不可用的，这应该是不能容忍的。假设我们做了主从，主库挂了之后，运维让从库接管，那么服务可以继续运行，正所谓有备无患。
是备份关系， 我们操作主库，数据也会同步到从库。 如果主库机器坏了，从库可以上。就好比你 D盘的片丢了，但是你移动硬盘里边备份有。
3、sentinel类型架构
用于高可用需求场景，可用于高可用Cache，存储等场景。内存/QPS受限于单机。
从库作为一个“傀儡”，可以在需要的时候“顶上来”，”接盘“。我们配置的主从是为了”有备无患“，在主redis挂了之后，可以立马切换到从redis上，可能只需要花几分钟的时间，但是仍然是需要人为操作。假设主redis在晚上23点挂了，10分钟之后你接到电话，老板让你赶紧修复，于是你从被窝爬起来整，岂不是很头疼。假如你关机了，又其他人知道服务器密码，那系统岂不是要停机一晚上？太可怕了。
这个时候redis sentinel 就派上用场了。sentinel 通常翻译成哨兵，就是放哨的，这里它就是用来监控主从节点的健康情况。客户端连接redis主从的时候，先连接 sentinel，sentinel会告诉客户端主redis的地址是多少，然后客户端连接上redis并进行后续的操作。当主节点挂掉的时候，客户端就得不到连接了因而报错了，客户端重新想sentinel询问主master的地址，然后客户端得到了[新选举出来的主redis]，然后又可以愉快的操作了。
.png)
4、cluster类型架构
用于高可用需求场景，可用于大数据量高可用Cache/存储等场景。内存/QPS不受限于单机，可受益于分布式集群高扩展性。
我们分别学习了redis 单点，redis主从，并增加了高可用的 sentinel 哨兵模式。我们所做的这些工作只是保证了数据备份以及高可用，目前为止我们的程序一直都是向1台redis写数据，其他的redis只是备份而已。实际场景中，单个redis节点可能不满足要求，因为：
-
单个redis并发有限
-
单个redis接收所有的数据，最终回导致内存太大，内存太大回导致rdb文件过大，从很大的rdb文件中同步恢复数据会很慢。
所以，我们需要redis cluster 即redis集群。
Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:
-
自动分割数据到不同的节点上。
-
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
为了配置一个redis cluster,我们需要准备至少6台redis，为啥至少6台呢？我们可以在redis的官方文档中找到如下一句话：
Note that the minimal cluster that works as expected requires to contain at least three master nodes.
因为最小的redis集群，需要至少3个主节点，既然有3个主节点，而一个主节点搭配至少一个从节点，因此至少得6台redis。
.png)
