喜欢就 关注 我们吧！
简介：
Hello 各位 ，我是公号「八点半技术站」的创作者 - Bruce.D （姓氏：豆）。
感谢微信给予的个人认证，专注于PHP、数据库技术领域知识经验分享。
技术的交流、不仅仅限制于阅读，在此欢迎各路大神、小白，来「wx技术群」分享自己的编程经验心得 与 技术实战干货。
开场白-灵魂拷问
Q：redis 集群为了解决什么问题存在？
A：解决线性扩展性。
Q：redis 集群诞生以前怎么解决这个问题？
A：客户端分片、代理协助分片（Twemproxy）、查询路由、预分片、一致性哈希、客户端代理/转发等。
Q：redis 集群采用什么方式保证线性可扩展性、可用性、数据一致性？
A：Hash槽、查询路由、节点互联的混合模式。
Q：redis 集群化面临的问题是什么？
A：Redis集群本身要解决的是可伸缩问题，同时数据一致、集群可用等一系列问题。前者涉及到了节点的哈希槽的分配(含重分配)，节点的增删，主从关系指定与变更(含自动迁移)这些具体的交互过程；后者则是故障发现，故障转移，选举过程等详细的过程。
Q：redis 集群实现的核心思想和思路是什么？
A： 通过消息的交互（Gossip）实现去中心化(指的是集群自身的实现，不是指数据)，通过Hash槽分配，实现集群线性可拓展。
其实当大家认真看完这 5 个话题，我认为你如果之前不了解 redis集群，那么现在肯定也有一个新的认知，并且知道如何去学习对应的技术点。
接下来，可以俗称 “ 铺垫 ” 吧~~~ 下面内容也很精华，浏览吧。
redis 集群 - 设计目标
redis 集群是一个distribute、fault-tolerant 的 redis实现。
主要设计目标是达到：线性可扩展性、可用性、数据一致性。
线性拓展：主官方推荐最大的节点数量为1000，由于Cluster架构中无Proxy层，Master与Slave之间使用异步replication。
数据一致性：客户端容忍一定程度的数据丢失，集群尽可能保存Client write操作的数据，保证数据一致性。
可用性：Redis集群通过partition来提供一定程度的可用性，当集群中的一部分节点失效或者无法进行通讯时，集群仍可以继续提供服务。
redis 集群 - 容错
节点失效检测：跟大部分分布式框架一样，Redis Cluster节点间通过持续的心跳来保持信息同步，不过 Redis Cluster节点信息同步是内部实现的，不依赖第三方组件，如zk。
集群中的 nodes持续交换 ping、pong数据，消息协议使用 Gossip，这两种 packet数据结构一样，它们之间通过 type字段区分。
节点定时向其他节点发送 ping命令，它会随机选择存储的其他集群节点的其中三个进行信息“广播”，例如广播的信息包含一项是节点是否被标记为 PFAIL/FAIL。
PFAIL表示 “ 可能已失效 ”，是尚未完全确认的失效状态（即可能是某个节点或少数 Master认为其不可达）；FAIL表示 Node被集群大多数的Masters认定为失效（即大多数 Master已认定为不可达，且不可达的时间已经超过配置的 NODE_TIMEOUT）。
当节点收到其他节点广播的信息，它会记录被其他节点标记为失效的节点。举个例子，如果节点被某个节点标记为 PFAIL，集群中大部份其他主节点也认为该节点进入了失效状态，那么该节点的状态会被标志为 FAIL。
当节点被标志为FAIL，这个节点已失效的信息会被广播至整个集群，所有集群中的节点都会将失效的节点标志为FAIL。
集群失效检测： 当某个 Master或者 Slave不能被大多数Nodes可达时，用于故障迁移并将合适 Slave提升为 Master。当Slave提升未能成功，集群不能正常工作。
即集群不能处理 Client的命令的请求，当 Client发出命令请求时，集群节点都将返回错误内容的 respone。
集群正常工作时，负责处理16384个slots的节点中，全部节点均正常。反之，若集群中有一部分 hash slot不能正常使用，集群亦将停止工作，即集群进入了FAIL状态。
对于集群进入 FAIL状态，会有以下两种情况：
至少有一个 hash slot不可用。
集群中大部份 Master都进入了 PFAIL状态。
往下拉，有干货
和我再战 n+1 天
同时，为了方便大家学习，我会把一些源码、技术干货存储到 github 中，随时可以在微信群 进行交流，扫下面二维码 ，备注 “技术进群” 就可以通过审核。
进群的小伙伴请加右侧私人微信（备注：技术进群）
----投稿分隔线----
投稿，关注公众号回复“投稿”，专员对接
-----商务合作分隔线----
商务合作，关注公众号回复“商务合作”，专员对接