redis主从、哨兵、集群的区别
通过持久化特性，Redis保证即使服务器重启也不会丢失数据（或少量丢失），因为持久化会将内存中的数据保存在硬盘上，重启时会从硬盘中加载数据。硬盘。
哨兵的作用是监控master和slave，并在master和slave之间进行切换。
可以一主多从，但数据冗余存储，每个主从节点存储的数据相同。
数据分段存储，每个节点存储一部分数据，达到分布式集群的目的。
redis中主从、哨兵和集群这三个有什么区别?
采访讨论了Redis架构相关的话题，包括主从架构、哨兵、集群等关键概念。接下来，我们将更直观地解释Redis架构的关键区别。
在Redis架构中，主从架构通过在服务器之间复制数据来提高可用性和性能。
主服务器继续将数据推送到从服务器以创建数据备份。
当主服务器出现故障时，从服务器可以立即升级为主服务器并接管服务。
复制过程使用PSYNC命令，包括完全重新同步和部分重新同步模式，以确保数据一致性。
为了实现更高级别的可用性，引入了 Sentinel 系统。
作为集群管理器，Sentinel 持续监控主服务器的状态，在检测到主服务器发生故障后，它会自动选择辅助服务器作为新的主服务器以进行自动故障转移。
Sentinel 系统通过 ping 监视主服务器，并按配置的时间间隔确认其状态，以确保高可用性。
分片集群通过将数据分布到多个Redis实例来实现分布式存储。
每个版本负责存储一部分数据，从而扩展系统的容量。
RedisCluster 使用客户端路由通过哈希槽将数据分发到不同的实例，而 Codis 等服务器端路由解决方案则通过代理层分发数据。
随着集群中实例的动态增加或减少，通过消息传播和映射关系更新来保证正确的数据路由。
数据迁移是动态扩展集群内实例时的一个重要过程。
当客户端请求数据时，如果目标实例没有相关数据，则返回重定向以引导客户端到正确的实例。
迁移过程包括实例之间的通信和增量数据传输，以保证迁移过程中数据的一致性和可用性。
通过这些架构设计，Redis可以提供高可用性、高扩展性和数据一致性，以满足不同场景的需求。
主从架构、节点和集群对于提高系统可靠性和性能发挥着重要作用。
玩转Redis的高可用（主从、哨兵、集群）
所谓高可用性，也称为HA（HighAvailability），是分布式系统架构设计要考虑的因素之一，是保证系统SLA的重要指标。
Redis高可用主要有三种模式：主从模式、哨兵模式、集群模式。
当Redis数据库中的数据发生变化时，Redis会自动将变化同步到其他Redis系统。
当Redis部署在多台机器上时，这些机器节点分为两类： 一个是主节点（masternode），一个是从节点（slavenode）。
通常，主节点可以执行读和写操作，而从节点只能执行读操作。
一个主节点可以有多个从节点，但一个从节点只能有一个主节点，也就是所谓的1主多从结构。
·支持主从复制。
主机自动向从机同步数据，并且读写分离。
·Master以非标准方式向主从提供服务。
- 阻止方法。
因此，在主从同步过程中，客户端仍然可以提交查询或修改请求。
·从机也以非阻塞的方式完成数据同步。
同步过程中，当客户端提交查询请求时，Redis会返回同步前的数据。
·Redis不具备自动容错和恢复功能。
某些前端读写请求可能会由于主机和从机系统的停机而失败。
如需恢复，请手动切换前端IP。
·主机系统宕机。
IP切换后，在出现数据不一致之前，部分数据无法同步到从系统。
被介绍。
系统可用性降低；
·Redis很难支持在线扩容，当集群容量达到上限时，在线扩容变得非常复杂。
·Redis主节点和从节点data 相同，但降低了内存可用性
实际生产中优先选择Sentinel模式。
在此模式下，如果主站宕机，Sentinel 会自动选择主站并指定另一个从站作为新的主站。
在主从模式下，redis还提供了哨兵命令redis-sentinel。
哨兵作为进程独立运行。
原理是Sentinel进程通过向所有Redis机器人发送命令并等待Redis服务器的响应来监视多个正在运行的Redis实例。
通常，使用奇数个哨兵来促进决策和选择。
多个哨兵组成哨兵集群。
哨兵之间直接沟通，以确保哨兵正常运行，而Master Fighter和哨兵则做出决定，选举新的Master。
Sentinel模式的作用：
·当你发送命令时，Redis服务器运行并监控执行状态，包括主服务器和从服务器。
·但是，即使 Sentinel 进程监控 Redis 服务器，这也可能会导致问题。
，可以使用多个Sentinel进行监控。
每个哨兵当它被监视时，就会形成各种哨兵模式。
Sentinel 与 kafka 集群中的 Zookeeper 功能非常相似。
·哨兵模式基于主从模式，哨兵模式具有主从模式的所有优点。
·自动主从切换，使系统更加健壮、高可用。
·主从模式的缺点是各个系统中的数据相同，内存可用性较低。
·Redis难以支持在线扩展。
当集群容量达到上限时，在线扩容变得非常复杂。
Redis集群模式本身并没有使用一致性哈希算法，而是使用了槽。
Redis哨兵模式基本上可以实现高可用和读写分离，但是这种模式下每个Redis服务器存储的数据都是一样的，比较浪费内存，所以redis3.0加入了集群。
集群模式实现了Redis和分片数据的分布式存储。
这意味着每个Redis节点存储不同的并通过集群总线与其他节点通信。
通信时使用特殊的端口号：外部服务端口号加10000。
例如，如果某个节点的端口号为6379，则用于与其他节点通信的端口号为16379。
节点之间的通信使用特殊的二进制协议。
对于客户端，显示的是整个集群。
客户端可以连接到任何节点进行操作，就像操作单个 Redis 实例一样。
客户端操作时，如果某个节点没有分配key，Redis会返回一个协调命令指向正确的节点。
。
这有点像浏览器页面上的 302 重定向。
根据官方建议，集群部署至少需要3个主节点，最好采用3主3从的6节点模型。
Redis中的每个节点都有两个，其中一个是槽，其值范围为0-16383。
您可以在上面的 redis-trib.rb 中阅读它。
执行结果显示了分布情况。
3 个主机上的 16383 个插槽之一。
另外一个是Cluster，可以理解为类似于Sentinel的集群管理插件。
当访问密钥到达时，Redis根据crc16算法计算结果，然后计算结果加16384的余数，因此每个密钥都对应数字0。
-16383 利用该值找到该槽对应的节点，然后自动直接跳转到该节点执行连接操作。
为了保证高可用性，redis-cluster集群引入了主从模式，一个主节点对应一个或多个从节点。
当另一个主节点 ping 主节点 master1 时，如果超时期间超过一半的主节点正在与 master1 通信，则认为 master1 宕机，master1 的从节点 slav1 变为活动状态，Slave1 成为主节点并继续。
我们提供服务。
如果master1及其从节点slav1都宕机了，那么整个集群就会处于失败状态，因为集群内的slot映射不完整。
集群高手之中如果超过一半死亡，集群就处于失败状态，无论是否有slave。
redis-cluster采用了去中心化的理念。
客户端直接连接到 Redis 节点，无需中间代理层。
您可以连接到集群中的任何节点 您可以连接到集群中的任何节点。
只有一个可用节点就足够了。
redis集群扩容意味着向集群中添加机器，缩容意味着从集群中删除机器，并将16383个槽位重新分配给集群中的节点（迁移数据）。
集群管理工具redis-tri.rb也用于扩缩容。
扩展时，首先使用 redis-tri.rbadd-node 将新机器添加到集群中。
新机器已经在集群中，但仍然无法工作，因为它还没有分配槽位。
的。
使用redis-tri.rbreshard进行分片重新哈希（数据迁移），只有将现有节点的slot分配给新节点后，新节点才会生效。
收缩时，首先使用redis-tri.rbreshard从机器上删除插槽，然后使用redis-tri.rbadd-del删除机器。
采用去中心化的理念，数据按照时隙存储并分发到多个节点，节点之间数据共享，数据分布可动态调整。
可扩展性：可扩展线性最多1000多个节点，可动态添加或删除节点；
高可用性：即使部分节点不可用，集群也能保持可用。
添加Slave作为备用数据副本，可以让节点之间通过Gossip协议和投票机制交换状态信息，完成从Slave到Master的角色提升。
降低运维成本，提高系统稳定性。
可用性。
1. RedisCluster是一个中心无节点集群架构，使用Goss协议（谣言传播）来协作自动恢复集群状态。
但GosSip存在的问题是，如果集群节点过多，节点之间的PING/PANG通信必须持续，不必要的流量占用大量网络资源。
Reds4.0已经对此进行了优化，但是这个问题仍然存在。
2. 数据迁移问题
RedisCluster可以动态伸缩节点，但在目前的实现中，这个过程仍然是半自动的，需要人工干预。
扩缩容时需要进行数据迁移。
为了保证迁移一致性，所有Redis迁移操作都是同步操作。
执行迁移时，Redis 会在两端进入不同长度的阻塞状态。
对于小高度来说，这个时间可以忽略不计。
。
但如果Key的内存占用过高，严重时会导致集群故障，导致不必要的迁移。
Master-Slave模式：主节点宕机后需要手动指定新的master，由于可用性较低，默认不使用。
Sentinel模式：当一个master节点宕机后，Sentinel进程会主动选择一个新的高可用的master，但每个节点上存储的数据是相同的，浪费了内存空间。
数据量不大，簇大小也不是很大。
事实并非如此。
当需要自动容错和灾难恢复时使用。
集群模式：数据量较大、QPS要求较高时使用。
RedisCluster在Redis 3.0之后正式发布，但能够证明其在大规模生产环境中成功的案例并不多。
redis 的一主二从三哨兵模式
一主二从三哨Redis模式是一种高可用的部署策略，旨在保证Redis宕机时能够继续提供服务。
通过配置一台主服务器和两台从服务器，并设置三个备份实例，当主服务器出现故障时，系统可以自动将从服务器提升为主服务器，保证服务的连续性。
配置方案如下：
主服务器IP地址：127.0.0.16001
两个从服务器IP地址：127.0.0.16002和127.0.0.16003< /p >
三台 Sentinel I 服务器 P 地址：127.0.0.116001， 127.0.0.116002, 127.0.0.116003
配置文件修改包括：
将`redis.conf`复制到`redis1.conf`和`redis 2.conf`修改`redis.conf`文件` 并配置如下：`bind192.168.1.88127.0.0.1`` protected-modeno``daemonizeyes``port6001``pi dfile"/var/run/redis_6001.pid"` 编辑文件`redis1.conf`和`redis2.conf`并配置它们如下：`bind192.168.1.88127.0 .0.1`prot ected-modeno``daemonizeyes``port6002` 或 `6003``pidfile "/var/run/redis_6002.pid" or "/var/run/redis_6003.pid" ``slaveof127.0.0.16001` 修改sentinel配置文件，包括`sentinel.conf`、`sentinel1.conf`和`sentinel2 .conf`，并配置以下：`port16001``d aemonizeyes``sentinelmonitormymaster127.0.0.160012`编辑sentinel配置文件，配置如下：`port16002`或`16003`sentinelmonitor mymaster127.0.0.160012`启动服务：
使用命令“. /bin/redis-server”启动“redis.conf”文件， “redis1.conf”和“redis2.conf”。。
使用`./bin/redis-sentinel`命令启动哨兵服务。
验证配置：
通过`./bin/redis-cli-p16001`命令连接到Sentinel并运行`sentinelmastermymaster`来验证主从状态。手动关闭主服务器，观察从服务器能否升级为主服务器。
测试发送和接收数据以确认从服务器之间的数据同步。
看门狗功能包括：
状态监控：监控主服务器的状态。
故障转移：当主服务器出现异常时，从服务器自动提升为新的主服务器。
配置修复：主从切换后，相关配置文件（如`redis.conf`、`redis1.conf`、`redis2.conf`、`sentinel.conf`）会自动更新。
学习资源：
RedisSentinel官方文档Redis哨兵机制原理及配置
