与memcached客户端支持分布式方案不同，Redis更倾向于在服务端构建分布式存储
- Redis分布式集群图1
- Redis分布式集群
Redis Cluster是一个实现了分布式且允许单点故障的Redis高级版本，没有中心节点，具有线性可伸缩的功能。节点与节点之间通过二进制协议进行通信，节点与客户端之间通过ascii协议进行通信。
在数据的放置策略上，Redis Cluster将整个key的数值域分成4096个hash槽，每个节点上可以存储一个或多个hash槽，也就是说当前Redis Cluster支持的最大节点数就是4096。
Redis Cluster使用的分布式算法也很简单：crc16( key ) % HASH_SLOTS_NUMBER
整体设计可总结为：
- 数据hash分布在不同的Redis节点实例上
- M/S的切换采用Sentinel
- 写：只会写master Instance，从sentinel获取当前的master Instance
- 读：从Redis Node中基于权重选取一个Redis Instance读取，失败/超时则轮询其他Instance；Redis本身就很好的支持读写分离，在单进程的I/O场景下，可以有效的避免主库的阻塞风险
- 通过RPC服务访问，RPC server端封装了Redis客户端，客户端基于Jedis开发
在数据一致性问题上，Redis没有提供CAS操作命令来保障高并发场景下的数据一致性问题，不过它却提供了事务的功能
Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行）。
但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）
Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行
1 数据分布算法
决定了在多master节点时，数据如何分布到这些节点。
- 自动将数据分片，每个master放部分数据
- 提供内置的高可用，部分master不可用时，还可继续工作
Redis cluster下，每个Redis要开放两个端口，比如：
- 一个是6379
- 另一个就是加10000的端口号16379
16379端口用于节点间通信，即cluster bus集群总线。
cluster bus的通信，用来故障检测，配置更新，故障转移授权。cluster bus用另一种二进制协议 - gossip，用于节点间高效数据交换，占用更少网络带宽和处理时间。
1.1 hash
计算指定 key 的 hash值，然后对节点数量(3)取模。0、1、2三个结果打到对应mater node。
一个mater宕机，所有请求过来，会发现都基于最新的2个master取模，尝试去取数据。导致大部分请求无法拿到有效缓存，流量涌入DB。
高井发场景 下不可接受。并发下对节点3的流量无法走缓存，导致全部走DB，DB就会被压垮。
任一master宕机，大量数据就需重新计算再写入缓存。
某mater宕机，就导致数据全部失效。全部要重新对剩下2台master取模，再分布到其它节点。
1.2 一致性hash
自动缓存迁移、自动负载均衡。
可能集中在某个hash区间值多，导致大量数据涌入同个master，造成master热点问题，导致性能瓶颈。
同样是计算指定 key 的 hash值，然后用hash值在圆环对应各点(每点都有个hash值)对比，看hash值该落在这圆环的哪个部位。
key落在圆环后，顺时针寻找距离自己最近节点。
一致性hash算法保证任一master宕机，只有之前在那master上的数据会受影响，因为顺时针走，全部在之前master上找不到了。会顺时走到下个master，也找不到。
1/3的流量瞬间涌入DB，重新查询。几乎接近100%流量全部失效。
虚拟节点
给每个master做均匀分布的虚拟节点。
这样在每个区间内，大量数据均匀分布到不同节点内，而非按顺时针顺序，全部涌入同一master。
