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进行迁移。