4.Redis Cluster 集群模式
如果单机吞吐量过大，我们可以横向和纵向进行扩展，横向就是加节点（scale out），纵向就是加配置（scale up）。
如果加配置，治标不治本，单机局限性和持久化问题无法解决（如轮式RDB快照还是AOF指令）
横向扩展更容易扩展，可以解决很多问题，包括单一实例节点的硬件扩容限制、成本限制，还可以分摊压力，精细化治理，精细化维护
集群的组成:
CLUSTER MEET <ip> <port>
数据自动分片：
cluster create 创建，会将 16384 个slots 平均分配在我们的集群实例上
通过 addslots 命令指定哈希槽范围
cluster addslots 0,7120redis-cli -h 192.168.0.2 –p 6379
通过一致性哈希算法把数据分到2^14个哈希槽中，每个节点负责一部分的槽位数据（自定义分配），节点之间通过goosip协议进行通信，更新信息，故障转移和故障检测。
如果请求所在的节点不是负责该槽位的节点，那么请求会被转发到负责该槽位的节点上。如果请求的键名所在的槽位没有被分配到任何节点上，那么Redis Cluster会返回一个错误信息
集群处于online状态说明数据对应的槽位都有节点进行管理，如果状态为offline说明有数据对应的槽位没有被任何节点管理。
数据复制过程和故障转移
数据复制 :
主从模式，master宕机会把从节点拿过来作为主节点。
故障检测
Redis的节点之间通过Gossip协议广播信息，每个节点定期的去ping--->主观下线和客观下线。对应前面讲的哨兵模式。
主从故障转移
基于raft的选举模式：
-
- 集群中设立一个自增计数器，初始值为 0 ，每次执行故障转移选举，计数就会+1。
- 检测到主节点下线的从节点向集群所有master广播一条CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST消息，所有收到消息、并具备投票权的主节点都向这个从节点投票。
- 如果收到消息、并具备投票权的主节点未投票给其他从节点（只能投一票哦，所以投过了不行），则返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示支持。
- 参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，如果收集到的选票 大于等于 (n/2) + 1 支持，n代表所有具备选举权的master，那么这个从节点就被选举为新主节点。
- 如果这一轮从节点都没能争取到足够多的票数，则发起再一轮选举（自增计数器+1），直至选出新的master。
-
新的主节点会撤销所有对已下线主节点的slots指派，并将这些slots全部指派给自己。
-
新的主节点向集群广播一条PONG消息，这条PONG消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
-
新的主节点开始接收和自己负责处理的槽有关的命令请求，故障转移完成。
client 访问 数据集群的过程
Redis每个实例节点会通过Gossip协议把哈希槽的分配信息进行扩散。相当于每个集群都有一个集群哈希槽对应哪个实例的注册表。
客户端连接任一实例，获取到slots与实例节点的映射关系，并将该映射关系的信息缓存在本地。
将需要访问的redis信息的key，经过CRC16计算后，再对16384 取模得到对应的 Slot 索引。
通过slot的位置进一步定位到具体所在的实例，再将请求发送到对应的实例上。
Redis集群和主从复制+哨兵机制这种模式有什么区别？
Redis集群通过把Redis数据进行分片存储在多个Redis节点来实现横向扩展和高可用性，适合大规模的Redis部署。
如果是小规模，用主从复制+哨兵模式就可以。
另外注意纯主从+哨兵的模式用的是读写分离，而redis集群技术的从节点就是一个主的备用，合理的来说应该是主备模式。
标签：乔亚,Redis,----,故障,实例,集群,哈希,节点 From： https://www.cnblogs.com/dwj-ngu/p/17277248.html