底层中间件-redis介绍-蒲公英云

一、redis简介

二、Redis基本数据类型（五种）

redis 自身是一个map，其中所有的数据都是采用key:value 的形式进行存储；数据类型指的是存储的数据的类型，也就是Value部分的类型，key部分永远都是字符串类型

高级数据类型有三种：Bitmaps，HyperLogLog， GEO

1. String字符串（对应Java-String）

存储的数据：单个数据，最简单的数据存储类型，也是最常用的数据存储类型
存储数据格式：一个存储空间保存一个数据
存储内容：通常使用字符串，如果字符串以整数的形式展示可以作为数字操作使用
使用场景：大型企业级应用中，分表操作是基本操作，使用多张表存储同类型数据，但是对应的主键 id 必须保证统一性，不能重复；使用这个作为主键自增可以确保唯一性

redis用于控制数据库表主键id，为数据库表主键提供生成策略，保障数据库表的主键唯一性

2. Hash哈希散列列表（对应Java-HashMap）

存储需求：对一系列存储的数据进行编组，方便管理，典型应用存储对象信息
需要的存储结构：一个存储空间保存多个键值对数据
hash类型：底层使用哈希表结构实现数据存储
使用场景：电商网站购物车设计与实现；应用于抢购，限购类、限量发放优惠卷、激活码等业务的数据存储设计

hash类型下的value只能存储字符串，不允许存储其他数据类型，不存在嵌套现象。如果数据未获取到，对应值为null
每个hash可以存储2的32次方减1个键值对

在这里插入图片描述

3. List列表（对应Java-LinkedList）

数据存储需求：存储多个数据，并对数据进入存储空间的顺序进行区分
需要的存储结构：一个存储空间保存多个数据，且通过数据可以体现进入顺序
list类型：保存多个数据，底层使用双向链表存储结构实现
业务场景：朋友圈点赞，按照点赞顺序显示点赞好友信息；应用于具有操作先后顺序的数据控制

在这里插入图片描述

4. Set集合（对应Java-HashSet）

新的存储需求：存储大量的数据，在查询方面提供更高的效率
需要的存储结构：能够保存大量的数据，高效的内部存储机制，便于查询
set类型：与hash存储结构完全相同，仅存储键，不存储值（nil），并且值是不允许重复的
应用场景：应用于随机推荐类信息检索，例如热点歌单推荐，热点新闻推荐，热卖旅游线路，应用APP推荐，大V推荐等；应用于同类型数据的快速去重

在这里插入图片描述

5. SortedSet（对应Java-TreeSet）

新的存储需求：数据排序有利于数据的有效展示，需要提供一种可以根据自身特征进行排序的方式
需要的存储结构：新的存储模型，可以保存可排序的数据
sorted_set类型：在set的存储结构基础上添加可排序字段
应用场景：票选广东十大杰出青年，各类综艺选秀海选投票各类资源网站TOP10（电影，歌曲，文档，电商，游戏等）聊天室活跃度统计；为所有参与排名的资源建立排序依据

在这里插入图片描述

三、Redis持久化

什么是持久化：利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化

为什么要持久化：防止数据的意外丢失，确保数据安全性

1. 持久化方式

RDB: 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

AOF: 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

2. RDB

2.1 save指令工作原理-手动执行一次保存操作

在这里插入图片描述

2.2 bgsave指令工作原理-手动启动后台保存操作-但不是立即执行

在这里插入图片描述

2.3 save操作配置自动执行-原理

满足限定时间范围内key的变化数量达到指定数量即进行持久化

在这里插入图片描述

2.4 RDB的优点

RDB是一个紧凑压缩的二进制文件，存储效率较高

RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景

RDB恢复数据的速度要比AOF快很多

应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

2.5 RDB的缺点

RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据

bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

3. AOF

3.1 AOF的产生

RDB的弊端：

存储数据量较大，效率较低基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低；
大数据量下的IO性能较低
基于fork创建子进程，内存产生额外消耗
宕机带来的数据丢失风险

解决思路：

不写全数据，仅记录部分数据
降低区分数据是否改变的难度，改记录数据为记录操作过程
对所有操作均进行记录，排除丢失数据的风险

3.2 概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程

AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

3.2 AOF写数据原理

在这里插入图片描述

AOF写数据的三种策略：

always(每次）每次写入操作均同步到AOF文件中，数据零误差，性能较低，不建议使用。
everysec（每秒）每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高，建议使用，也是默认配置在系统突然宕机的情况下丢失1秒内的数据
no（系统控制）由操作系统控制每次同步到AOF文件的周期，整体过程不可控

3.2 AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写的作用：

降低磁盘占用量，提高磁盘利用率

提高持久化效率，降低持久化写时间，提高IO性能

降低数据恢复用时，提高数据恢复效率

AOF重写规则：

进程内已超时的数据不再写入文件

忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令

如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

对同一数据的多条写命令合并为一条命令

如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式： -手动重写/自动重写

3.3 AOF手动重写 —bgRewriteAof指令工作原理

在这里插入图片描述

3.4 AOF重写流程

在这里插入图片描述

4. RDB VS AOF

在这里插入图片描述

对数据非常敏感，建议使用默认的AOF持久化方案
- AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
- 注意：由于AOF文件存储体积较大，且恢复速度较慢
数据呈现阶段有效性，建议使用RDB持久化方案
- 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
- 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
综合对比
- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
- 灾难恢复选用RDB
- 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

四、Redis过期策略和内存淘汰机制

1. 数据删除策略

在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露

1.1 定时删除

创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作

优点：节约内存，到时就删除，快速释放掉不必要的内存占用
缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量
总结：用处理器性能换取存储空间（拿时间换空间）

1.2 惰性删除

数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据，发现已过期，删除，返回不存在

优点：节约CPU性能，发现必须删除的时候才删除
缺点：内存压力很大，出现长期占用内存的数据
总结：用存储空间换取处理器性能 expireIfNeeded() （拿时间换空间）

1.3 定期删除

周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度

特点1：CPU性能占用设置有峰值，检测频度可自定义设置
特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理
总结：周期性抽查存储空间 expireIfNeeded() （随机抽查，重点抽查）

1.4 对比

定时删除节约内存，无占用不分时段占用CPU资源，频度高拿时间换空间

惰性删除内存占用严重延时执行，CPU利用率高拿空间换时间

定期删除内存定期随机清理每秒花费固定的CPU资源维护内存随机抽查，重点抽查

内存淘汰机制

…

五、主从复制

1. 主从复制由来

单机redis的风险与问题

问题一：机器故障

由于硬盘故障系统崩溃导致的数据丢失，很有可能对业务造成灾难性打击

问题二：容量瓶颈

由于内存不足，硬件条件跟不上很容易达到容量瓶颈

解决：为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

在这里插入图片描述

2. 主从复制简介

主从复制即将master中的数据即时、有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责： master：写数据，执行写操作时，将出现变化的数据自动同步到

slave：读数据

3. 主从复制的作用

读写分离：master写、slave读，提高服务器的读写负载能力
负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

4. 主从复制工作流程

建立连接阶段（即准备阶段）

数据同步阶段

命令传播阶段

4.1 阶段一、建立链接阶段

建立slave到master的连接，使master能够识别slave，并保存slave端口号
在这里插入图片描述

slave断开连接后，不会删除已有数据，只是不再接受master发送的数据

4.2 阶段二、数据同步阶段

在slave初次连接master后，复制master中的所有数据到slave

将slave的数据库状态更新成master当前的数据库状态

在这里插入图片描述

数据同步阶段Master说明

如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态
master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

数据同步阶段Slave说明

为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令
多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果 master带宽不足，因此数据同步需要根据业务需求，适量错峰
slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟较大，数据一致性变差，应谨慎选择