Redis三种集群方式

Redis有三种集群方式
主从复制，哨兵模式和Redis-Cluster集群。

主从复制

主从复制优缺点
优点：
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据
缺点：
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

主从复制原理

Redis主从复制包括全量复制和增量复制。
全量复制是发生在初始化阶段，从节点会主动向主节点发起一个同步请求，主节点收到请求后会生成一份当前数据的快照发送给从节点，从节点收到数据进行加载后完成全量复制。
增量复制是发生在每次Master数据发生变化的过程中，会把变化的数据同步给所有的从节点。
增量复制是通过维护Offset这个复制偏移量来实现的。
当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。
如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

Redis 主从同步包括三个阶段。
第一阶段：主从库间建立连接、协商同步。
从库向主库发送 psync 命令，告诉它要进行数据同步。主库收到 psync 命令后,响应 FULLRESYNC 命令（它表示第一次复制采用的是全量复制），并带上主库 runID 和主库目前复制进度 offset。
第二阶段：主库把数据同步到从库，从库收到数据后，完成本地加载
主库执行 bgsave 命令，生成 RDB 文件，接着将文件发给从库。从库接收到 RDB文件后，会先清空当前数据库，然后加载 RDB 文件。主库把数据同步到从库过程中，新来写操作，会记录到 replicationbuffer。
第三阶段，主库把新写命令，发送到从库
主库完成 RDB 发送后，会把 replication buffer 中✁修改操作发给从库，从
库再重新执行这些操作。这样主从库就实现同步啦。
主从复制
全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

• 从服务器连接主服务器，发送SYNC命令；
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
数据同步，slave是定时会发起的，假如每次同步，都把主的所有数据都进行同步，那么性
能会很慢，大部分时候，slave可能只跟master相差一部分数据。那么只需要同步这部分
数据。
slave发起同步的时候，还会带有上次同步的偏移量，然后跟master的最新的偏移量比较，
如果相差的数据在master的积压缓存（一个专门存储master最新数据并且会覆盖的内存区
间）能查询到的话，那么只需要把相差的数据同步给slave。这就叫做增量同步。
指令同步：master输入的指令会异步同步给slave。
Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

主从数据不一致
因为主从复制是异步进行，如果从库滞后执行，则会导致主从数据不一致。
主从数据不一致一般有两个原因：
主从库网路延迟。
从库收到了主从命令，但是它正在执行阻塞性命令（如 hgetall等）
如何解决主从数据不一致问题
可以换更好硬件配置，保证网络畅通。
2. 监控主从库间复制进度
读取过期数据

哨兵模式

Redis哨兵模式是一种用于监控和管理Redis主从复制架构的解决方案。它可以帮助确保高可用性，对于主节点的故障可以进行自动故障转移，从而避免服务中断。以下是关于Redis哨兵模式的详细解释：
监控：Redis哨兵通过周期性地检查Redis实例的健康状态来监控系统。如果发现主节点不可用，哨兵可以自动将一个从节点升级为新的主节点。
故障检测：当哨兵检测到主节点不可用时，它会开始一系列的故障检测步骤，确认主节点是否真的不可用，以避免错误地进行故障切换。
自动故障转移：一旦哨兵确定主节点不可用，它将会协调从节点中选举出一个新的主节点，并通知所有的客户端。这个过程是自动的，无需人工干预。
配置管理：哨兵也负责管理Redis集群的配置信息，包括记录当前的主从关系、故障切换的历史等。
通知机制：哨兵可以向管理员发送警报，通知主节点故障和自动故障转移的发生。
总的来说，Redis哨兵模式提供了一种简单而有效的方法来确保Redis集群的高可用性。通过监控、自动故障转移和通知机制，它可以帮助管理员及时处理主节点故障并避免服务中断。使用哨兵模式可以让Redis集群更加稳定可靠，适用于需要高可用性的生产环境。

如果我们在使用主从复制的情况下，Master服务器进行了down机的情况，我们的系统就不能再进行写的操作，所以此时redis在2.6版本引入了哨兵模式，但是并不稳定，2.8版本之后哨兵模式才稳定了起来。
顾名思义Redis的哨兵模式就是对redis系统进行实时的监控，其主要功能有下面两点
1.监测主数据库和从数据库是否正常运行。
2.当我们的主数据库出现故障的时候，可以自动将从数据库转换为主数据库，实现自动的切换。
修改配置说明当master主服务器down机之后，剩下的服务器要进行一个投票选举出一个主服务器
默认配置哨兵0.5ms进行一次检查这个集群。可以配置几个从节点将支持转换为主服务器的这个事情

哨兵作用
哨兵其实是一个运行在特殊模式下 Redis 进程。它有三个作用，分别是：
监控、自动选主切换（简称选主）、通知。
哨兵进程在运行期间，监视所有Redis 主节点和从节点。它通过周期性给主从库发送 PING命令，检测主从库是否挂了。如果从库没有在规定时间内响应哨兵PING命令，哨兵就会把它标记为下线状态；如果主库没有在规定时间内响应哨兵PING命令，哨兵则会判定主库下线，然后开始切换到选主任务。
所谓选主，其实就是从多个从库中，按照一定规则，选出一个当做主库。至于通知呢，就是选出主库后，哨兵把新主库连接信息发给其他从库，让它们和新主库建立主从关系。同时，哨兵也会把新主库连接信息通知给客户端，让它们把请求操作发到新主库上。

哨兵如何判定主库下线
兵是如何判断主库是否下线呢？我们先来了解两个基础概念哈：主观下线和客观下线。
哨兵进程向主库、从库发送 PING 命令，如果主库或者从库没有在规定时间内响应 PING 命令，哨兵就把它标记为主观下线。如果是主库被标记为主观下线，则正在监视这个主库所有哨兵要以每秒一次频率，以确认主库是否真进入了主观下线。 当有多数哨兵（一般少数服从多数，由 Redis 管理员自行设定一个值）在指定时间范围内确认主库确进入了主观下线状态，则主库会被标记为客观下线。这样做目就是避免对主库误判，
以减少没有必要主从切换，减少不必要开销。

哨兵的核心知识
哨兵至少需要 3 个实例，来保证自己的健壮性。
哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了 2 个哨兵实例，quorum = 1。
±—+ ±—+ | M1 |---------| R1 | | S1 | | S2 | ±—+ ±—+
配置 quorum=1，如果 master 宕机， s1 和 s2 中只要有 1 个哨兵认为 master 宕机了，就可以进行切换，同时 s1 和 s2 会选举出一个哨兵来执行故障转移。但是同时这个时候，需要 majority，也就是大多数哨兵都是运行的。
2 个哨兵，majority=2 3 个哨兵，majority=2 4 个哨兵，majority=2 5 个哨兵，majority=3 …
如果此时仅仅是 M1 进程宕机了，哨兵 s1 正常运行，那么故障转移是 OK 的。但是如果是整个 M1 和 S1 运行的机器宕机了，那么哨兵只有 1 个，此时就没有 majority 来允许执行故障转移，虽然另外一台机器上还有一个 R1，但是故障转移不会执行。
经典的 3 节点哨兵集群是这样的：
±—+ | M1 | | S1 | ±—+ | ±—+ | ±—+ | R2 |----±—| R3 | | S2 | | S3 | ±—+ ±—+
配置 quorum=2，如果 M1 所在机器宕机了，那么三个哨兵还剩下 2 个，S2 和 S3 可以一致认为 master 宕机了，然后选举出一个来执行故障转移，同时 3 个哨兵的 majority 是 2，所以还剩下的 2 个哨兵运行着，就可以允许执行故障转移。
redis 哨兵主备切换的数据丢失问题
两种情况和导致数据丢失
主备切换的过程，可能会导致数据丢失：
异步复制导致的数据丢失
因为 master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。

脑裂导致的数据丢失
脑裂，也就是说，某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master 还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 master ，也就是所谓的脑裂。
此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的 master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了。

Redis哨兵机制实现故障转移时，选举从节点变成主节点的因素有（）
断开连接时长
优先级排序（replica-priority配置）
数据偏移量
进程ID

Redis Cluster集群

Redis-Cluster是Redis提供的用于分布式部署的集群方案，它能够提供高可用性、横向扩展和自动分片等功能。以下是关于Redis-Cluster集群的一些详细信息：

1. 横向扩展：Redis-Cluster允许将数据分布在多个节点上，从而可以横向扩展以处理大规模的数据和流量。每个节点都可以独立地处理一部分数据和请求。
2. 高可用性：Redis-Cluster通过使用主从复制和故障转移来确保高可用性。如果一个主节点不可用，集群会自动将一个从节点升级为新的主节点，从而避免服务中断。
3. 自动分片：Redis-Cluster使用哈希槽（hash slot）来自动分片数据到不同的节点上。这样可以简化数据分布和管理，同时也能够实现负载均衡。
4. 节点间通信：在Redis-Cluster中，节点之间通过gossip协议进行通信，用于发现其他节点、同步集群配置信息、故障检测等。
5. 客户端路由：Redis-Cluster客户端可以通过集群的任意节点进行读写操作，集群会自动将请求路由到正确的节点上。
6. 动态扩缩容：Redis-Cluster支持动态增加和删除节点，可以根据实际需求来调整集群的规模。
   总的来说，Redis-Cluster提供了一种方便、高效的方式来构建分布式的Redis环境。它适用于需要处理大量数据和并发请求的场景，能够提供高可用性和可扩展性。使用Redis-Cluster可以让管理员更容易地管理大规模的Redis部署，并且能够满足不同规模和需求的应用。

哨兵模式下虽然解决了Master选举的问题，但是在线扩容的问题还是没有解决。于是就有了第三种集群方式，Redis Cluster，它实现了Redis的分布式存储，也就是每个节点存储不同的数据实现数据的分片。
在Redis Cluster中，引入了Slot槽来实现数据分片，Slot的整体取值范围是0~16383，每个节点会分配一个Slot区间当我们存取Key的时候，Redis根据key计算得到一个Slot的值，然后找到对应的节点进行数据的读写。
群集至少需要3主3从，且每个实例使用不同的配置文件。
在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，
若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。
在redis的官方文档中，对redis-cluster架构上，有这样的说明：在cluster架构下，默认的，一般redis-master用于接收读写，而redis-slave则用于备份，当有请求是在向slave发起时，
会直接重定向到对应key所在的master来处理。
但如果不介意读取的是redis-cluster中有可能过期的数据并且对写请求不感兴趣时，则亦可通过readonly命令，将slave设置成可读，然后通过slave获取相关的key，达到读写分离。
哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Cluster集群应运而生，它在Redis3.0加入的，实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它也提供复制和故障转移的功能。

Cluster集群节点的通讯
一个Redis集群由多个节点组成，各个节点之间是怎么通信的呢？通过Gossip协议！
Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种，分别是：ping、pong、meet、fail。

meet消息：通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。
ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。
pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。
fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态
特别的，每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时，使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

哈希槽
我们的key会通过一个hash算法，然后取模16384得到一个0到16383的值。
这个虚拟槽又会对应到不同的机器，并且虚拟槽跟机器的对应关系是能手动维护的，这样我就知道这
个key会放在哪台机器呢。
并且整个集群维护会非常灵活，一些热点的key我都可以单独部署一台主。
你说key是根据一个hash算法得到虚拟槽的，那我希望一个订单相关的key都到一台机器，比如订单
的统计数据、订单的基本信息等等，是不同的key，会分散到不同的机器，查询就会查询多台机器，
怎么解决？
作者也想到了这个具体的业务问题，所以，当你希望相关的数据放在同一个key的话，你可以在key
上加{}.这样hash的算法只会去根据{}里面的值来进行虚拟槽的计算了。
Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分hash 槽。
Redis 一致性hash、hash槽
16384 个。这是因为Redis 集群并没有使用一致性hash，而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
一个切片集群被分为 16384个 slot（槽），每个进入 Redis ✁键值对，根据key 进行散列，分配到这 16384 插槽中一个。使用哈希映射也比较简单，用CRC16算法计算出一个 16bit✁值，再对 16384取模。数据库中每个键都属于这 16384 个槽✁其中一个，集群中✁每个节点都可以处理这 16384 个槽。集群中✁每个节点负责一部分哈希槽，假设当前集群有 A、B、C3 个节点，每个节点上负责✁哈希槽数 =16384/3，那么可能存在一种分配：
节点A 负责 0~5460 号哈希槽
节点B 负责 5461~10922 号哈希槽
节点C 负责 10923~16383 号哈希槽
这个比较偏， 知道的人不多， 如果你可以答出最大节点数，然后给出解释, 估计面试官的好感度, 会蹭蹭的往上涨。
16384 个。这是因为Redis 集群并没有使用一致性hash，而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

哈希槽的数量是16384（2^14）
在redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2 * 8 (8 bit) * 1024(1k) = 16K），也就是说使用2k的空间创建了16k的槽数。
虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) =65K），也就是说需要需要8k的心跳包，Redis作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

Hash Slot插槽算法
既然是分布式存储，Cluster集群使用的分布式算法是一致性Hash嘛？并不是，而是Hash Slot插槽算法。
插槽算法把整个数据库被分为16384个slot（槽），每个进入Redis的键值对，根据key进行散列，分配到这16384插槽中的一个。使用的哈希映射也比较简单，用CRC16算法计算出一个16 位的值，再对16384取模。数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽。
集群中的每个节点负责一部分的hash槽，比如当前集群有A、B、C个节点，每个节点上的哈希槽数 =16384/3，那么就有：
节点A负责0~5460号哈希槽
节点B负责5461~10922号哈希槽
节点C负责10923~16383号哈希槽

Redis Cluster集群中，需要确保16384个槽对应的node都正常工作，如果某个node出现故障，它负责的slot也会失效，整个集群将不能工作。
因此为了保证高可用，Cluster集群引入了主从复制，一个主节点对应一个或者多个从节点。当其它主节点 ping 一个主节点 A 时，如果半数以上的主节点与 A 通信超时，那么认为主节点 A 宕机了。如果主节点宕机时，就会启用从节点。
在Redis的每一个节点上，都有两个玩意，一个是插槽（slot），它的取值范围是0~16383。另外一个是cluster，可以理解为一个集群管理的插件。当我们存取的key到达时，Redis 会根据CRC16算法得出一个16 bit的值，然后把结果对16384取模。酱紫每个key都会对应一个编号在 0~16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
虽然数据是分开存储在不同节点上的，但是对客户端来说，整个集群Cluster，被看做一个整体。客户端端连接任意一个node，看起来跟操作单实例的Redis一样。当客户端操作的key没有被分配到正确的node节点时，Redis会返回转向指令，最后指向正确的node，这就有点像浏览器页面的302 重定向跳转。
故障转移
Redis集群实现了高可用，当集群内节点出现故障时，通过故障转移，以保证集群正常对外提供服务。
redis集群通过ping/pong消息，实现故障发现。这个环境包括主观下线和客观下线。
主观下线： 某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况。

redis Cluster并非采用传统的一致性hash算法，而是通过虚拟槽的方式去实现，解决了节点数据不均匀问题。
redis Cluster主从切换功能不需要依赖哨兵。redis Cluster采用虚拟槽的概念，会创建16384个虚拟槽，每个数据key都会对应一个虚拟槽，redis节点可以配置虚拟槽范围
Redis 集群的主从复制模型是怎样的
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有 N-1 个复制品
Redis 集群会有写操作丢失吗
Redis 并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作
Redis 集群之间是如何复制的：异步复制
Redis 集群最大节点个数是多少：16384 个
Redis 集群如何选择数据库：Redis 集群目前无法做数据库选择，默认在 0 数据库
怎么测试 Redis 的连通性：ping

codis与redis集群的区别

redis cluster基 于smart client去中心化的设计，client必须按key的哈希将请求直接发送到对应的节点。这意味着：
cluster必须要等对应语⾔的redis driver对cluster⽀持的开发和不断成熟；client不能直接像单机⼀样使⽤pipeline来提⾼效率，想同时执
⾏多个请求来提速必须在client端⾃⾏实现异步逻辑。 ⽽codis因其有中⼼节点、基于proxy的设计，对client来说可以像对单机redis⼀样
去操作proxy（除了⼀些命令不⽀持），还可以继续使⽤pipeline并且如果后台redis有多个的话速度会显著快于单redis的pipeline。同时
codis使 zookeeper来作为辅助，这意味着单纯对于redis集群来说需要额外的机器搭zk，不过对于很多已经在其他服务上了zk的公司来说这不是问题）

Redis 集群方案

1.twemproxy，大概概念是，它类似于一个代理方式，使用方法和普通 Redis 无任何区别，设置好它下属的多个 Redis 实例后，使用时在本需要连接 Redis 的地方改为连接twemproxy，它会以一个代理的身份接收请求并使用一致性 hash 算法，将请求转接到具体 Redis，将结果再返回 twemproxy。使用方式简便(相对 Redis 只需修改连接端口)，对旧项目扩展的首选。 问题：twemproxy 自身单端口实例的压力，使用一致性 hash 后，对Redis 节点数量改变时候的计算值的改变，数据无法自动移动到新的节点
2. codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 节点数量改变情况下，旧节点数据可恢复到新 hash 节点
3. Redis cluster3.0 自带的集群，特点在于他的分布式算法不是一致性 hash，而是 hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍
4.在业务代码层实现，起几个毫无关联的 Redis 实例，在代码层，对 key 进行 hash 计算，然后去对应的 Redis 实例操作数据。 这种方式对 hash 层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控等等
Redis 集群方案什么情况下会导致整个集群不可用
有 A，B，C 三个节点的集群,在没有复制模型的情况下,如果节点 B 失败了，那么整个集群就
会以为缺少 5501-11000 这个范围的槽而不可用

cluster是一个去中心化多主多从的集群架构。
cluster集群除了能实现主从自动切换以外，cluster还可以做到数据分片，我可以把我的数据灵活的
分散到不同的主，然后主对应的从会读取主的数据。
cluster里面会有个虚拟槽的概念，其实就是0-16383的一个数值。

Redis哨兵sentinel集群和Cluster集群区别

Redis哨兵集群是基于主从复制来实现的，所以它可以实现读写分离，分担Redis读操作的压力
而Redis Cluster 集群的Slave节点只是实现冷备机制，它只有在Master宕机之后才会工作。
Redis哨兵集群无法在线扩容，所以它的并发压力受限于单个服务器的资源配置。
Redis Cluster提供了基于Slot槽的数据分片机制，可以实现在线扩容提升写数据的性能
从集群架构上来说，Redis 哨兵集群是一主多从， 而Redis Cluster是多主多从
Redis 哨兵集群是单独启动哨兵服务对主从节点进行监控，所以原则上还是主从，只不过哨兵实现了主从自动故障转移，它可以实现读写分离，分担Redis读操作的压力。
而Redis Cluster 集群的Slave节点只是实现冷备机制，它只有在Master宕机之后才会工作。
从集群架构上来说，Redis 哨兵集群是一主多从， 而Redis Cluster是多主多从
哨兵集群是一主多从，所有的数据都会存储在我的主，而cluster集群数据会通过虚拟槽的分片机制分配到不同的主服务器，所以扛压这块，哨兵集群受限于单个服务器的资源配置，而cluster是多主联合扛压。
RedisCluster集群，采用虚拟槽的分片机制，能够灵活的在线进行扩容、缩容，以及灵活的进行数据隔离
Redis Sentinal 着眼于高可用，在 master 宕机时会自动将 slave 提升 为 master，继 续提供服务。 Redis Cluster 着眼于扩展性，在单个 redis 内存不足时，使用 Cluster 进行分片存储要部署 Redis 的哨兵模式和集群模式，需要按照以下步骤进行：
部署 Redis 哨兵模式：
安装和配置 Redis：在每个 Redis 节点上安装 Redis，并确保配置文件中的 sentinel 配置项启用（例如，sentinel.conf）。
配置哨兵节点：创建一个 sentinel.conf 文件，指定每个哨兵节点的配置信息，包括监控的 Redis 主节点和其他哨兵节点的地址。
启动哨兵进程：使用 redis-sentinel 命令启动每个哨兵节点的进程。哨兵会自动发现其他哨兵和 Redis 主节点，并监控它们的状态。
验证和测试：使用 redis-cli 连接到其中一个哨兵节点，通过命令查看各个节点的状态，确保哨兵正常工作。
部署 Redis 集群模式：
安装和配置 Redis：在每个 Redis 节点上安装 Redis，并确保配置文件中的 cluster-enabled 配置项启用。
创建集群：选择一个节点作为集群的首领（leader），使用 redis-cli 命令初始化集群，并添加其他节点到集群中。
验证和测试：使用 redis-cli 连接到任何一个节点，在集群中执行各种 Redis 命令来验证集群的正常工作。
需要注意的是，在部署 Redis 的哨兵模式和集群模式时，要仔细阅读官方文档，并根据实际情况进行适当的配置。此外，还要确保网络连接正常、节点之间可以相互通信，并且合理设置密码和访问控制等安全措施。

红锁Redlock

关于分布式锁，一般有三种选择，
1、redis
2、zk
3、DB锁（悲观锁、乐观锁）
其中用的最多的应该是redis。
redis常用的方式有单节点、主从模式、哨兵模式、集群模式。
单节点在生产环境基本上不会使用，因为不能达到高可用，且连RDB或AOF备份都只能放在master上，所以基本上不会使用。
另外几种模式都无法避免两个问题：
1、异步数据丢失。
2、脑裂问题。
所以redis官方针对这种情况提出了红锁（Redlock）的概念。
https://redis.io/topics/distlock/
Redlock：全名叫做 Redis Distributed Lock;即使用redis实现的分布式锁；
使用场景：多个服务间保证同一时刻同一时间段内同一用户只能有一个请求（防止关键业务出现并发攻击）；
官网文档地址如下：Distributed locks with Redis – Redis
这个锁的算法实现了多redis实例的情况，相对于单redis节点来说，优点在于 防止了 单节点故障造成整个服务停止运行的情况；并且在多节点中锁的设计，及多节点同时崩溃等各种意外情况有自己独特的设计方法；