redis哨兵和集群区别是什么?

redis哨兵和集群的区别如下。

监控（Monitoring）：Sentinel会不断地检查你的主服务器和从服务器是否运作正常，提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。

集群即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储。

即每台redis存储不同的内容，共有16384个slot。每个redis分得一些slot，hash_slot = crc16(key) mod 16384找到对应slot，键是可用键，如果有｛}则取｛}内的作为可用键，否则整个键是可用键。

主从、哨兵、集群各自架构的优点和缺点对比

优点：·架构简单，部署方使。高性价比：缓存使用时无需备用节点（单实例可用性可以用supervisor或crontab保证），当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务，高性能。

缺点：·不保证数据的可靠性。在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。

高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合 *** 作命令简单，排序、计算较少的场景。也可以考虑用Memcached替代。

在哨兵模式中，仍然只有一个 master 节点。当并发写请求较大时，哨兵模式并不能缓解写压力。

在redis-cluster集群中，每一个主节点可以添加多个从节点，主节点和从节点遵循主从模式的特性。
当用户需要处理更多的读请求时，添加从节点可以扩展系统的读性能。

redis集群的主节点内置了类似Sentinel的节点故障检测和自动故障转移功能。当集群中的某个主节点下线时，集群中的其他在线主节点发现了以后，会对已下线的主节点进行故障转移。集群进行故障转移的方法和Sentient进行故障转移的方法基本一致，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以集群中不需要使用Sentinel。

redis-cluster集群将键存储空间分割为16384个槽位(slot)，事实上集群最大节点数量是16384个官方建议最大节点数量不超过1000个节点。
所有主节点都负责16384个哈希槽中的一部分，当16384个槽都有某个节点在负责处理时，集群进入上线状态，并开始处理客户端发送的数据命令请求。
一个slot槽位可以存放多个数据，key的槽位计算公式：HASH_SLOT = CRC16(key) mod 16384

由于Redis集群无中心节点，请求会随机发给任意主节点。
主节点只会处理自己负责槽位的命令请求，其他槽位的命令请求，该主节点会返回客户端一个转向错误。
客户端根据错误中包含的地址和端口重新向正确的负责的主节点发起命令请求。

系统：CentOS7
Redis: 509
Redis节点

注意：

配置文件主要修改：

执行结果

按照之前的配置修改并启动，使用以下命令将其加入集群：

添加完新节点后，需要对新添加的主节点进行hash槽重新分配，这样该主节点才能存储数据，redis共有16384个槽。

删除从节点19216816413:7000，node_id:cb21c351b3d2378976bf7d215553d0e04d7fad43

执行结果

存在slot的主节点无法直接删除，所以我们需要先移动主节点19216816413:7001的slot至其他三个主节点

查看集群节点信息

删除主节点

执行结果

查看集群信息

搭建Redis集群的过程中，执行到cluster create <ip>:<port> 的时候，发现程序在阻塞，显示：Waiting for the cluster to join 的字样，然后就无休无尽的等待

根据字样的提示，在等待集群的创建。嗯？这是什么原因？大部分情况下这是因为集群通信的端口没有开放！

先说下解决方案：
开放Redis服务的两个TCP端口。譬如Redis客户端连接端口为6379，而Redis服务在集群中还有一个叫集群总线端口，其端口为客户端连接端口加上10000，即 6379 + 10000 = 16379。所以开放每个集群节点的客户端端口和集群总线端口才能成功创建集群！

问题解决了，则反思一下，客户端端口和集群总线端口有什么区别呢？

总而言之，客户端端口提供的是外部客户端访问服务的端口；而集群总线端口是提供集群内部各个Redis服务之间的通信。

参考资料：

>