1. 单机模式

Redis 单副本，采用单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。

优点：

• 架构简单，部署方便。
• 高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务。
• 高性能。

缺点：

• 不保证数据的可靠性。
• 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。
• 高性能受限于单核 CPU 的处理能力(Redis 是单线程机制)，CPU 为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用 Memcached 替代。

2. 主从架构

主（master）和 从（slave）部署在不同的服务器上，当主节点服务器写入数据时会同步到从节点的服务器上，一般主节点负责写入数据，从节点负责读取数据。

从节点设置只读属性，而主节点没有只写属性，因此，主节点可读可以写

优点：

• 读写分离，提高效率
  主节点负责写操作，从节点负责读操作；如果写少读多场景，配置多个从节点的话，效率非常高
• 数据热备份，提供多个副本。
  从节点宕机，影响较小

缺点：

• 主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预。

  因为只有主节点能进行写操作，一旦主节点宕机，整个服务就无法使用。当然此时从节点仍可以进行读操作，但是对于整个服务流程来说，是无法使用的。

• Master的写的压力难以降低。

  如果写操作比较多，那么只有一个主节点的话，无法分担压力。

• 主节点存储能力受到单击限制。

  主节点只能有一个，因此单节点内存大小不会太大，因此存储数据量受限。

• 主从数据同步，可能产生部分的性能影响甚至同步风暴。

  风暴问题，对于任何集群分布式来说都存在，要合理分布节点。

3. 哨兵

  Redis哨兵模式是是一个管理多个 Redis 实例的工具，它可以实现对 Redis 的监控、通知、自动故障转移，是Redis实现高可用 的实现方案。

为什么需要Redis哨兵模式？

  Redis主从模式当主服务器宕机后，需要手动把一台从服务器切换为主服务器，需要人工干预费事费力，为了解决这个问题出现了哨兵模式。

如下图所示：

如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般。

优点：

• 对节点进行监控，来完成自动的故障发现与转移

缺点：

• 特别是在主从切换的瞬间存在访问瞬断的情况，等待时间比较长，至少十来秒不可用。
• 哨兵模式只有一个主节点对外提供服务，没法支持很高的并发
• 单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

与主从相比，哨兵仅解决了手动切换主从节点问题，至于其他的问题，基本上仍然存在。

哨兵的主要问题还是由于中心架构，仅存在一个master节点引起的，写的效率太低。

4. 集群模式

Redis Cluster 是 3.0 版后推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。

Redis Cluster 集群节点最小配置 6 个节点以上(3 主 3 从)，其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。

注意：集群模式下 从节点不提供读写，与主从模式不一样。 总结一下经验，分布式 场景下：集群模式一般从节点不参与读写，仅作为备用节点。而主从一般都要负责读或写，都要参与具体的工作。

优点：

• 无中心架构。

  即有多个master节点，不像哨兵模式下仅有一个。这样写的压力就可以分散了；并且存储量也可以扩展了，因为多个主节点都可以存储一部分数据，总量要远大于单主节点架构。
  

• 数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

• 可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除。

• 高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够 实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升。

  当然，如果某个槽归属的小群内都不可用时，整个服务仍然是不可用的！通过cluster-require-full-coverageyes 控制该特性， 默认yes 即需要集群完整，方可对外提供服务，设置为no ，其他的小集群仍然可以对外提供服务。

缺点：

• 如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

5. 哈希槽是什么？

在redis集群中，一共会虚拟出16384个槽位来存储数据集，这16384个槽位分别映射到各个节点上。

哈希槽的计算规则

(1）假设主节点的数量为3，将16384个槽位按照用户自己的规则手动去分配这3个节点，16384除以4，那么每个节点大约得到5460个槽。（用户自定义分配的原因在于有些机器的配置高，有些机器的配置低，配置高的可以分配多一点槽位，配置低的可以分配少一点槽位）

(2)存储数据时，对要存储的键进行crc16哈希运算,得到一个值，并取模16384，判断这个值在哪个节点的范围区间。

  假设crc16(“test_key”)%16384=3345，
  因为3345在区间0-5460之间，
  所以test_key数据写入到节点1里面。

(3)查询数据时，对要查询的键进行crc16哈希运算,得到一个值，并取模16384，判断这个值在哪个节点的范围区间。

  假设crc16(“test_key”)%16384=3345，

  因为3345在区间0-5460之间，

  所以test_key数据应该从节点1里面获取。

  以上就是redis集群采用的虚拟哈希槽的原理和计算规则说明，是不是没有想象的那么复杂。

关于哈希槽的一些疑问

1、 为啥要设置2^14个槽位？

  理论上crc16算法可以得到2^16个数值，其数值范围在0-65535之间，取模运算key的时候，应该是crc16(key)%65535，但是却设计为crc16(key)%16384，原因是作者在设计的时候做了空间上的权衡，觉得节点最多不可能超过1000个，同时为了保证节点之间通信效率，所以采用了2 ^14。

2、 为什么redis集群不采用一致性哈希算法：

  一致性哈希的节点分布基于圆环，无法很好的手动控制数据分布，比如有些节点的硬件差，希望少存一点数据，这种很难操作。

  redis集群的槽位空间是可以用户手动自定义分配的，类似于 windows 盘分区的概念，可以手动控制大小。

  其实，无论是一致性哈希还是哈希槽的方式，在增减节点的时候，都会对一部分数据产生影响，都需要我们迁移数据，当然，redis集群也提供了相关手动迁移槽数据的命令。