1、单机redis在海量数据面前的瓶颈

2、怎么才能够突破单机瓶颈，让redis支撑海量数据？

redis如何通过master横向扩容支撑1T+数据量.png

3、redis的集群架构

redis cluster可以支撑N个redis master node，每个master node都可以挂载多个slave node。是读写分离的架构，对于每个master来说，写就写到master，然后读就从mater对应的slave去读。

高可用，因为每个master都有salve节点，那么如果master挂掉，redis cluster这套机制，就会自动将某个slave切换成master。

redis cluster（多master + 读写分离 + 高可用）

我们只要基于redis cluster去搭建redis集群即可，不需要手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用

4、redis cluster 与 replication + sentinal

如果你的数据量很少，主要是承载高并发高性能的场景，比如你的缓存一般就几个G，单机足够了，此时手动搭建replication，一个mater，多个slave，要几个slave跟你的要求的读吞吐量有关系，然后自己搭建一个sentinal集群，去保证redis主从架构的高可用性，就可以了

如果你是海量数据+高并发+高可用的场景，海量数据，如果你的数据量很大，那么建议就用redis cluster。

5、分布式数据存储的核心算法，数据分布的算法

hash算法 -> 一致性hash算法（memcached） -> redis cluster，hash slot算法。

用不同的算法，就决定了在多个master节点的时候，数据如何分布到这些节点上去，解决这个问题

1、redis cluster介绍

（1）自动将数据进行分片，每个master上放一部分数据

（2）提供内置的高可用支持，部分master不可用时，还是可以继续工作的

在redis cluster架构下，每个redis要放开两个端口号，比如一个是6379，另外一个就是加10000的端口号，比如16379。

16379端口号是用来进行节点间通信的，也就是cluster bus的东西，集群总线。cluster bus的通信，用来进行故障检测，配置更新，故障转移授权。cluster bus用了另外一种二进制的协议，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间

2、最老土的hash算法和弊端（大量缓存重建）

某一个master宕机，对于高并发场景不可以接受，因为此时一旦一个master宕机，所有请求重新求2膜，导致大部分请求全部无法拿到有效的缓存，大量流量涌入数据库中，可能所有缓存都会失效，几乎接近100%流量失效。 

3、一致性hash算法（自动缓存迁移）+虚拟节点（自动负载均衡）

然后，key求hash着落的位置，key落在圆环以后顺时针着最近的节点请求数据。

当某一个master宕机，此时只有之前那个master上的数据会收影响，按照顺时针着下一个master，此时导致1/3（1/n）的流量失效，查数据库。比接近之前100%  的流量失效好些。      

存在的问题：缓存热点的问题，肯能集中在某个hash区间得值特别多，导致大量数据涌入同一个吧master，造成master热点性能瓶颈。

解决热点问题：虚拟节点

图中细线是正常节点，粗线是虚拟节点，给每个master都做了均匀分布的虚拟节点，此时在每个区间内大量的数据，都会均匀分布到不同的节点内。

4、redis cluster的hash slot算法

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。

redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot。hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去移动hash slot的成本是非常低的。客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现。
当一台机器宕机， 此时最多1/3数据失效，但是redis会很快将slot进行迁移。