关于redis:Redis相关知识点整理

Redis相干知识点整顿

1、Redis是什么?

  • 在web利用倒退的初期,关系型数据库倍受关注。因为过后的web站点访问量和并发量不高,交互少。在起初随着访问量的晋升,应用关系型数据库的web站点都开始在性能上呈现瓶颈。而这个瓶颈的源头都是在磁盘的读写上。磁盘的读写速度速度比起高并发业务下的访问量来说要慢的多,而对着互联网的倒退,导致对web利用的性能有了更高的需要,次要体现在:

    • 低提早的读写速度:利用能够快速反应用户的申请
    • 反对海量的数据和流量:对于搜寻这样的大型利用而言,须要利用PB级别的数据和应答百万级别的流量
    • 大规模的集群治理:系统管理员心愿分布式应用能更简略的部署和治理
    • 宏大经营老本的考量:系统管理员心愿分布式应用能简略的部署和治理
为了克服这一问题,NoSQL应运而生,同时以高性能,可扩展性强,高可用等长处宽泛受到开发人员和仓库管理人员的青眼。
  • Redis是什么?Redis是当初最受欢迎的NoSQL数据库之一,Redis是一个应用ANSIC编码的开源数据库,蕴含多种数据结构,反对网络,基于内存,可选持久性的键值对存储数据库,个性:

    • 基于内存运行,性能高效
    • 反对分布式,实践上能够有限扩大
    • key-value存储系统
  • 绝对于其余数据库类型,Redis具备的特点是:

    • 操作具备原子性
    • 长久化
    • 高并发读写

2、Redis的利用场景

  • Redis的利用场景包含:缓存零碎(热点数据,高频读,低频写),计数器。音讯队列零碎,排行榜,社交网络和实时零碎

3、Redis的数据类型和次要个性

  • Redis提供的数据类型包含五种自在类型和一种自定义类型,这5种自有类型包含:Stirng类型,哈希类型,列表类型,汇合类型,和程序汇合类型。
  • String类型:它是一个二进制平安的字符串,意味着它不仅能存储字符串,还能存储图片视频等多种类型,最大长度反对521M
  • Hash类型:该类型是有field和关联的value组成的map。其中,field和value都是字符串类型的。
  • 列表类型:该类型是一个插入程序排序的字符串元素汇合,基于双链表实现
  • Set汇合类型:是一种无程序的汇合,List是有序的且惟一
  • 程序汇合类型:zset是一种有序汇合类型,每个元素都会关联一个double类型的分数权值,通过这个权值能够为汇合中的成员进行从小到大的排序,与set类型一样,其底层也是通过这个哈希表实现的

4、Redis简略动静字符串

基于c语言中传统字符串的缺点,Redis本人构建了一种名为简略动静字符串的形象类型,SDS简直贯通了Redis的所有数据结构。

5、事务

  • Redis自身的每条语句是原子性的,而且对多个语句提供了事务的反对。

    • 命令序列化
    • 原子性
    • 三阶段:开始事务-命令入队-执行事务

6、Redis常见的问题-击穿

  • 什么叫缓存的击穿:当Redis获取某一个key时,因为key不存在,而必须向DB发动一次申请的行为,叫做Redis击穿
  • 引发击穿的起因:

    • 第一次拜访
    • 歹意拜访不存在的key
    • key过期
  • 正当的躲避计划

    • 服务器启动时提前进行写入
    • 标准key的命名,通过中间件拦挡
    • 对于高频拜访的key,设置正当的TTL或永不过期

7、Redis常见的问题-雪崩

  • 什么叫缓存的雪崩:Redis缓存层因为某种原因宕机后,所有的申请会涌向存储层,短时间内的高并发会导致存储层挂机,称之为Redis雪崩
  • 正当的躲避计划:

    • 应用Redis集群
    • 限流

8、除Redis之外还有什么NoSQL型数据库

  • MemCache

    • 是一个与Redis十分类似的数据库,然而他的数据结构没有Redis丰盛。是一个分布式的通知缓存零碎,被许多网站用于晋升网站的访问速度,对于一些大型的须要被频繁拜访数据库的网站访问速度晋升非常显著
  • Mongo

9、Redis集群

  • Redis集群有三种集群模式,别离是主从模式,Sentinel模式,Cluster模式

10、主从模式

  • 主从模式是三种模式中最简略的一种,在主从赋值中,数据库分为两类,主数据库和从数据库(master和slave),特点有:

    • 主数据库能够进行读写操作,当读写操作导致数据变动后会主动将数据同步给从数据库
    • 从数据库个别都是只读的,并且只承受从主数据库同步过去的数据
    • 一个master能够领有多个slave,一个slave只能有一个master
    • slave挂了不影响其余slave的读和master的读和写,重新启动后将数据从master中同步过去
    • master挂掉之后,不影响算啦测的读,然而redis不再提供写服务,master重启后会从新对外提供
    • master挂了之后,不会在slave当选一个master
  • 工作机制:

    • 当slave启动后,被动向master发送SYNC命令。master接管到SYNC命令后在后盾保留快照(RDB长久化),和缓存保留快照这段时间的命令,而后将保留的快照文件和缓存的命令发送给slave,slave承受到快照文件和命令后会加载快照文件和缓存的执行命令
    • 复制初始化之后,master每次承受到的写命令都会同步发送给slave,保障主从数据统一。
  • 平安设置:

    • 当master设置明码后,客户端拜访master须要明码,启动slave须要明码,在配置文件中配置即可,客户端拜访slave不须要明码
  • 、毛病:从下面能够看出,master节点在主从模式中惟一,若master挂掉,则redis无奈对外提供写服务
  • 主从模式的搭建

11、Sentinel模式(哨兵模式)

  • 主从模式的弊病就是不具备高可用性,当主机挂掉之后,Redis不再对外提供写入操作,因而哨兵机制由此而生
  • 哨兵就是用来监控redis集群的情况,特点如下

    • 哨兵模式是建设在主从模式的根底上,如果只有一个redis节点,哨兵机制就没有任何意义
    • 当master挂掉之后,哨兵会在slave中抉择额一个阶段作为master,并主动批改他们的配置文件,其余slave节点的属性会被批改,至多slaveof属性会更新
    • 当master启动之后,它将不再是master而是作为slave接管新的master同步数据
    • 哨兵机制因为也是一个过程,也有挂掉的时候,所以sentinel也会启动多个造成一个sentinel集群
    • 当多个sentinel配置的时候,他们之间也会相互监控
    • 当主从模式配置明码时,sentinel也会同步将配置信息批改到配置文件中,不须要放心
    • 一个sentinel或sentinel集群能够治理多个主从redis,多个sentinel也能够监控同一个redis
    • sentinel最好不要和redis部署在同一台机器上,不然redis服务器挂掉之后,sentinel也挂了
  • 工作机制

    • 每个sentinel以每秒钟一次的频率向他所知的master及其他sentinel实例发送一个PING命令
    • 如果一个实例间隔最初一次无效回复PING的命令工夫超过down-after-milliseconds 选项所指定的值,这个实例会被sentinel标记为主观下线(就是,我每秒钟会叫你一次,设定一个工夫,若这个工夫内你还没有回复我,则我认为你曾经死了)
    • 如果一个master被标记为主观下线,则正在监督这个master的所有sentinel会每秒一次的频率确定master确实进入了主观下线状态
    • 当有足够数量的sentinel(大于等于配置文件指定的值)则在指定的工夫范畴内认为master确实进入的主观下线的状态,会被标记为主观下线(我叫你不答复,其他人叫你也不答复,则由可能宕机状态变为主观上的宕机状态)
    • 在个别状况下,没个sentinel会以每10s一次的评率向它始终的所有master,slave发送INFO命令
    • 当master被sentinel标记为主观下线时,sentinel向下线的master的所有slave发送INFO的评率会从10s一次转换成1s一次
    • 若没有足够数量的sentinel批准master曾经下线,master的下线状态就会移除,这个时候若master向sentinel的PING命令就有返回值,master的主观下线状态就会被移除
当应用sentinel模式的时候,客户端就不必间接连贯redis,而是连贯sentinel中的ip和port,由sentinel来提供具体的可提供服务的redis实现,这样当master节点挂掉之后,sentinel就会感知,并将新的节点告知使用者.之后即便原来的节点重启,也只能作为slave节点.

12、Cluster模式

  • sentinel模式能够满足个别的生产需要,具备高可用性,然而当数据量过大到一台服务器放不下的状况时,主从模式或者哨兵模式就不能满足需要了,这个时候须要对数据的存储进行分片,将数据存储到多个redis实例中,cluster模式的呈现就是为了解决单机redis容量无限的问题,所以redis的数据依据肯定的队则调配到多个机器上
  • cluster能够说是sentinel模式和主从模式的结合体,通过cluster能够实现主从和master重选性能,如果配置两个正本和三个分片的话,就须要六个redis实例,因为redis的数据是依据肯定的规定调配到cluster的不同机器的,当数据量过大时,能够新增机器进行扩容
  • 应用集群,只须要将redis配置文件中的cluster-enable配置关上即可,每个集群中至多须要三个主数据库能力失常运行,性增节点也十分不便
  • cluster集群的特点

    • 多个redis节点网络互联,数据共享
    • 所有的节点都是一主一从(也能够是一主多从)其中从库不提供服务,仅作为备用
    • 不反对同时解决多个key,因为redis须要将key平均的散布在每个节点上,并发量很高的状况下同时创立key-value会升高性能并导致不可预测的行为
    • 反对在线减少和删除节点
    • 客户端能够连贯任何一个主节点进行读写
    • redis-cluster是去中心化的,连贯哪个节点都能够获取数据和设置数据(主节点),从节点只是作为备份存在,个别不提供服务
注:redis-cluster是redis的分布式解决方案,无效的解决了redis分布式方面的需要,redis-cluster个别由多个节点组成,节点数量至多为6个能力保障组成残缺高可用集群.其中,三个主节点,三个从节点,单个主节点会调配槽,解决客户端的命令申请,而从节点会在主节点故障之后,顶替主节点

13、数据分片策略

  • 分布式存储计划中最重要的一点就是数据分片,shading
  • 为了使得集群可能程度扩大,首要解决的问题就是如何将整个数据集依照肯定的规定调配到多个节点上,长用的数据分片办法有:范畴分片,哈希分片,一致性哈希算法和虚构哈希槽
  • 范畴分片:范畴分片假如数据是有序,将程序相邻近的数据放在一起,能够很好的反对变俩操作,这种分片模式的毛病是依照程序写的时候会存在热点(即缓存在同一个片上),当日志在写入的时候,个别的日志都是依照工夫排序的,这个时候工夫是枯燥递增的,这个时候写入的热点永远在最初一个分片上。
  • redis-cluster采纳哈希槽分区,所有的键依据哈希函数映射到0-16383个整数槽内,计算公式slot=CRC16(KEY) & 16383.每一个节点负责保护一部分槽及所映射的键值数据
  • 虚构槽分区的特点

    • 解耦数据和槽之间的关系,简化了节点的扩容和膨胀难度
    • 节点本身保护槽的映射关系,不须要客户端或代理服务器保护槽分区的元数据
    • 反对节点,槽和键之间的映射查问

14、集群扩容

  • 当一个 Redis 新节点运行并退出现有集群后,咱们须要为其迁徙槽和数据。首先要为新节点指定槽的迁徙打算,确保迁徙后每个节点负责类似数量的槽,从而保障这些节点的数据平均。
  1. 首先启动一个 Redis 节点,记为 M4。
  2. 应用 cluster meet 命令,让新 Redis 节点退出到集群中。新节点刚开始都是主节点状态,因为没有负责的>槽,所以不能承受任何读写操作,后续咱们就给他迁徙槽和填充数据。
  3. 对 M4 节点发送 cluster setslot { slot } importing { sourceNodeId } 命令,让指标节点筹备导入槽的数据。 >4) 对源节点,也就是 M1,M2,M3 节点发送 cluster setslot { slot } migrating { targetNodeId } 命令,让源节>点筹备迁出槽的数据。
  4. 源节点执行 cluster getkeysinslot { slot } { count } 命令,获取 count 个属于槽 { slot } 的键,而后执行步骤>六的操作进行迁徙键值数据。
  5. 在源节点上执行 migrate { targetNodeIp} ” ” 0 { timeout } keys { key… } 命令,把获取的键通过 pipeline 机制>批量迁徙到指标节点,批量迁徙版本的 migrate 命令在 Redis 3.0.6 以上版本提供。
  6. 反复执行步骤 5 和步骤 6 直到槽下所有的键值数据迁徙到指标节点。
  7. 向集群内所有主节点发送 cluster setslot { slot } node { targetNodeId } 命令,告诉槽调配给指标节点。为了>保障槽节点映射变更及时流传,须要遍历发送给所有主节点更新被迁徙的槽执行新节点。

15、膨胀集群

膨胀节点就是将 Redis 节点下线,整个流程须要如下操作流程。

  • 首先须要确认下线节点是否有负责的槽,如果是,须要把槽迁徙到其余节点,保障节点下线后整个集群槽节点映射的完整性。
  • 当下线节点不再负责槽或者自身是从节点时,就能够告诉集群内其余节点遗记下线节点,当所有的节点遗记改节点后能够失常敞开。
  • 下线节点须要将节点本人负责的槽迁徙到其余节点,原理与之前节点扩容的迁徙槽过程统一。
  • 迁徙完槽后,还须要告诉集群内所有节点遗记下线的节点,也就是说让其余节点不再与要下线的节点进行 Gossip 音讯替换。
  • Redis 集群应用 cluster forget { downNodeId } 命令来讲指定的节点退出到禁用列表中,在禁用列表内的节点不再发送 Gossip 音讯。

16、故障转移

  • 当 Redis 集群内大量节点呈现故障时通过主动故障转移保障集群能够失常对外提供服务。
  • 当某一个 Redis 节点主观下线时,Redis 集群会从其从节点中通过选主选出一个代替它,从而保障集群的高可用性。这块内容并不是本文的核心内容,感兴趣的同学能够本人学习。
  • 然而,有一点要留神。默认状况下,当集群 16384 个槽任何一个没有指派到节点时整个集群不可用。执行任何键命令返回 CLUSTERDOWN Hash slot not served 命令。当持有槽的主节点下线时,从故障发现到主动实现转移期间整个集群是不可用状态,对于大多数业务无法忍受这状况,因而倡议将参数 cluster-require-full-coverage 配置为 no ,当主节点故障时只影响它负责槽的相干命令执行,不会影响其余主节点的可用性。

参考文章:
https://www.jianshu.com/p/0a8…
https://blog.csdn.net/miss118…
https://www.cnblogs.com/power…

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据