redis 集群是一个提供在多个redis间节点间共享数据的程序集。
redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
redis 集群的特点:
自动分割数据到不同的节点上。
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
可线性扩展到上千个节点
可使数据自动路由到多个节点
实现了多个节点间的数据共享
可支持动态增加或删除节点
可保证某些节点无法提供服务时不影响整个集群的操作
不保证数据的强一致性
支持redis所有处理单个数据库键的命令
不支持对多个数据库键的操作，比如mset、sunion
不能使用 select 命令，集群只使用默认的0号数据库
架构细节:
(1)所有的redis节点彼此互联(ping-pong机制),内部使用二进制协议优化传输速度和带宽.
(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value
(1)领着选举过程是集群中所有master参与,如果半数以上master节点与master节点通信超过(cluster-node-timeout),认为当前master节点挂掉.
(2):什么时候整个集群不可用(cluster_state:fail),当集群不可用时,所有对集群的操作做都不可用，收到((error) clusterdown the cluster is down)错误
a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成进群的slot映射[0-16383]不完成时进入fail状态.
b:如果进群超过半数以上master挂掉，无论是否有slave集群进入fail状态。
hash slot
redis集群没有使用一致性hash，而是引入了哈希槽（hash slot）的概念。
redis集群一共有16384个哈希槽，每个key通过crc16校验后对16384取模来决定对应哪个槽。
hash_slot = crc16(key) mod 16384
每个主节点都负责处理 16384 个哈希槽的其中一部分，由于redis 集群的key被分割为 16384 个slot， 所以集群的最大节点数量也是 16384 个。推荐的最大节点数量为1000个左右。
举个例子，比如当前集群有3个节点,那么：
节点 a 包含 0 到 5500号哈希槽。
节点 b 包含5501 到 11000 号哈希槽。
节点 c 包含11001 到 16384号哈希槽。
这
种结构很容易添加或者删除节点。比如如果我想新添加个节点d，我需要从节点 a, b,
c中得部分槽到d上。如果我像移除节点a,需要将a中得槽移到b和c节点上,然后将没有任何槽的a节点从集群中移除即可。由于从一个节点将哈希槽移动到另
一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
说明：
所有的哈希槽必须配置在集群中的某一个节点上。
节点和哈希槽之间的对应关系在搭建集群时配置，集群使用中也支持动态迁移。
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有n-1个复制品.
在我们例子中具有a，b，c三个节点的集群,在没有复制模型的情况下,如果节点b失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点a1，b1，c1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点b失败后，集群便会选举b1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了
不过当b和b1 都失败后，集群是不可用的.
redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.
第一个原因是因为集群是用了异步复制. 写操作过程:
客户端向主节点b写入一条命令.
主节点b向客户端回复命令状态.
主节点将写操作复制给他得从节点 b1, b2 和 b3.
主
节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低
—— 我们必须在性能和一致性之间做出权衡。 注意：redis 集群可能会在将来提供同步写的方法。 redis
集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子
假设集群包含 a 、 b 、 c 、 a1 、 b1 、 c1 六个节点， 其中 a 、b 、c 为主节点， a1 、b1 、c1
为a，b，c的从节点， 还有一个客户端 z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 a 、c 、a1 、b1 和
c1 ，小部分的一方则包含节点 b 和客户端 z1 .
z1仍然能够向主节点b中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将b1选举为新的master，那么z1写入b中得数据便丢失了.
注意， 在网络分裂出现期间， 客户端 z1 可以向主节点 b 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 redis 集群的一个重要的配置选项：
sentinel
是redis官方为集群提供的高可用解决方案。
在实际项目中可以使用sentinel去做redis自动故障转移，减少人工介入的工作量。另外sentinel也给客户端提供了监控消息的通知，这样客
户端就可根据消息类型去判断服务器的状态，去做对应的适配操作。
下面是sentinel主要功能列表：
监控（monitoring）： redis sentinel实时监控主服务器和从服务器运行状态。
提醒（notification）：当被监控的某个 redis 服务器出现问题时， redis sentinel 可以向系统管理员发送通知， 也可以通过 api 向其他程序发送通知。
自
动故障转移（automatic failover）： 当一个主服务器不能正常工作时，redis sentinel
可以将一个从服务器升级为主服务器， 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接到 redis 服务器时， redis
sentinel会告之新的主服务器地址和端口。
redis sentinel 是一个分布式系统， 你可以在架构中运行多个 sentinel 进程，这些进程通过相互通讯来判断一个主服务器是否断线，以及是否应该执行故障转移。
在
配置redis sentinel时，至少需要有1个master和1个slave。当master失效后,redis
sentinel会报出失效警告，并通过自动故障转移将slave提升为master，并提供读写服务;当失效的master恢复后，redis
sentinel会自动识别，将master自动转换为slave并完成数据同步。
通过redis sentinel可以实现redis零手工干预并且短时间内进行m-s切换，减少业务影响时间。
两个服务器中分别都部署redis和redis
sentinel。当master中的redis出现故障时（redis进程终止、服务器僵死、服务器断电等），由redis
sentinel将master权限切换至slave redis中，并将只读模式更改为可读可写模式。应用程序通过redis
sentinal确定当前master redis位置，进行重新连接。
根据业务模式，可以制定两种拓扑结构：单m-s结构和双m-s结构。如果有足够多的服务器，可以配置多m-s结构。
单
m-s结构特点是在master服务器中配置master redis（redis-1m）和master
sentinel（sentinel-1m）。slave服务器中配置slave redis（redis-1s）和slave
sentinel（sentinel-1s）。其中 master redis可以提供读写服务，但是slave
redis只能提供只读服务。因此，在业务压力比较大的情况下，可以选择将只读业务放在slave redis中进行。
双
m-s结构的特点是在每台服务器上配置一个master redis，同时部署一个slave redis。由两个redis
sentinel同时对4个redis进行监控。两个master
redis可以同时对应用程序提供读写服务，即便其中一个服务器出现故障，另一个服务器也可以同时运行两个master
redis提供读写服务。缺点是两个master redis之间无法实现数据共享，不适合存在大量用户数据关联的应用使用。
<a href="http://photo.blog.sina.com.cn/showpic.html#blogid=75ad98f30101fwqj&url=http://album.sina.com.cn/pic/0029c0wjgy6eewx6tvyba"></a>
两个结构各有优缺点，分别适用于不同的应用场景：
单m-s结构适用于不同用户数据存在关联，但应用可以实现读写分离的业务模式。master主要提供写操作，slave主要提供读操作，充分利用硬件资源。
双（多）m-s结构适用于用户间不存在或者存在较少的数据关联的业务模式，读写效率是单m-s的两（多）倍，但要求故障时单台服务器能够承担两个mater redis的资源需求。