Redis-Cluster集群
在守卫模式下，仍然只有一个主节点。
当并发写请求较大时，哨兵模式无法缓解写压力。
在redis-cluster集群中，每个master节点可以添加多个slave节点。
主节点和从节点遵循主从模式的特点。
当用户需要处理多个读请求时，添加从节点可以扩展系统的读性能。
redis集群的master节点内置了类似于Sentinel的节点故障检测和自动故障转移功能。
当集群中的某个主节点离线时，集群中其他在线的主节点发现该离线主节点后，会对该主节点进行故障转移。
集群故障转移方法与感知故障转移方法基本相同。
不同的是，在集群中，故障转移是由集群中其他在线的主节点来执行的，因此集群中不需要使用Sentinel。
redis-cluster集群将密钥存储空间划分为16384个槽位，实际上集群的最大节点数为16384【官方建议最大节点数不超过1000个节点】。
所有主节点负责16384个哈希轨道的一部分。
当16384个哈希轨道中的某个节点负责处理时，集群进入在线状态，开始处理客户端发送的数据命令请求。
一个轨道可以存储多个数据。
键槽计算公式为：HASH_SLOT=CRC16(key)mod16384
由于Redis集群没有中心节点，因此请求会随机发送到任意主节点。
主节点只会处理其负责的槽的命令请求，对于来自其他槽的命令请求，主节点将向客户端返回重定向错误。
客户端根据错误中的地址和端口向正确的负责主节点重新发起命令请求。
系统：CentOS7Redis:5.0.9Redis-node
注意：
主要配置文件修改：
运行结果
按照之前的配置更改并启动，并使用以下命令将其添加到集群中：
添加新节点后，新添加的主节点的哈希跟踪必须重新分布，这样 主节点可以存储数据，redis共有16384个磁道。
删除从节点192.168.164.13:7000，node_id:cb21c351b3d2378976bf7d215553d0e04d7fad43
运行结果
trace的主要部分存在节点，无法直接删除，所以我们必须首先将跟踪移动到主节点 192.168.164.13:7001 到另外三个主节点
查看集群节点信息
删除主节点
运行结果
查看集群信息
SpringCloud微服务详解： Redis 高可用集群
对于一般的小型项目，单实例的Redis缓存就可以满足需求，比如： B. 数百人访问的项目或日访问量数千的项目。但随着项目访问量的增加，单实例已经无法满足性能和稳定性的要求。
这时候可以考虑使用主从、哨兵或者Redis cluster集群等更高级的解决方案。
Redis集群集群具有无中心的结构。
其特点包括： 生产环境中的Redis集群需要至少一个备份节点来保证高可用性。
集群包含6个主从节点，每个节点分配一个特定的哈希槽范围：M1-S1负责哈希槽0-5500，M2-S2负责哈希槽5501-11000，M3-S3负责哈希槽11001 – 哈希槽号16384。
如果M1失败，集群选择S1作为新节点 并且集群继续运行。
如果M1和S1都故障，则集群不可用。
建议使用六台独立的服务器来部署集群。
首先，下载最新版本并更新基础组件，以避免编译和安装错误。
然后编译安装，创建集群配置文件夹，并在其中创建六个配置文件（7001.conf至7006.conf），根据集群需求修改配置。
启动服务，创建集群，最后检查集群信息，确认配置的正确性。
在微服务架构中，Redis 集群被集成为开发过程的一部分。
在pom.xml文件中包含相关依赖，并在bootstrap.yml配置文件中设置集群连接参数。
开发者可以将RedisTemplate封装为RedisUtil来简化操作。
部署到生产环境时，需要考虑以下几点： - 配置内网地址并启用防火墙以保证安全。
- 建立认证访问机制，防止未经授权的访问。
——建立监测预警体系，及时发现并纠正扩容、抢修等问题。
总之，微服务版的Redis高可用集群通过集群部署来提升性能和稳定性，但生产环境的部署需要关注安全、权限管理、监控报警等。
正确的配置和管理可确保集群高效、安全地运行。
为什么redis集群有16384个槽?
面试官：为什么Redis Cluster选择16384个哈希磁道？ 候选人：决定拥有 16384 个哈希轨道是基于两个主要考虑：防止由于较大的网络数据包而导致网络带宽使用过多，以及应对通常不超过 1000 个 Redis 实例的集群大小。太多的哈希轨道意味着网络数据包会更大并且可能“过度使用”网络带宽。
同时，Redis的设计者认为实际应用中的集群规模通常不会超过1000个实例，因此选择了16384个数量，这样既可以合理地将数据分布到集群中的各个实例中，又可以避免过多的实例数量。
交换数据时的带宽消耗。
面试官：我们来谈谈Redis分片集群的原理。
候选人：分片集群是Redis3.x版本中引入的官方集群解决方案。
它通过将数据分散到多个Redis实例来实现“水平扩展”，从而克服单实例存储的瓶颈。
每个实例负责一部分数据，不仅可以实现读写分离，还可以通过增加实例数量来扩展集群的容量。
面试官：RedisCluster的路由机制是怎样的？ Candidate：RedisCluster中的路由机制是在客户端实现的。
客户端会缓存每个实例负责的哈希轨迹列表，以便根据哈希轨迹将数据分发到正确的Redis实例。
当客户端发送请求时，会计算key的哈希值，然后根据这个值找到对应的哈希槽，进而找到正确的实例。
面试官：如果集群中的Redis实例发生变更（添加或删除），客户端如何处理？ Candidate：当集群中的Redis实例发生变化时，信息通过集群中的通信机制进行传播。
客户端缓存的哈希轨道和实例之间的映射关系可以动态调整，以确保请求正确路由到当前集群状态。
当客户端发出请求时，如果检测到数据尚未迁移到目标实例，则会收到“moved”命令，表明客户端应向新实例发起请求。
面试官：为什么Redis使用哈希轨道来进行数据分布而不是一致性哈希算法？ 候选：Redis使用哈希跟踪，使得每个实例都可以接收哈希跟踪信息，从而可以快速定位数据所属的实例。
虽然一致性哈希算法可以减少数据迁移的影响，但当集群大小发生变化时，需要确定受影响的数据区域并进行迁移。
相比之下，哈希追踪方法更简单、更高效、更灵活。
面试官：那么在RedisCluster中，服务器端路由指的是什么？ 候选：服务器端路由通常是指通过代理层（如Codis）接收客户端请求，并将请求转发到Redis集群中的特定实例进行处理。
Codis通过初始化的哈希踪迹将数据分发到不同的Redis实例，代理层负责缓存哈希踪迹和实例之间的最新映射关系，以保证请求能够正确路由。
面试官：在Codis中扩展Redis实例的流程是怎样的？ 候选：在Codis中，扩容Redis实例的过程通常包括：向集群中添加一个新的实例，然后将一些数据迁移到新的实例中。
具体过程涉及实例之间的数据迁移，包括发送数据、接收确认、删除发送数据等步骤。
确保数据迁移完成后数据的一致性。
面试官：明白了。
您推荐奥斯汀的哪些开源项目？ 候选人：奥斯汀是消息推送的开源项目。
结合真实的互联网项目进行设计和实现，支持多种消息类型和全链路跟踪。
该项目集成了SpringBoot、MySQL、Docker等多个中间件，目的是统一消息处理，提高业务需求的开发效率。
面试官：明白了。
感谢分享，这非常有帮助。
摘要：本文介绍了Redis集群中设置哈希轨道的原因、分片集群的原理、RedisCluster和Codis的路由机制以及服务器端数据迁移和路由的实现。
还推荐了一个用于消息推送的开源项目austin，旨在统一消息处理，提高效率。
