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…