redis-Cluster第一篇分区方案&应用场景篇

哨兵短板

假如现在有这么个业务场景，假如公司是个商城业务，商品数量很多，需要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、当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力，拥有自动故障转移的能力。
我把文章分成小节，附在标题上吧。。方便有需要的朋友翻阅。