### 哨兵短板 假如现在有这么个业务场景，假如公司是个商城业务，商品数量很多，需要redis存贮的数据大约200G，但是，公司只有100G的机器，主从哨兵的时候就会发现其实每台redis的存贮数据都是一样的，每个redis实力都是**全量存储**，也就是主从结构+哨兵可以实现高可用故障切换+冗余备份，但是并不能解决**数据容量**的问题，用哨兵，浪费内存且有**木桶效应**。所以，为了最大化利用内存，就有了Cluster，也就是**分布式存储**。即每台redis存储不同的内容。说到分布式存贮就不得不说一下redis的两种分布式方案了。 ### 客户端分区方案 优点是**分区逻辑可控**，缺点是**需要自己处理数据路由、高可用、故障转移**等问题，比如在**redis2.8**之前通常的做法是获取某个`key`的`hashcode`，然后取余分布到不同节点，不过这种做法无法很好的支持动态伸缩性需求，**一旦节点的增或者删操作，都会导致key无法在redis中命中**，这个方案真的和高可用不沾边也就不多说了。 ### 代理方案 优点是**简化客户端分布式逻辑和升级维护便利**，缺点是**加重架构部署复杂度和性能损耗**，比如**twemproxy**、**Codis**，这两个如果我有时间的话也会写一下。  官方为我们提供了专有的集群方案：**Redis Cluster**，它非常优雅地解决了 Redis 集群方面的问题，部署方便简单，因此理解**应用好 Redis Cluster 将极大地解放我们使用分布式 Redis 的工作量**。 ### 这里我总结了一下哨兵和cluster如何选择 **单机**：数据量少，主要承载高并发场景，其实单机足够了。 **哨兵**：一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，结合sentinal集群，去保证redis主从架构的高可用性，就可以了。 **redis cluster**：主要是针对海量数据+高并发+高可用的场景，**海量数据**，如果你的数据量很大，那么建议就用redis cluster，可以理解为只要是海量数据单机和哨兵根本不行，需要分布式存储才可以。 ### Redis Cluster简介 Redis Cluster 是 Redis 的分布式解决方案，在3.0版本正式推出，有效地解决了 Redis 分布式方面的需求。当遇到**单机内存、并发、流量**等瓶颈时，可以采用 Cluster 架构方案达到负载均衡的目的。 架构图(这个图是百度搜的我就不自己画了太丑了)：  理解一下图片就行:图中，**每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点，对其操作。** Redis 集群提供了以下两个好处： 1、将数据自动切分到多个节点的能力。 2、当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力，拥有自动故障转移的能力。 我把文章分成小节，附在标题上吧。。方便有需要的朋友翻阅。