Redis集群原理和总结

Redis集群原理

节点主从(镜像全量)+哈希slot(分片)

无主模型 遵循 CAP原则 C一致性 A可用性 P分区容错性,三者不可兼得

数据放在大数据集群中的方式/集群承载数据的方式:分片 镜像全量

镜像全量 优:做数据的高可用(节点不单一),不担心某一个节点故障,数据在其他节点有相同备份

​ 缺:占用内存资源,横向来说,没有对数据的扩展能力(4G–>12G)

分片 优:横向扩展能力强

​ 缺:没有备份

CRUD操作 增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete)

主从复制 主可以进行CRUD所有操作 从只能R

主从模型

在这里插入图片描述
图上能看得到的信息:

1, 只有1个Master,可以有N个slaver,而且Slaver也可以有自己的Slaver,由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系,而不是Zookeeper那种平行关系是自主推优出来的。

2, 读写分离,Master只负责写和同步数据给Slaver,Slaver承担了被读的任务,所以Slaver的扩容只能提高读效率不能提高写效率。

3, Slaver先将Master那边获取到的信息压入磁盘,再load进内存,client端是从内存中读取信息的,所以Redis是内存数据库。

当一个新的Slaver加入到这个集群时,会主动找Master来拜码头,Master发现新的小弟后将全量数据发送给新的Slaver,数据量越大性能消耗也就越大,所以尽量避免在运行时做Slaver的扩容。

简单总结下主从模式的设计:

优点:读写分离,通过增加Slaver可以提高并发读的能力。

缺点:Master写能力是瓶颈。

      虽然理论上对Slaver没有限制但是维护Slaver开销总将会变成瓶颈。

      Master的Disk大小也将会成为整个Redis集群存储容量的瓶颈。

哈希Slot:

这个艺名看起来很文艺,但也不是什么新技术,他的真名就叫分表分库,再上一个图:
在这里插入图片描述

图上能看到的信息:

1, 对象保存到Redis之前先经过CRC16哈希到一个指定的Node上,例如Object4最终Hash到了Node1上。

2, 将整个数据库分为16384个槽位,所有K的数据都是这些slot的一个,每个Node被平均分配了一个Slot段,对应着0-16384,Slot不能重复也不能缺失,否则会导致对象重复存储或无法存储。

3, Node之间也互相监听,一旦有Node退出或者加入,会按照Slot为单位做数据的迁移。例如Node1如果掉线了,0-5640这些Slot将会平均分摊到Node2和Node3上,由于Node2和Node3本身维护的Slot还会在自己身上不会被重新分配,所以迁移过程中不会影响到5641-16384Slot段的使用。

简单总结下哈希Slot的优缺点:

缺点:每个Node承担着互相监听、高并发数据写入、高并发数据读出,工作任务繁重

优点:将Redis的写操作分摊到了多个节点上,提高写的并发能力,扩容简单。

双剑合并:

看到这里大家也就发现了,主从和哈希的设计优缺点正好是相互弥补的,将图一每一套主从对应到图二中的每一个Node,就是Redis集群的终极形态,先Hash分逻辑节点,然后每个逻辑节点内部是主从,如图:
在这里插入图片描述

想扩展并发读就添加Slaver,想扩展并发写就添加Master,想扩容也就是添加Master,任何一个Slaver或者几个Master挂了都不会是灾难性的故障。

3.0以后,Master既是主节点又是哨兵,可以实现高可用

Redis集群总结

1.Redis集群是一个由多个节点组成的分布式服务集群,它具有复制、高可用和分片特性

2.Redis的集群没有中心节点,并且带有复制和故障转移特性,这可用避免单个节点成为性能瓶颈,或者因为某个节点下线而导致整个集群下线

3.集群中的主节点负责处理槽(储存数据),而从节点则是主节点的复制品

4.Redis集群将整个数据库分为16384个槽,数据库中的每个键都属于16384个槽中的其中一个

5.集群中的每个主节点都可以负责0个至16384个槽,当16384个槽都有节点在负责时,集群进入上线状态,可以执行客户端发送的数据命令

6.主节点只会执行和自己负责的槽有关的命令,当节点接收到不属于自己处理的槽的命令时,它将会处理指定槽的节点的地址返回给客户端,而客户端会向正确的节点重新发送

7.如果需要完整地分片、复制和高可用特性,并且要避免使用代理带来的性能瓶颈和资源消耗,那么可以选择使用Redis集群;

如果只需要一部分特性(比如只需要分片,但不需要复制和高可用等),那么单独选用twemproxy、Redis的复制和Redis Sentinel中的一个或多个

哨兵要解决什么问题?原理是什么?
​ 解决了主从模型中主服务器的故障问题
​ 当一个sentinel认为被监视的服务器已经下线时,它会向网络中的其他Sentinel进行确认,判断该服务器是否真的已经下线
​ 如果下线的服务器为主服务器,那么sentinel网络将对下线主服务器进行自动故障转移,通过将下线主服务器的某个从服务器提升为新的主服务器,并让其从服务器转为复制新的主服务器,以此来让系统重新回到上线的状态

twemproxy是位于客户端和服务器之间的路由代理层,计算方式是:k%服务器数量

twemproxy产生的三个问题: 单点故障(不能实现高可用)

​ 数据倾斜(特殊K值,大部分数据放置在某一台服务器上)

​ 数据摘取(新服务器加入时整个数据做全量再分发)

  • 8
    点赞
  • 33
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值