以前的redis要搞几个节点，每个节点存储一部分的数据，得借助一些中间件来实现，比如说有codis、twemproxy，有一些redis中间件，你读写redis中间件，redis中间件负责将你的数据分布式存储在多个机器上的redis实例中。
现在的redis也不断在更新，现在的rediscluster，原生的redis集群模式，就可以做到在多台机器上部署多个redis实例，每个实例存储一部分数据，同时每个redis可以挂redis从实例，自动确保说，如果redis主实例挂了，会自动切换到redis从实例。
按照以前的redis架构，master节点的数据和slave节点的数据是一摸一样的，master能容纳多大的数据量，那么slave也就只能容纳多大的数据量。使用缓存清理算法可以释放空间，将旧的很少使用的数据，给清除出内存，然后保证内存中就只有固定大小的内存，不可能超过master内存的物理上限的。
这就是单master所导致的瓶颈问题。
分布式数据存储的核心算法，数据分布的算法：
hash算法 –>一致性hash算法 ->rediscluster的hashslot算法
用不同的算法，就决定了在多个master节点的时候，数据如何分布到这些节点上的问题。
（1） redis集群模式的工作原理
- 自动将数据进行分片，每个master上放一部分数据
- 提供内置的高可用支持，部分master不可用时，还能继续工作。
- 在rediscluster下，每个redis要开放两个端口，比如一个是6379这种4位数的端口，另外一个就是10000数值后的端口，比如16379端口。
这个16379端口号是用来进行节点通信的，也就是clusterbus的东西，集群总线。
clusterbus的通信，用来进行故障检测，配置更新，故障转移授权。
clusterbus用了另外一种二进制的协议，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。
（2） hash算法
原理：来了一个key之后，计算hash值，然后对节点数量（3）取模，取模结果一定是在0-2之间的，小于节点数量。
这样计算后，就可以打到对应的3个masternode上去，这样就实现了最简单的数据分布算法。
问题所在：一旦有一个masternode宕机了，请求过来后，会基于剩下的两个master去取模，原来是对3取模，现在是对2取模，原来的数据也不能用了，导致几乎大部分请求，全部无法拿到有效的缓存，大量的流量就会涌入数据库中。
高并发的场景来说，是不可以接受这样的，1/3的流量不能走缓存，全部走数据库，那么数据库就会被压垮。所以，hash算法最大的问题就是，只要有任意一个master宕机，那么大量的数据就需要重新写入缓存，风险很大。
（3） 一致性Hash算法+ 虚拟节点算法
原理：有一个key过来以后，同样是计算hash值，然后会用hash值在圆环对应的各个点上（每个点都会有一个hash值）去比对，看hash值应该落在这个圆环的哪个部位。key落在圆环上以后，就会顺时针旋转去寻找距离自己最近的一个节点。
一旦有一台圆环上的master宕机，过来key后，就会顺时针去下一个节点去取值，但是取不到值。
一致性hash算法，保证，任何一个master宕机，只有之前在那个master上的数据会受到影响，因为照着顺时针走，全部在之前的master上找不到了，master宕机了，会顺时针走到下一个master去，也是找不到的。那么就会有1/3的流量瞬间涌入数据库中去查找数据。
问题所在：缓存热点的问题，可能集中在某个hash区间内的值特别多，那么会导致大量的数据都涌入同一个master内，造成master的热点问题，性能出现瓶颈。
虚拟节点算法：给每个master都做了均匀分布的虚拟节点。
这样的话，在每个区间内，大量的数据，都会均匀的分布到不同的节点内，而不是按照顺时针的顺序去走，不会全部涌入同一个master内
（4） hashsolt算法
rediscluster有固定的16384个hashsolt，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hashsolt。
rediscluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hashsolt。
hashsolt让node的增加和移除变得很简单，增加一个master，就将其他master的hashsolt移动部分过去，减少一个master，就将它的hashsolt移动到其他master上去，移动hashsolt的成本是非常低的。
在集群中，任何一台master宕机，另外两个节点不影响，因为key找的是hashsolt，找的不是机器
（5） 在集群模式下，redis的key是如何寻址的？
（6） rediscluster
可以支撑N个redismasternode，每个masternode都可以挂载多个slavenode，能够继续保持读写分离的结构，对于每个master来说，写就写到master，然后读就从master对应的slave去读。
高可用方面，因为每个master都有slave节点，那么如果master挂掉，rediscluster这套机制，就会自动将某个slave切换成master。
简而言之，rediscluster就是（多master + 读写分离 + 高可用），我们只要基于rediscluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用
（7） rediscluster和 replication + sentinal
如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就是几个G，那么单机足够了，就搭建replication+一个master+多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，保证redis的高可用性。
rediscluster，主要是针对海量数据+高可用的场景。
（8） rediscluster节点间的内部通信机制
- 基础通信原理
一、 rediscluster节点间采取gossip协议进行通信
跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的。
集中式：集群元数据集中式存储的一个典型代表，就是大数据领域的storm，分布式的大数据实时计算引擎，集中式的元数据存储的架构，底层基于zookeeper（分布式协调的中间件）的集群所有元数据维护。
（好处：元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他的节点读取的时候就可以立即感知到。
缺点：所有的元数据更新压力全部集中在一个地方，可能会导致元数据的存储有压力。）
gossip协议：小道留言，所有节点都持有一份元数据，不同的节点如果出现了元数据的表更之后，就不断的将元数据发送给其他节点，让其他节点也进行元数据的变更。
（好处：元数据的更新比较分散，不是集中在一个地方的，更新请求会陆陆续续打到节点上更新，有一定延时，降低了压力。
缺点：元数据的更新有延时，可能导致集群的一些操作会有一些滞后。）
二、 10000端口
每个节点都有一个用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。
三、 gossip协议
gossip协议包含多种消息，包括ping，pong，meet，fail等等。
meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信。
redis-trib.rb add-node
其实内部就是发送了一个gossipmeet消息，给新加入的节点，通知那个节点去加入我们的集群。
ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据。
pong：返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新
fail：某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。
四、 ping消息深入
ping很频繁，而且要携带一些元数据，所以可能会加重网络负担。
每个节点每秒会执行10次ping，每次会选择5个最近没有通信的其他节点。
当然如果发现某个节点通信延时达到了cluster_node_timeout/2，那么立即发送ping，避免数据交互交换延时过长，滞后的时间太长了。
每次ping，一个是带上自己的节点信息，然后就是带上1\10其他接节点的信息，发送出去，进行数据交换。至少包含3个其他节点的信息，最多包含总结点n-2个其他节点的信息。
- 面向集群的jedis内部实现原理
开发中：使用jedis，就是redis的javaclient客户端，我们现在是rediscluster，那么就是使用的jedisclusterapi
jedisclusterapi与rediscluster集群交互的一些基本原理
一、 基于重定向的客户端
a、 请求重定向
客户端可能会挑选任意一个redis实例去发送命令，每个redis实例接收到命令，都会计算hashslot。
如果在本地就在本地处理，否则返回moved给客户端，让客户端进行重定向。
clusterkeyslotmykey，可以查看一个key对应的hashslot是什么。
用redis-cli的时候，可以加入-c参数，支持自动的请求重定向，redis-cli接收到moved之后，会自动重定向到对应的节点执行命令。
b、 计算hashslot
计算hashslot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hashslot。
用hashtag可以手动指定key对应的slot，同一个hashtag下的key，都会在同一个hashslot中，比如setmykey:{100}
c、 hashslot查找
节点间通过gossip协议进行数交换，就只到每个hashslot在哪个节点上。
二、 smartjedis
a、 什么是smartjedis
基于重定向的客户端，很消耗网络IO，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点。
所以大部分的客户端，比如javaredis客户端，就是jedis，都是smart的。
本地维护一份hashslot->node的映射表，缓存，大部分情况下，直接走本地缓存就可以找到hashslot->node，不需要通过节点进行moved重定向。
b、 JedisCluster的工作原理
其实就是维护了一个hash slot ->node映射表
在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot->node映射表，同时为每个节点创建一个JedisPool连接池。
每次基于JedisCluster执行操作，首先JedisCluster都会在本地就按key的hashslot，然后在本地映射表中找到对应的节点。
如果那个node正好还是持有那个hashslot，那么就ok；如果说进行了reshard这样的操作，可能hashslot已经不在那个node上了，就会返回moved。
如果JedisCluster API发现对应的节点返回moved，那么利用该节点的元数据，更新本地的hashslot->node映射表缓存。
重复上面几个步骤，知道找到对应的节点，如果重试超过5次，那么就会报出JedisClusterMaxRedirectionException。
jedis老版本，可能会出现在集群某个节点故障还没完成自动切换恢复时，频繁更新hashslot，频繁ping节点检查
c、 hashslot迁移和ask重定向
如果hashslot正在迁移，那么会返回ask重定向给jedis
jedis接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hashslot迁移过程中，所以JedisClusterApi是不会更新hashslot本地缓存
已经可以确定说，hashSlot已经迁移完了，moved是会更新hashslot -> node映射表缓存的
3. 高可用性与主备切换原理
rediscluster的高可用的原理，几乎跟哨兵是类似的。
一、 判断节点宕机
如果一个节点认为另一个节点宕机，那么就是pfail，主观宕机。
如果多个节点都认为另一个节点宕机了，那么就是fail，客观宕机，跟哨兵的原理几乎一样的。
在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail。
如果一个节点认为某个节点pfail了，那么会在gossip消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail。
二、 从节点过滤
对宕机的masternode，从其所有的slavenode中，选择一个切换成masternode。
检查每个slavenode与masternode断开连接的时间，如果超过了cluster-node-timeout * cluster-salve-validity-factor，那么就没有资格切换成master。
这个跟哨兵是一样的，从节点超时过滤的步骤。
三、 从节点选举
哨兵：对所有的slavenode进行排序，slavepriority，offset，runid
每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的节点，选举时间越靠前，优先进行选举。
所有的masternode开始slave选举投票，给要进行选举的slave进行投票，如果大部分masternode（N/2+1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。
从节点执行主备切换，从节点切换为主节点。
四、 与哨兵比较
整个流程跟哨兵相比，非常类似，所以说，rediscluster功能强大，直接集成了replication和sentinal功能。