[TOC]
Redis 哨兵模式
描述: 哨兵模式是主从的升级版，因为主从的出现故障后，不会自动恢复，需要人为干预，这就很蛋疼啊。在主从的基础上，实现哨兵模式就是为了监控主从的运行状况，对主从的健壮进行监控，就好像哨兵一样，只要有异常就发出警告，对异常状况进行处理。
Sentinel 介绍
描述: Redis从2.8开始发布了一个稳定版本的 。当前版本的 Sentinel 称为Sentinel 2。它是使用更强大和更简单的预测算法来重写初始Sentinel实现。
Redis Sentinel 是一个分布式系统，Redis Sentinel为Redis提供高可用性。可以在没有人为干预的情况下 阻止某种类型的故障。
Redis Sentinel 是redis的高可用实现方案，在实际生产环境中，对提高整个系统可用性是非常有帮助的。
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
默认情况下，Sentinel 使用 TCP 端口 26379 运行（请注意，6379 是普通的 Redis 端口）。Sentinel 接受使用 Redis 协议的命令，因此您可以使用或任何其他未修改的 Redis 客户端来与 Sentinel 对话。并且可以直接查询 Sentinel 以从其角度检查受监控 Redis 实例的状态，查看它知道的其他 Sentinel，等等。
Sentinel 高可用性
描述: 当主节点出现故障时redis sentinel 能自动完成故障发现和故障转移，并通知客户端从而实现真正的高可用。
Redis Sentinel是一个分布式架构，其中包含N个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其他Sentinel节点进行监控， 当它返现节点不可达时，会对节点做下线标识，如果被标识的是主节点，它还会和其他Sentinel及诶单进行“协商”，当大多数节点都认为主 节点不可达时，会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给redis的客户端，整个过程是自动的不需要人工干预，有效的解决了redis的高可用问题。
Redis 主从和Redis Sentinel 区别
同时看出，Redis Sentinel包含多个Sentinel节点，这样做带来两个好处:
Sentinel的仲裁会 描述: 我们master被sentinel集群监控时，需要为它指定一个参数，该参数指定了当需要判决master为不可用，并且进行failover时，所需要的sentinel数量。
不过，当failover主备切换真正被触发后，failover并不会马上进行，还需要sentinel中的大多数sentinel授权后才可以进行failover。 当时，failover被触发后将尝试去进行failover的sentinel会去获得“大多数”sentinel的授权（如果票数比大多数还要大的时候，则询问更多的sentinel)
例如，当集群中有 5个sentinel 票数被设置为2，当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。
如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。
WeiyiGeek.简单图示
选举算法 Q: 当master被认为客观下线后，又是怎么进行故障恢复的呢?
原来哨兵中首先选举出一个老大哨兵来进行故障恢复，选举老大哨兵的算法叫做「Raft算法」：
选出大佬哨兵后，大佬哨兵就会对故障进行自动回复，从slave中选出一名slave作为主数据库，选举的规则如下所示：
Tips: 通过以上的层层筛选最终实现故障恢复，当选的slave晋升为master，其它的slave会向新的master复制数据，若是down掉的master重新上线，会被当作slave角色运行。
配置版本号 为什么要先获得大多数sentinel的认可时才能真正去执行failover呢？
保证了活跃性：如果大多数sentinel能够互相通信，最终将会有一个被授权去进行failover. 保证了安全性：每个试图去failover同一个master的sentinel都会得到一个独一无二的版本号。
当一个sentinel被授权后，它将会获得宕掉的master的一份最新配置版本号，当failover执行结束以后，这个版本号将会被用于最新的配置。因为大多数sentinel都已经知道该版本号已经被要执行failover的sentinel拿走了，所以其他的sentinel都不能再去使用这个版本号。这意味着每次failover都会附带有一个独一无二的版本号。我们将会看到这样做的重要性。
节点通信 描述: 当哨兵启动后会与master建立一条连接，用于订阅master的频道。
该频道用于获取监控该master的其它哨兵的信息,并且还会建立一条定时向master发送INFO命令获取master信息的连接。
「当哨兵与master建立连接后，定期会向（10秒一次）master和slave发送INFO命令，若是master被标记为主观下线，频率就会变为1秒一次。」
但是一个faiover要想被成功实行的前提，sentinel必须能够向选为master的slave发送命令，然后能够通过INFO命令看到新master的配置信息。
并且，定期发送自己的信息，以便其它的哨兵能够订阅获取自己的信息，发送的内容包含「哨兵的ip和端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本」等信息。
以及，「定期的向master、slave和其它哨兵发送PING命令（每秒一次），以便检测对象是否存活」，若是对方接收到了PING命令，无故障情况下，会回复PONG命令。
所以，哨兵通过建立这两条连接、。
例子说明，假设有一个名为mymaster的地址为192.168.56.11:6379。一开始，集群中所有的sentinel都知道这个地址，于是为mymaster的配置打上版本号1。一段时候后mymaster死了，有一个sentinel被授权用版本号2对其进行failover。如果failover成功了，假设地址改为了192.168.56.12:6279，此时配置的版本号为2，进行failover的sentinel会将新配置广播给其他的sentinel，由于其他sentinel维护的版本号为1，发现新配置的版本号为2时，版本号变大了，说明配置更新了，于是就会采用最新的版本号为2的配置。
重要的事情说明三遍:
Tips: 这里涉及到一些概念需要理解，INFO、PING、PONG等命令，后面还会有MEET、FAIL命令，以及主观下线，当然还会有客观下线，这里主要说一下这几个概念的理解：
上线和下线
Sentinel(哨兵) 与 master会定期一直保持联系，若是某一时刻哨兵发送的PING在指定时间内没有收到回复，那么发送PING命令的哨兵就会认为该master「主观下线」（Subjectively Down）。
当sentinel发送PING后，以下回复之一都被认为是合法的, 。
有时 哨兵 与 master 之间的网络问题造成收发中断，而不是master本身的原因，所以哨兵同时会询问其它的哨兵是否也认为该master下线，若是认为该节点下线的哨兵达到一定的数量（），就会认为该节点「客观下线」（Objectively Down）。
从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip协议：如果一个sentinel收到了足够多的sentinel发来消息告诉它某个master已经down掉了，SDOWN状态就会变成ODOWN状态。如果之后master可用了，这个状态就会相应地被清理掉。
正如之前已经解释过了，真正进行failover需要一个授权的过程，但是所有的failover都开始于一个ODOWN状态。
ODOWN状态只适用于master，对于不是master的redis节点sentinel之间不需要任何协商，slaves和sentinel不会有ODOWN状态。
若是，则该master客观下线的标识会被移除；回复了客观下线的标识也会被移除。
每个 Sentinel 都需要定期执行的任务
Sentinel之间和Slaves之间的自动发现机制 描述: 虽然sentinel集群中各个sentinel都互相连接彼此来检查对方的可用性以及互相发送消息。但是你不用在任何一个sentinel配置任何其它的sentinel的节点。
因为sentinel利用了master的发布/订阅机制()去自动发现其它也监控了统一master的sentinel节点。
同样，你也不需要在sentinel中配置某个master的所有slave的地址，sentinel会通过询问master来得到这些slave的地址的。
网络隔离时的一致性
描述: redis sentinel集群的配置的一致性模型为最终一致性，集群中每个sentinel最终都会采用最高版本的配置。然而，在实际的应用环境中，有三个不同的角色会与sentinel打交道:
为了考察整个系统的行为我们必须同时考虑到这三个角色。
下面有个简单的例子，有三个主机，每个主机分别运行一个redis和一个sentinel:
在这个系统中，初始状态下redis3是master, redis1和redis2是slave。之后redis3所在的主机网络不可用了，sentinel1和sentinel2启动了failover并把redis1选举为master。
Sentinel集群的特性保证了sentinel1和sentinel2得到了关于master的最新配置。但是sentinel3依然持着的是就的配置，因为它与外界隔离了。
当网络恢复以后，我们知道sentinel3将会更新它的配置。但是，如果客户端所连接的master被网络隔离，会发生什么呢？
客户端将依然可以向redis3写数据，但是当网络恢复后，redis3就会变成redis的一个slave，那么，在网络隔离期间，客户端向redis3写的数据将会丢失。
也许你不会希望这个场景发生：
如果你把redis当做缓存来使用，那么你也许能容忍这部分数据的丢失。 但如果你把redis当做一个存储系统来使用，你也许就无法容忍这部分数据的丢失了。 因为redis采用的是异步复制，在这样的场景下，没有办法避免数据的丢失。然而,你可以通过以下配置来配置redis3和redis1，使得数据不会丢失。
通过上面的配置，当一个redis是master时，如果它不能向至少一个slave写数据(上面的min-slaves-to-write指定了slave的数量)，它将会拒绝接受客户端的写请求。由于复制是异步的，master无法向slave写数据意味着slave要么断开连接了，要么不在指定时间内向master发送同步数据的请求了(上面的min-slaves-max-lag指定了这个时间)。
故障转移步骤
一次故障转移操作由以下步骤组成：
Sentinel 使用以下规则来选择新的主服务器：
Sentinel状态持久化
snetinel的状态会被持久化地写入sentinel的配置文件中。每次当收到一个新的配置时，或者新创建一个配置时，配置会被持久化到硬盘中，并带上配置的版本戳。这意味着，可以安全的停止和重启sentinel进程。
优点 哨兵模式是主从模式的升级版，所以在系统层面提高了系统的可用性和性能、稳定性。当master宕机的时候，能够自动进行故障恢复，需不要人为的干预。
哨兵与哨兵之间、哨兵与master之间能够进行及时的监控，心跳检测，及时发现系统的问题，这都是弥补了主从的缺点。
缺点 哨兵一主多从的模式同样也会遇到写的瓶颈，已经存储瓶颈，若是master宕机了，故障恢复的时间比较长，写的业务就会受到影响。
增加了哨兵也增加了系统的复杂度，需要同时维护哨兵模式。
Sentinel 配置步骤
描述: 哨兵模式的监控配置信息，是通过配置从数据库的来指定的，比如：
运行哨兵的两种方式:
Tips: 在运行 Sentinel 时必须使用配置文件，因为系统将使用该文件来保存在重启时将重新加载的当前状态。如果没有给出配置文件或配置文件路径不可写，Sentinel 将简单地拒绝启动。
Tips: Sentinel 默认运行侦听 TCP 端口 26379 的连接，因此要使Sentinel 工作，您的服务器的端口 26379必须打开以接收来自其他 Sentinel 实例的 IP 地址的连接。否则哨兵不能说话，也不能就该做什么达成一致，所以永远不会执行故障转移。
官方参考:
测试环境
Tips: 此处演示只用了一台主机进行演示，在生产环境中搭建sentinel一定要在各redis服务器上配置监听，这才能真正的实现高可用。
流程步骤 描述: 哨兵模式的搭建配置比较简单，在前面一章配置的主从模式的基础上，同时创建一个文件夹用于存放三个哨兵的配置文件：
Step 0.Redis主从服务配置文件并启动配置Redis主从服务。
Step 1.Redis 哨兵Sentinel常用配置简单说明。
Step 2.sentinel 配置文件配置分别生成26379、36379、46379的监听端口,以及分别启动三个端口的哨兵服务。
Step 3.验证Redis Sentine服务并通过查看哨兵相关信息
Step 4.在Master节点上添加一个Keys验证主从正常同步
Step 6.从上面流程验证了redis主从同步以及哨兵服务正常运行，下面我们将进行演示哨兵模式故障转移()。
Step 6.向 Sentinel 询问 master 的状态，在开始使用 Sentinel 最明显的事情是检查它正在监视的 master 是否运行良好
WeiyiGeek.验证
Step 7.然后我们再来测试一下哨兵的自动故障恢复，直接kill掉6380服务端口的进程。
Sentinel 配置文件
描述：在redis源码包中自带一个配置文件示例。
Sentinel 常用命令
描述: Sentinel 常用API命令(
常用命令
(1) 出于连接管理和管理目的，Sentinel 支持以下 Redis 命令子集：
(2) SENTINEL命令是 Sentinel 的主要 API
(3) 动态获取修改Sentinel配置
Tips 可以操作的全局参数包括：
(4) 移除master监控服务或者删除旧的 master 或无法访问的副本
(5) 添加或删除哨兵 描述: 由于 Sentinel 实现了自动发现机制，因此将新 Sentinel 添加到您的部署中是一个简单的过程。您需要做的就是启动配置为监视当前活动主站的新 Sentinel。在 10 秒内，Sentinel 将获取其他 Sentinel 的列表以及附加到 master 的副本集。在该过程结束时，可以使用该命令 来检查所有 Sentinel 是否同意监视 master 的 Sentinel 总数。
移除 Sentinel 有点复杂：Sentinels 永远不会忘记已经看到的 Sentinels，即使它们很长时间无法访问，因为我们不想动态更改授权故障转移和创建新配置所需的多数数字。因此为了删除 Sentinel，应在没有网络分区的情况下执行以下步骤：
发布/订阅消息 描述: 客户端可以使用 Sentinel 作为与 Redis 兼容的发布/订阅服务器（但您不能使用PUBLISH），以便订阅或PSUBSCRIBE到频道并获得有关特定事件的通知。
以下是您可以使用此 API 接收的频道和消息格式的列表。第一个字是通道/事件名称，其余的是数据的格式。 注意：指定实例详细信息的地方意味着提供以下参数来标识目标实例：
标识 master 的部分（从 @ 参数到结尾）是可选的，并且仅在实例本身不是 master 时才指定。
Tips ：-BUSY 状态的处理，当 Lua 脚本运行的时间超过配置的 Lua 脚本时间限制时，Redis 实例会返回 -BUSY 错误。在触发故障转移之前发生这种情况时，Redis Sentinel 将尝试发送SCRIPT KILL 命令，只有在脚本为只读时才会成功。如果在此尝试后实例仍处于错误状态，则最终将进行故障转移。
命令使用演示:
WeiyiGeek.sentinel相关命令实践
Redis Cluster 模式
描述: 在大型项目中Redis Cluster 集群模式被广泛应用，哨兵解决和主从不能自动故障恢复的问题，但是同时也存在难以扩容以及单机存储、读写能力受限的问题，并且集群之前都是一台redis的全量的数据，导致所有的redis都冗余一份，就会大大消耗内存空间,所以此时我们需要引入Redis 集群模式。
1.基础介绍
描述: 什么是Redis集群？
Redis集群是一个多Redis实例的集合，用于通过对数据库分区来扩展数据库，使其更具有弹性。集群中的每个成员，无论是主副本还是次级副本，都管理哈希槽的一个子集。如果一个主服务器出现不能访问的故障，那么它的从属服务器会提升为主服务器。在由三个主节点组成的最小的Redis集群中，每个主节点都有一个从属节点（为了至少能保证最低程度的故障转移），每个主节点分配一个范围在0至16383之间的哈希槽。节点A包含哈希槽范围为从0到5000，节点B为5001到10000，节点C从10001到18383。集群内部的通信则通过内部总线进行，使用gossip协议来传播关于集群的信息或者发现新节点。
Redis 集群采用了P2P的模式完全去中心化(分布式存储), 实现数据的分片把所有的 Key 分成了 16384 个 slot，每个 Redis 实例负责其中一部分slot, 并根据算法每个redis节点存储不同的内容; 集群中的所有信息（节点、端口、slot等），都通过节点之间定期的数据交换而更新，同时解决了在线的节点收缩（下线）和扩容（上线）问题。
例如：Redis 客户端可以在任意一个 Redis 实例发出请求（读、写），如果所需数据不在该实例中，通过重定向命令引导客户端访问所需的实例。
cluster 特性(已测试):
优点 1) 集群模式是一个无中心的架构模式，将数据进行分片，分布到对应的槽中，每个节点存储不同的数据内容，通过路由能够找到对应的节点负责存储的槽，能够实现高效率的查询。 2) 并且集群模式增加了横向和纵向的扩展能力，实现节点加入和收缩，集群模式是哨兵的升级版，哨兵的优点集群都有。
缺点 1) cluster环境下slave默认不接受任何读写操作，在slave执行readonly命令后可只能执行读操作 2) client端不支持多key操作(mget,mset等)，但当keys集合对应的slot相同时支持mget操作见:hash_tag 3) 不支持多数据库，只有一个(无多个db) 4) JedisCluster 没有针对byte[]的API，需要自己扩展(附件是我加的基于byte[]的BinaryJedisCluster-api) 1) 缓存的最大问题就是带来数据一致性问题，在平衡数据一致性的问题时，兼顾性能与业务要求，大多数都是以最终一致性的方案进行解决，而不是强一致性。 2) 并且集群模式带来节点数量的剧增，一个集群模式最少要6台机，因为要满足半数原则的选举方式，所以也带来了架构的复杂性。
Tips: 集群模式真正意义上实现了系统的高可用和高性能，但是集群同时进一步使系统变得越来越复杂，接下来我们来详细的了解集群的运作原理。
Q:什么是redis-cluster选举容错?
(1)选举过程是集群中所有master参与, 如果半数以上master节点与故障节点通信超过(cluster-node-timeout)时间, 则认为该节点故障，自动触发故障转移操作.
(2) 什么时候整个集群不可用(cluster_state:fail)?
2.集群架构
描述: redis-cluter 架构细节浅析
WeiyiGeek.架构图
3.原理分析
3.1 数据分区原理 描述: 集群的原理图还是很好理解的，在Redis集群中采用的是虚拟槽分区算法，会把redis集群分成 16384 个槽（0-16383）。
比如：下图所示三个master会把范围的槽可能分成三部分（0-5000）、（5001-11000）、（11001-16383）分别数据三个缓存节点的槽范围。
当客户端请求过来，会首先通过对key进行CRC16 校验并对 16384 取模（CRC16(key)%16383）计算出key所在的槽，然后再到对应的槽上进行取数据或者存数据，这样就实现了数据的访问更新。
WeiyiGeek.数据分区原理
Tips: 进行分槽存储是将一整堆的数据进行分片，防止单台的redis数据量过大，影响性能的问题。
3.2 节点通信 描述: 节点之间实现了将数据进行分片存储，那么节点之间又是怎么通信的呢？
这个和前面哨兵模式讲的命令基本一样, 首先新上线的节点, 会通过 Gossip 协议向老成员发送Meet消息，表示自己是新加入的成员。
老成员收到Meet消息后，在没有故障的情况下会恢复PONG消息，表示欢迎新结点的加入，除了第一次发送Meet消息后，之后都会发送定期PING消息，实现节点之间的通信。
Redis集群节点间的通信机制有如下两种方式
集中式方式
gossip 方式
gossip协议包含多种消息，包括ping，pong，meet，fail等等，流程示例：
通信的过程中会为每一个通信的节点开通一条tcp通道，之后就是定时任务，不断的向其它节点发送PING消息，这样做的目的就是为了了解节点之间的元数据存储情况，以及健康状况，以便即使发现问题。
但如果节点通信网络抖动问题,网络通信中有时会因为一些客观原因使得网络突然中断或者波动而变得不可访问。
此时 Redis Cluster 提供了一种选项 cluster-node-timeout，表示当某个节点持续timeout的时间失联时，才可以认定该节点出现故障，需要进行主从切换。当没有此参数时候，网络抖动会导致主从频繁切换 【数据的重新复制】。
Tips: 每个节点都有一个专门用于节点间gossip通信的端口，默认得为自己提供服务的端口号+10000，即6379为redis服务端点则节点间通信的就是18000端口。
3.3 数据请求 上面说到了槽信息，在Redis的底层维护了一个数组存放每个节点的槽信息。
因为他是一个二进制数组，只有存储0和1值，如下所示：
这样数组只表示自己是否存储对应的槽数据，若是1表示存在该数据，0表示不存在该数据，这样查询的效率就会非常的高，类似于布隆过滤器(二进制存储)。
比如：集群节点1负责存储0-5000的槽数据，但是此时只有0、1、2存储有数据，其它的槽还没有存数据，所以0、1、2对应的值为1。
并且，每个redis底层还维护了一个clusterNode数组，大小也是16384，用于储存负责对应槽的节点的ip、端口等信息，这样每一个节点就维护了其它节点的元数据信息，便于及时的找到对应的节点。
当新结点加入或者节点收缩，通过PING命令通信，及时的更新自己clusterNode数组中的元数据信息，这样有请求过来也就能及时的找到对应的节点。
WeiyiGeek.clusterNode数组中的元数据信息
有两种其它的情况就是：
1) 若是请求过来发现，数据发生了迁移，比如新节点加入，会使旧的缓存节点数据迁移到新结点。
2) 请求过来发现旧节点已经发生了数据迁移并且数据被迁移到新结点，由于每个节点都有clusterNode信息，通过该信息的ip和端口。此时旧节点就会向客户端发一个MOVED 的重定向请求，表示数据已经迁移到新结点上，你要访问这个新结点的ip和端口就能拿到数据，这样就能重新获取到数据。
倘若正在发正数据迁移呢？
答: 旧节点就会向客户端发送一个ASK 重定向请求，并返回给客户端迁移的目标节点的ip和端口，这样也能获取到数据。
3.4扩容和收缩
描述: 扩容和收缩也就是节点的上线和下线，可能节点发生故障了，故障自动回复的过程（节点收缩）。
节点的收缩和扩容时，会重新计算每一个节点负责的槽范围，并发根据虚拟槽算法，将对应的数据更新到对应的节点。
还有前面的讲的新加入的节点会首先发送Meet消息，详细可以查看前面讲的内容，基本一样的模式。
以及发生故障后，哨兵老大节点的选举，master节点的重新选举，slave怎样晋升为master节点，可以查看前面哨兵模式选举过程。
Tips: 新节点加入集群时都是master节点,并且也是无法写数据的（没有slot槽位），需要从新分配槽位后才可以访问。
3.5高可用主从切换原理 描述: 集群中当发现自己的 master(主节点)变为 FAIL 状态时，便尝试进行 Failover 指向其它正常 master 节点。
有时由于挂掉的 master 可能会有多个slave 节点，从而存在多个 slave 节点 竞争成为 master节点 的过程，其过程如下：
1.slave 发现自己的 master 变为
2.将自己记录的集群 进行 +1，并广播 信息.
3.其他节点收到该信息只有 master 响应判断请求者的合法性， 并发送 ，对每一个 epoch 只发送一次 ack
4.尝试 failover 的 slave 收集 .
5.超过半数后变成新Master.
6.广播 Pong 通知其他集群节点。
所以 Redis Cluster 既能够实现主从的角色分配，又能够实现主从切换，相当于 的功能。
3.6 跳转重定位节点与卡槽 当客户端向一个错误的节点发出了指令，该节点会发现指令的key所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。
客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有key将使用新的槽位映射表。
4.集群搭建
描述: Redis集群中要求奇数节点,至少要有三个节点，并且每个节点至少有一备份节点，所以至少需要6个redis服务实例。
4.1 安装环境
4.2 安装流程 Step 1.分别在三台服务器安装编译配置redis安装与上面一致(注意更新依赖)。
Step 2.准备目录结构和redis配置。
Step 3.将配置文件分别复制到其他目录并修改端口号。
Step 4.编写开启与关闭集群脚本 cluster-control.sh，并启动集群
Step 5.Redis 官方提供了 redis-trib.rb 工具()，我们可以进行手动进行创建Redis集群。
Step 6.验证Redis集群是否正常工作
5.集群命令
5.1 命令行式
语法格式:
Tips: 对于check、fix、reshard、del node、set timeout，您可以指定群集中任何工作节点的主机和端口。
实践使用:
Tips : 通过从其它集群导入数据到当前集群中的流程说明。
5.2 交互式命令
描述: 在我们以集群模式连接到集群中的任意一台主机时，可以通过交互魔术执行如下命令。
语法格式:
使用实践:
常用命令示例:
6.集群补充
(1) Redis集群和哨兵的区别 1、哨兵只提供一个主节点，同步时也是全量同步。集群的数据是分片放的，分片意味着数据是不重叠的。 2、哨兵架构可以写主读从，但是集群架构读写都走主节点。 3、哨兵架构收到单机数据量制约【一般不超过10个G】，集群架构可以很方便的进行水平扩展【当然操作起来还需要分配slots槽等等是有些麻烦】。 4、哨兵架构中的哨兵角色只是起到监控的作用，但不对外提供服务，相当于占用了资源。集群的话每一台主机都是主/或从，就不会有哨兵角色的这种主机资源“浪费”。
(2) Redis集群脑裂产生的问题 描述: 一个小集群内部主从因网络问题无法进行同步数据导致了重新选举()而后网络恢复导致该小集群出现2个主节点对外提供服务。
规避方式: 在redis.conf配置文件下更改参数配置，该配置意思是主节点写数据完成后，最少需要同步的slave数量。
举例说明: 比如1主2从的机制，原来的主节点因为网络波动被判定为挂了，此时新的从节点想上位，那么它必须要能给另外1个从节点进行redis写的同步，它才能成为主节点。此时对于这个从节点除了自己以外他还有一个从节点对其进行数据同步，那么1+1>2/3符合半数选举机制。
Tips: 非常注意该配置在一定程度上会影响集群的可用性，比如slave要是少于1个，那么没有从节点写入数据，就满足不了这个配置，那就不能对外提供服务了。
(3) Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？
描述: 因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中 一个挂了，是达不到选举新master的条件的。
示例: 3个master，挂了1个，则挂了的master其对应的slave若是获得了另外两个master的支持【2>3/2】，则它就可以成为master。
反例: 2个master，挂了1个，那么就算另外一个master选出一个slave作为新的master，此时票数也不够【1=2/2】，达不到半数效果。
反例: 4个master，如果挂了1个，选举方式和3个master的方式类似，可以达到半数选举的效果。但如果挂了2个，场景和上面的类似，也一样无法选出新的master。
总结: 为什么至少需要3个master节点,因为主从切换需要满足半数选举机制。 总结: 为什么推荐节点数为奇数，因为需要从节省机器资源角度出发考虑的。
(4) 集群是否完整才能对外提供服务？ 描述: 不一定 redis.conf 可以配置参数,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。
(5) 为啥redis.cond文件内部要写集群信息？ 描述: 因为当关闭所有机器的时候，再次重启可以通过配置文件来恢复集群信息。 PS：集群重启不要用创建集群的命令，直接启动单台机器即可
(6) 集群内部主从为啥不放在一台机器上？ 描述: 为了更安全，如果放在一台机器上，一个小集群挂了就整个集群全部挂掉。
到此这篇redis端口号及其占用的主要资源是什么（redis端口号及其占用的主要资源是什么意思）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-yjs/43486.html