Redis基础总结

1.NoSQL

C:\Program Files\MySQL\MySQL Server 5.7\bin>mysql -uroot -p

redis-cli

1. 什么是NoSQL

• NoSQL = Not Only SQL

• 非关系型数据库

<!--more-->

2.为什么要用NoSQL

• 高并发读写

• 海量数据的高效率存储和访问

• 高可扩展性和高可用性

2.Redis（通讯组件Socket+基于RESP协议）

一个高性能的key-value数据库

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

• Redis支持数据的备份，即master-slave模式的数据备份。

1.支持的数据类型

1. String: 字符串类型

2. Hash：散列类型

3. List：列表类型

4. Set：集合类型

5. Sorted Set：有序集合类型

2.应用场景

1. 缓存

2. 任务队列

3. 网站访问统计

4. 数据过期处理

5. 应用排行榜

6. 分布式集群架构中的session分离

3.Redis持久化

1.RDB持久化：可以在指定的时间间隔内将内存中的数据集快照写入磁盘

2.AOF持久化：记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集

3.RDB结合AOF：在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整

4.不持久化：你甚至可以关闭持久化功能，让数据只在服务器运行时存在

4.RDB的优点

• RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

• RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

• RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

5.RDB的缺点

• 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

• 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

6.AOF的优点

• 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 同步策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。

• AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。

• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

7.AOF的缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

• AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

8.Redis的淘汰策略

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

4. allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

6. no-enviction（驱逐）：禁止驱逐数据

9.Redis使用会带来的问题

redis可以满足很多的应用场景，而且因为将所有数据都放到内存中，所以它的读写性能很好，很多公司都在使用redis。redis给我们带来便利的同时，使用过程中会存在什么问题呢

• redis使用了单线程来处理请求，为什么单线程可以支持如此高的并发呢？主要有如下几点：

  1. 纯内存访问：将所有数据都放到内存中,内存响应时间为100纳秒，是redis达到每秒万级别访问的重要基础

  2. 非阻塞IO：redis使用epoll作为I/O多路复用技术，redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多时间

  3. 单线程：避免了线程切换和竞态产生的消耗，简化了数据结构和算法的实现 因此如果某个命令执行时间过长，会造成其他命令阻塞，对redis来说是致命的

• 阻塞问题（产生场景）

  1.API或数据结构使用不合理

  1. 避免使用某些易造成阻塞的命令如：keys sort hgetall smembers

  2. 防止一次操作获取过多数据：缩减大对象或者把大对象拆分为多个小对象

  3. 防止大量key同时过期：如果有很多key在同一秒内过期，超过了所有key的25%，redis主线程就会阻塞直到过期key比例下降到25%以内，因此要避免同一时间过期大量key，过期时间可做散列处理

  2.cpu饱和

  1. 单线程的redis处理命令时只能使用一个CPU，CPU饱和是指redis把单核的CPU使用率跑到接近100%，首先要确定redis的并发量是否达到极限，通过redis-cli-h{ip} -p{port}--stat 获取redis当前使用情况。

     如果达到每秒6w+左右的qps，说明单台已跑到极限，需要水平扩展。

     如果qps只有几百或者几千CPU就已经饱和，可能使用了高算法复杂度的命令或者是对内存的过度优化

  3.持久化操作

  持久化引起主线程的阻塞操作主要有：fork阻塞、AOF刷盘阻塞、HugePage写操作阻塞

  1. fork阻塞：发生在RDB和AOF重写时，redis主线程调用fork操作产生共享内存的子线程，由子线程完成持久化文件的重写工作，若fork操作耗时过长会引起阻塞。

     避免使用内存过大的实例。

  2. AOF刷盘阻塞：开启AOF持久化功能时，一般会采用1次/s的刷盘方式，后台线程每秒对AOF文件做fsync操作，当硬盘压力过大时fsync操作需要等待直到写入完成。

     如果主线程距离上一次的fsync成功超过2s，为了数据安全会阻塞直到后台线程执行完fsync完成。这种阻塞是由于磁盘压力引起。

     尽量独立部署

  3. HugePage写操作阻塞：子进程在执行重写期间利用linux的copyonwrite机制，会拖慢写操作的执行时间，导致大量写操作慢查询。

     优化linux配置

• 缓存穿透

  缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不命中，且不将空结果写到缓存中。 会导致后端存储负载变大，造成后端存储宕机等问题。 产生原因：1.自身代码或数据出现问题 2.恶意攻击，爬虫造成空命中如何解决：

  1. 缓存空对象 存储层不命中，扔将空对象保存到缓存层。 适用场景：数据频繁变化、实时性高 带来问题： a.缓存了空值，会占用内存空间；可以设置较短过期时间，自动剔除。 b.数据不一致，若存储层添加了此数据，有短暂不一致；可主动清除掉缓存的空对象。

  2. 布隆过滤器 在访问缓存层和数据层之前将存在的key用布隆过滤器提前保存起来，做第一层拦截。 适用场景：大用户集，实时性要求较低的场景，如有几亿的数据集，每隔一段时间会新增用户进去，在更新之前新用户的访问会存在缓存穿透问题。 缺点：代码维护复杂