Linux 关于redis cluster 和普通redis哨兵模式

支撑n个redis master node,每个master node 都可以挂载多个slave node

读写分离的架构,对于每个master来说,写就写到master,然后读就从mater对应的slave去读

高可用,因为每个master都有slave节点,那么如果master挂掉了,redis cluster这套机制,就会将某个slave切换成master

redis cluster(多master +读写分离+高可用)

我们只要基于redis cluster 去搭建redis集群即可,不需要手工搭建replication复制+主从架构+读写分离+哨兵集群+高可用.

redis cluster vs replication +sentinal

如果你的数据量很少,主要是承载高并发高性能的场景,比如你的缓存一般就几个G,单机就足够了,

replication,一个master ,多个slave,要几个slave跟你的要求的读吞吐量有关系,然后自己搭建一个sentinal集群,去保证redis主从架构的高可用行,就可以.

redis cluster ,主要针对的是海量数据+高并发+高可用的场景,海量数据,如果你的数据量很大,那么建议就用redis cluster

二：Sentinel集群会对Redis的主从架构中的Redis实例进行监控，一旦发现了master节点宕机了，就会选举出一个Sentinel节点来执行故障转移，从原来的slave节点中选举出一个，将其提升为master节点，然后让其他的节点去复制新选举出来的master节点。

你可能会觉得这样没有问题啊，甚至能够满足我们生产环境的使用需求了，那我们为什么还需要Redis Cluster呢？

首先Redis Sentinel说白了也是基于主从复制，在主从复制中slave的数据是完全来自于master。

假设master节点的内存只有4G，那slave节点所能存储的数据上限也只能是4G。主从复制架构中是读写分离的，我们可以通过增加slave节点来扩展主从的读并发能力，但是写能力和存储能力是无法进行扩展的，就只能是master节点能够承载的上限。

所以，当你只需要存储4G的数据时候的，基于主从复制和基于Sentinel的高可用架构是完全够用的。

但是如果当你面临的是海量的数据的时候呢？16G、64G、256G甚至1T呢？现在互联网的业务里面，如果你的体量足够大，我觉得是肯定会面临缓存海量缓存数据的场景的。

这就是为什么我们需要引入Redis Cluster

一致性哈希则是对2^32取模，也就是值的范围在[0, 2^32 -1]。一致性哈希将其范围抽象成了一个圆环，使用CRC16算法计算出来的哈希值会落到圆环上的某个地方。 
一致性哈希能够在我们后续需要新增节点或者删除节点的时候，不影响其他节点的正常运行

这就是Redis Cluster各个节点之间交换数据、通信所采用的一种协议，叫做gossip。

总的来说，Redis Cluster相当于是把Redis的主从架构和Sentinel集成到了一起，从Redis Cluster的高可用机制、判断故障转移以及执行故障转移的过程，都和主从、Sentinel相关，主从是Redis高可用架构的基石。

详情可见https://blog.csdn.net/weixin_42667608/article/details/111360617