Redis笔记

关系型数据库的问题

1.性能瓶颈：磁盘IO性能低下

关系型数据库菜存取数据的时候和读取数据的时候他要走磁盘IO。磁盘这个性能本身是比较低的。

2.扩展瓶颈：数据关系复杂，扩展性差，不便于大规模集群

我们说关系型数据库，它里面表与表之间的关系非常复杂，不知道大家能不能想象一点，就是一张表，通过它的外键关联了七八张表，这七八张表又通过她的外件，每张又关联了四五张表。你想想，查询一下，你要想拿到数据，你就要从A到B、B到C、C到D的一直这么关联下去，最终非常影响查询的效率。同时，你想扩展下，也很难!

解决思路

面对这样的现象，我们要想解决怎么版呢。两方面：

一，降低磁盘IO次数，越低越好。

二，去除数据间关系，越简单越好。

降低磁盘IO次数，越低越好，怎么搞？我不用你磁盘不就行了吗？于是，内存存储的思想就提出来了，我数据不放到你磁盘里边，放内存里，这样是不是效率就高了。

第二，你的数据关系很复杂，那怎么办呢？干脆简单点，我断开你的关系，我不存关系了，我只存数据，这样不就没这事了吗？

把这两个特征一合并一起，就出来了一个新的概念：NoSQL

NoSQL的概念

（1）概念

NoSQL：即 Not-Only SQL（不仅仅是SQL 泛指非关系型的数据库），作为关系型数据库的补充。 作用：应对基于海量用户和海量数据前提下的数据处理问题。

（2）特征

1可扩容，可伸缩。SQL数据关系过于复杂，你扩容一下难度很高，那我们Nosql 这种的，不存关系，所以它的扩容就简单一些。

2大数据量下高性能。包数据非常多的时候，它的性能高，因为你不走磁盘IO，你走的是内存，性能肯定要比磁盘IO的性能快一些。

3灵活的数据模型、高可用。他设计了自己的一些数据存储格式，这样能保证效率上来说是比较高的，最后一个高可用，我们等到集群内部分再去它！

（3）应用场景（热点信息）

我们以电商为例，来看一看他在这里边起到的作用。

第一类，在电商中我们的基础数据一定要存储起来，比如说商品名称，价格，生产厂商，这些都属于基础数据，这些数据放在MySQL数据库。

第二类，我们商品的附加信息，比如说，你买了一个商品评价了一下，这个评价它不属于商品本身。就像你买一个苹果，“这个苹果很好吃”就是评论，但是你能说很好吃是这个商品的属性嘛？不能这么说，那只是一个人对他的评论而已。这一类数据呢，我们放在另外一个地方，我们放到MongoDB。它也可以用来加快我们的访问，他属于NoSQL的一种。

第三，图片内的信息。注意这种信息相对来说比较固定，他有专用的存储区，我们一般用文件系统来存储。至于是不是分布式，要看你的系统的一个整个 瓶颈 了？如果说你发现你需要做分布式，那就做，不需要的话，一台主机就搞定了。

第四，搜索关键字。为了加快搜索，我们会用到一些技术，有些人可能了解过，像分ES、Lucene、solr都属于搜索技术。那说的这么热闹，我们的电商解决方案中还没出现我们的redis啊！注意第五类信息。

第五，热点信息。访问频度比较高的信息，这种东西的第二特征就是它具有波段性。换句话说他不是稳定的，它具有一个时效性的。那么这类信息放哪儿了，放到我们的redis这个解决方案中来进行存储。

Redis特征：

（1）数据间没有必然的关联关系；

（2）内部采用单线程机制进行工作；

（3）高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。

（4）多数据类型支持

String ，List ，Hash，Set，Zset（用的比较少）

（5）支持持久化，可以进行数据灾难恢复

redis的应用场景

（1）为热点数据加速查询（主要场景）。如热点商品、热点新闻、热点资讯、推广类等高访问量信息等。

（2）即时信息查询。如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等。

（3）时效性信息控制。如验证码控制、投票控制等。

（4）分布式数据共享。如分布式集群架构中的 session 分离 消息队列.

五种数据类型

数据类型指的是存储的数据的类型，也就是 value 部分的类型，key 部分永远都是字符串。

持久化

两种持久化方式

1.我们知道一点，计算机中的数据全部都是二进制，如果现在我要你给我保存一组数据的话，你有什么样的方式呢，其实最简单的就是现在长什么样，我就记下来就行了，那么这种是记录纯粹的数据，也叫做快照存储，也就是它保存的是某一时刻的数据状态。

2.还有一种形式，它记录你所有的操作过程，比如说大家用idea的时候，有没有遇到过写错了ctrl+z撤销，然后ctrl+y还能恢复，这个地方它是在记录你所有的操作过程，操作过程，都给你留下来了，数据肯定不会丢。这种保存操作过程的存储，用专业术语来说可以说是日志。

总结一下：

第一种：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。

第二种：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。

 

RDB

1.save指令

手动执行一次保存操作

save指令相关配置

设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

由于Redis单线程，当cpu执行的时候会阻塞redis服务器，直到他执行完毕，所以说我们不建议大家用save指令。

2. bgsave指令

之前我们讲到了当save指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理？

此时我们可以使用：bgsave指令，bg其实是background的意思，后台执行的意思

手动启动后台保存操作，但不是立即执行

当执行bgsave的时候，客户端发出bgsave指令给到redis服务器。注意，这个时候服务器马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用Linux的fork函数创建一个子进程，让这个子进程去执行save相关的操作。

他才是主流方案。子进程开始执行之后，它就会创建啊RDB文件把它存起来，操作完以后他会把这个结果返回，也就是说bgsave的过程分成两个过程，第一个是服务端拿到指令直接告诉客户端开始执行了；另外一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息。

3 save配置自动执行

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化（使用bgsave）

save second changes

参数： second（监控时间范围）， changes（监控key的变化量）

范例：

save 900 1
save 300 10
save 60 10000

RDB特殊启动形式

服务器运行过程中重启

debug reload

关闭服务器时指定保存数据

shutdown save

全量复制（在主从复制中详细讲解）

 

RDB优点：

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

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

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

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

RDB缺点：

• 两个时间点之间，具有较大的可能性丢失数据

• 数据量较大时，效率低下

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

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

AOF

因为RDB有许多缺点，所以又有了AOF

AOF概念

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

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

启动AOF相关配置

开启AOF持久化功能，默认no，即不开启状态

appendonly yes

AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF写数据策略，默认为everysec（每秒）

appendfsync always|everysec|no

AOF重写

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

AOF重写作用

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

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

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

AOF重写规则

• 进程内具有时效性的数据，并且数据已超时将不再写入文件

• 非写入类的无效指令将被忽略，只保留最终数据的写入命令

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

  如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录

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

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

AOF重写方式

• 手动重写

bgrewriteaof

• 自动重写

auto-aof-rewrite-min-size size  （内存大小）
auto-aof-rewrite-percentage percentage  （内存百分比）

 

RDB与AOF区别

RDB与AOF对比（优缺点）

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢（每次存所以）	快（每次存部分）
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高

5.4.2 RDB与AOF应用场景

RDB与AOF的选择之惑

• 对数据非常敏感，建议使用默认的AOF持久化方案

AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。

注意：由于AOF文件存储体积较大，且恢复速度较慢

• 数据呈现阶段有效性，建议使用RDB持久化方案

数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案

灾难恢复选用RDB

注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：

• 同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量