Redis分布式数据存储

为什么需要分布式存储？

我们一个主机的内存总是有限的，那么redis缓存的数据过多的话，肯定会有用完的时候，如果系统又有必要存储大量的redis数据，就需要分布式存储来进行横向的扩展。
一个master存储量不够，那么我们就将数据分离，再添加一个master。N个master node，每个master都挂载多个slave node进行读写分离。这就是redis cluster集群架构（多master+读写分离+高可用）。
如图：

redis cluster介绍

什么是redis cluster，存储redis数据的分布式架构。

• 可以自动将数据分片，每个master上存放一部分数据
• 提供内置的高可用支持，部分master不可用是，其余的master还是可以使用的
• 在redis cluster架构下，redis要开放两个端口，一个是6397端口，一个是加10000的端口号，比如16397，16397是进行集群节点之间的通信的，比如故障检测，配置更新，故障转移授权等等

分布式存储数据算法

hash：这种算法就是对key进行取模，比如有3台机器，那么就对3进行取模。key = 1111 那么取模的值为1，就会存到第二台机器上。

但是这样如果有一台机器宕机了，不仅该台主机数据丢失，而且其他数据也会大部分都查询不到，因为缺少了一台主机，所以所有的key要对2进行取模。那原本比如11114 对3取模是2，存储到了第3台机器，结果现在查询的时候对2取模值为0，就会去第一台机器查询，自然查询不到了。那么大量的缓存数据缺失，导致数据库压力增加，就可能造成系统崩溃

一致性hash：会有一个圆环的概念，同样是通过hash算出来数据需要落在哪台主机上，但是如果当前主机宕机，或者数据查询不到的话，会按照顺时针到下一个节点的主机上再次查询。但是这样也会有一个热点的问题，如果某一个区间的值都在同一个master中的话，会有大量的请求涌入进同一个mster造成流量瓶颈，影响性能。
如图：

一致性hash+虚拟节点：会将节点做虚拟的分布式存储，这样同一个区间内的数据会均匀的分布在所有节点上，不会造成master热点的问题。如图：

redis cluster的hash slot：

redis cluster会有固定的16384个hash slot，不管机器有多少个，这16384个节点都均匀的分布在所有的主机上，哪怕是一个主机宕机了，也可以迅速的完成迁移，不会对其他数据的查询造成影响

redis cluster核心原理

1、基础通信原理
采用的是gossip协议进行通信。是所有节点之间进行相互的通信，保持整个集群所有节点的数据是完整的。并且元数据的更新比较分散不会再同一个节点上有过多的压力，缺点就是可能会有一定的延时。
另一种通信方式是集中式，redis cluster没有用这个，因为这个虽然说元数据的更新和读取时效性比较好，但是集中处理会对元数据的存储造成一定的压力

2、节点通信
每个节点都有一个专门用来做节点通信的端口10000，比如一个提供服务的端口是7001，那么节点通信的端口就是17001。每隔一段时间就会往其他节点发送ping消息，其他节点会返回pong

3、交换信息
故障信息：节点的增加或者移除，hash slot信息，等等

gossip协议
gossip协议包含很多信息，ping、pong、meet、fail等等
meet：是发送给新的节点，告诉他们加入集群，然后进行相互的通信。
ping：每隔节点都会频繁的发送ping，包含自己的状态还有所维护的元数据，进行数据的交换
pong：返回ping和meet，包含自己的状态和其他信息，也可以用于信息的广播和更新
fail：某个节点判断另一个节点fail之后，会发送fail告诉其他节点指定的节点宕机了

ping消息
ping是很频繁的，并且会携带元数据增加网络的负担。每隔节点每秒会进行10次ping，每次ping会选择最不经常通信的5个节点。比如说两个节点10分钟都没有进行ping，那么数据会严重不一致，出现问题。

redis cluster的高可用

和哨兵模式几乎是一样的
判断节点宕机
如果一个节点认为另一个节点宕机就是pfail，主观宕机
如果多个节点都认为这个节点宕机了，就是fail，客观宕机。跟哨兵的sdown和odown是一样的

在cluster_node_timeout规定的时间内某个节点一直都没有返回pong，那么就会认为这个节点pfail，然后和其他节点ping的时候会带上这个信息，如果超过半数的节点都认为这个节点pfail，就会变成fail。

从节点选举
先过滤节点，如果长时间不与master进行通信了，那么这个slave就不在选举的范围内考虑。
每个从节点都会根据自己对master复制数据的offset，来设置一个选举时间，offset越大的（复制数据越多），选举时间越靠前，优先进行选举
所有的master node给slave进行投票，如果大部分的master（N/2 + 1）都投给了一个slave那么这个节点可以切换为主节点。

jedis客户端

我们开发的时候都是基于jedis进行开发，他是基于Java 的client，因为我们现在将的是redis cluster，所以使用的就是jedis cluster api去开发。我们来说一些jedis cluster和redis cluster交互的原理。

基于重定向的客户端

客户端会随意给一个redis实例发送一个命令，这个实例就会计算hash slot的值，如果在本地就会直接处理，如果在其他机器就返回给客户端moved，让客户端进行重定向。