背景
集群的解决方案有三种
1.主从复制
2.哨兵机制
3.cluster
这三种，其实都可以解决集群的问题。所以，区别的本质，不在于能不能解决集群的问题，而在于集群问题解决得好不好，方便不方便。
为什么要弄三种解决方案呢？
因为每一种都有缺陷。
1.主从复制
缺点
不能自动故障恢复
2.哨兵机制
优点
解决自动故障恢复的问题。
缺点
不能解决负载均衡的问题。
3.cluster
优点
解决负载均衡的问题。具体解决方案是分片/虚拟槽slot。
以上是这篇文章大的背景。细节看下文。
哨兵和cluster的区别？本质区别？
区别
1.主从复制-备份
备份。
或者，读写分离。
2.哨兵-高可用
解决的问题是：自动化故障恢复
3.cluster-高并发
分片/槽
参考
redis中主从、哨兵和集群这三个有什么区别 ？分别有什么优势？适用于什么场景？在实际工作如何选择？
主从模式：备份数据、负载均衡，一个Master可以有多个Slaves。 sentinel发现master挂了后，就会从slave中重新选举一个master。 cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。
sentinel着眼于高可用，Cluster提高并发量。
问题是哨兵也可以监控多个主数据节点，这也是数据节点的集群啊？为什么还需要cluster这种集群解决方案呢？ cluster有分片/槽算法，把请求尽量平均的负载均衡到各个机器。
哨兵部署的机器数量
数量
七. Redis Sentinel部署技巧
1.Sentinel节点不应该部署在一台物理机上。
2.部署至少三个且奇数个的Sentinel节点
3.只有一套Sentinel，还是每个主节点配置一套Sentinel的讨论的建议方案是如果Sentinel节点集合监控的是同一个
业务的多个主节点集合，那么使用方案一，否则使用方案2.
作者：大道化简 来源：CSDN 原文：blog.csdn.net/sunhuiliang… 版权声明：本文为博主原创文章，转载请附上博文链接！
一般三主三从就够用了
支付系统
也是个位数的集群
cluster包含哨兵机制吗？
哨兵机制的功能，即通过监控实现自动故障恢复。这些功能，特别是解决自动故障恢复，cluster解决方案都支持这些功能。
redis-cluster：如何自动故障恢复？
1.哨兵机制是解决自动故障恢复的问题
2.那么，cluster是怎么解决自动故障恢复？基本上实现原理差不多。
生产环境部署
juejin.cn/post/684490… juejin.cn/post/684490…
redis-集群解决方案：主要是cluster和第三方代理？
解决方案
1.第三方 代理
豌豆荚codis
codis是一个豌豆荚团队开源的使用Go语言编写的Redis。
Proxy使用方法和普通的redis没有任何区别，设置好下属的多个redis实例后就可以了，使用时在本需要连接redis的地方改为连接codis，它会以一个代理的身份接收请求。
并使用一致性hash算法，将请求转接到具体redis，将结果再返回codis，和之前比较流行的twitter开源的Twemproxy功能类似。
这套架构的特点： 分片算法：基于 slot hash桶； 分片实例之间相互独立，每组 一个master 实例和多个slave； 路由信息存放到第三方存储组件，如 zookeeper 或etcd 旁路组件探活 codis是目前用的最多的集群方案，codis一个比较大的优点是可以不停机动态新增或删除数据节点，旧节点的数据也可以自动恢复到新节点。
2.官方 cluster
cluster与哨兵的区别
1.哨兵机制
客户端连接哨兵
2.cluster
客户端直接连接主数据节点
Redis官网推出，可线性扩展到1000个节点
无中心架构
一致性哈希思想
客户端直连redis服务，免去了proxy代理的损耗
具体的redis cluster的搭建方案可以参考官方的搭建方案。
youzhixueyuan.com/detailed-ex…
3.cluster-分片/虚拟槽 + 哨兵-自动故障恢复
即时通讯产品，就是采用的这种解决方案。
redis-工作实践
集群
即时通讯产品
1.客户端连接哨兵
2.哨兵监控三个节点
大厂
1.客户端连接主数据节点
2.哨兵节点只负责监控数据节点
Redis客户端把请求发送到Twemproxy，路由规则发送到正确的Redis实例
LVS集群：实现twemproxy的负载均衡，提高proxy的可用性和扩容能力，使得twemproxy对应用透明
Sentinel集群：检测Redis主从的存活状态，当redis master失效，把slave提升为新的master
支持无效Redis实例的自动删除
减少客户端与Redis实例的连接数
redis-大厂
有赞
总结
综上所述，回答了以下问题：
Redis集群为了解决什么问题而存在的？
解决线性可扩展性。
Redis集群诞生以前怎么解决这个问题？
客户端分片、代理协助分片(Twemproxy)、查询路由、预分片、一致性哈希、客户端代理/转发等。
Redis集群采用什么方式保证线性可扩展性、可用性、数据一致性？
Hash槽、查询路由、节点互联的混合模式。
Redis集群化面临的问题是什么？
Redis集群本身要解决的是可伸缩问题，同时数据一致、集群可用等一系列问题。前者涉及到了节点的哈希槽的分配(含重分配)，节点的增删，主从关系指定与变更(含自动迁移)这些具体的交互过程；后者则是故障发现，故障转移，选举过程等详细的过程。
Redis集群实现的核心思想和思路是什么？
通过消息的交互（Gossip）实现去中心化(指的是集群自身的实现，不是指数据)，通过Hash槽分配，实现集群线性可拓展。
Gossip协议
即节点之间互相通信！
redis-命令类型
命令类型
五种
1.meet
建立握手连接
2.ping
检查通信是否正常
3.pong
成功
4.fail
失败
5.publish
1）哨兵节点向主数据节点发送主题数据；
2）然后，其他哨兵节点获取主题数据；
3）最后，哨兵节点之间，两两建立命令连接。
4.4. Sentinel的通信命令 Sentinel 节点连接一个 Redis 实例的时候，会创建 cmd 和 pub/sub 两个 连接。Sentinel 通过 cmd 连接给 Redis 发送命令，通过 pub/sub 连接到 Redis 实例上的其他 Sentinel 实例。 Sentinel 与 Redis 主节点 和 从节点 交互的命令，主要包括：
命令 作用
PING
Sentinel 向 Redis 节点发送 PING 命令，检查节点的状态
INFO Sentinel 向 Redis 节点发送 INFO 命令，获取它的 从节点信息
PUBLISH Sentinel 向其监控的 Redis 节点 sentinel:hello 这个 channel 发布 自己的信息 及 主节点 相关的配置
SUBSCRIBE Sentinel 通过订阅 Redis 主节点 和 从节点 的 sentinel:hello 这个 channnel，获取正在监控相同服务的其他 Sentinel 节点
Sentinel 与 Sentinel 交互的命令，主要包括：
命令 作用
PING
Sentinel 向其他 Sentinel 节点发送 PING 命令，检查节点的状态
SENTINEL:is-master-down-by-addr 和其他 Sentinel 协商 主节点 的状态，如果 主节点 处于 SDOWN 状态，则投票自动选出新的 主节点
作者：零壹技术栈 链接：juejin.cn/post/684490… 来源：掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
