Skip to main content

Redis

什么是内存数据库(Redis)​

内存：游戏和广告技术应用程序具有排行榜、会话存储和实时分析等使用案例，它们需要微秒响应时间并且可能随时出现大规模的流量高峰。

Redis 使用简单的键值方法来存储数据。键值数据库将数据存储为键值对集合，其中键作为唯一标识符。键和值都可以是从简单对象到复杂复合对象的任何内容。键值数据库是高度可分区的，并且允许以其他类型的数据库无法实现的规模进行水平扩展。

redis 有哪些常用的数据类型？​

key-String（String 类型是 Redis 最基本的数据类型，一个 Redis 中字符串 value 最多可以是 512M）

list 是一个双向可读写的管道，其头部是左侧，尾部是右侧，一个列表最多可以包含 2^32-1 （4294967295）个元素，下标 0 表示列表的第一个元素，可以使用负数下标，元素值可以重复

Set 是 String 类型的无序集合，集合中的成员是唯一的，这就意味着集合中不能出现重复的数据，可以 在两个不同的集合中对数据进行对比并取值，常用于取值判断，统计，交集等场景

sorted set 有序集合，和集合一样也是 string 类型元素的集合,且不允许重复的成员，不同的是每个元素都会关 联一个 double(双精度浮点型)类型的分数， redis 正是通过该分数来为集合中的成员进行从小到大的排 序，有序集合的成员是唯一的,但分数(score)却可以重复，集合是通过哈希表实现的，所以添加，删 除，查找的复杂度都是 O(1)， 集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储 40 多亿个 成员)，经常用于排行榜的场景。每个元素是由 score 和 value 组成：score 可以重复，value 不可以重复

hash 是一个 string 类型的字段(field)和值(value)的映射表， Redis 中每个 hash 可以存储 2^32 -1 键值对，类似于字典，存放了多个 k/v 对， hash 特别适合用于存储对象场景

  • 哈希表，获取该表的全部数据和表中指定 key 的数据，分别对应的命令
# 获取所有哈希表中的字段
hkeys key
#获取在哈希表中指定 key 的所有字段和值
hgetall key

说几个你在项目中的Redis应用场景​

使用爬虫进行分任务爬取，对爬取到的文本、快照（截图）进行分任务保存。

  • 为什么要用 redis 来做？

redis 是基于内存存储计算，性能速读远超 mysql 等数据库，计算速度很快，所以在使用的时候数据响应很快。

持久化的存储方式有哪些？​

AOF（append only file） 持久化，采用日志的形式来记录每个写操作，追加到 AOF 文件的末尾。 RDB 持久化，是指在指定的时间间隔内，执行指定次数的写操作，将内存中的数据集快照写入磁盘中，它是 Redis 默认的持久化方式。执行完操作后，在指定目录下会生成一个 dump.rdb 文件，Redis 重启的时候，通过加载 dump.rdb 文件来恢复数据。

过期键的删除策略是怎样的？​

目前来说有三种删除策略：

  • 定时删除：在设置键的过期时间时，创建一个定时器，当到达键过期时间时通过定时器去删除键。 优点是：对内存友好。因为通过定时器，当一个键到达过期时间时就会立马被删除，直接就释放了内存。 缺点是：对 CPU 不友好。因为如果过期键比较多，那么删除这些过期键会占用相当一部分 CPU 时间，如果 CPU 时间非常紧张的话，还将 CPU 时间用在删除和当前任务无关的过期键上，会对服务器的响应时间以及吞吐量造成影响。

惰性删除：惰性删除并不是当到达过期时间时去删除，而是每次获取键时，会判断是否过期，如果过期则删除，并返回空；没过期，就返回键值。 优点：对 CPU 时间友好。程序只会在取出键时才会判断是否删除，并且只作用到当前键上，其他过期键不会花费 CPU 时间去处理。 缺点：对内存不友好。因为只有键被使用时才会去检查是否删除，如果有大量的键一直不被使用，那么这些键就算过期了也不会被删除，会一直占用着内存。这种可以理解为是一种内存泄漏——大量无用的数据一直占用着内存，并且不会被删除。

定期删除：每隔一段时间，就对数据库中的键进行检查，如果过期则删除。至于要删除多少什么时候删除，则是通过具体程序决定。 定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。 并且，通过定期删除过期键，有效的减少了过期键带来的内存浪费。 但删除的时长和频率比较难定义，因为：如果频率太高或者时长太长，那么会占用大量的 CPU 时长。如果过短又会出现内存浪费的情况。 因此。如果采用定期删除策略的话需要通过具体的业务场景来定义时长和频率。

Nosql是什么？​

NoSQL(Not only SQL)是对不同于传统的关系数据库的数据库管理系统的统称，即广义地来说可以把所有不是关系型数据库的数据库统称为 NoSQL。

NoSQL 数据库专门构建用于特定的数据模型，并且具有灵活的架构来构建现代应用程序。NoSQL 数据库使用各种数据模型来访问和管理数据。这些类型的数据库专门针对需要大数据量、低延迟和灵活数据模型的应用程序进行了优化，这是通过放宽其他数据库的某些数据一致性限制来实现的。

数十年来，用于应用程序开发的主要数据模型是由关系数据库（如 Oracle、DB2、SQL Server、MySQL 和 PostgreSQL）使用的关系数据模型。直到 21 世纪中后期，才开始大规模采用和使用其他数据模型。为了对这些新类别的数据库和数据模型进行区分和分类，创造了术语“NoSQL”。通常术语“NoSQL”与“非关系”可互换使用。

NoSQL 的 BASE 原则：Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定义。BASE 是 NoSQL 数据库通常对可用性及一致性的弱要求原则:

  • Basically Availble --基本可用
  • Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
  • Eventual Consistency -- 最终一致性， 也是是 ACID 的最终目的。

BASE 模型是传统 ACID 模型的反面，不同于 ACID，BASE 强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了.

MVCC​

MVCC 是多版本并发控制机制，顾名思义支持 MVCC 的数据库表中每一行数据都可能存在多个版本，对数据库的任何修改的提交都不会直接覆盖之前的数据，而是产生一个新的版本与老版本共存，通过读写数据时读不同的版本来避免加锁阻塞。

使用锁和锁协议来实现相应的隔离级别来进行并发控制会造成事务阻塞，导致并发性能会受到一定的影响。而多版本并发控制使得对同一行记录做读写的事务之间不用相互阻塞等待(写写还是要阻塞等待，因为事务对数据进行更新时会加上排他锁)，提高了事务的并发能力，可以认为 MVCC 是一种解决读写阻塞等待的行级锁。

MVCC 的重要特性: (1)MVCC 只支持 RC(读取已提交)和 RR(可重复读)隔离级别。 (2)MVCC 能解决脏读、不可重复读问题，不能解决丢失更新问题和幻读问题。 (3)MVCC 是用来解决读写操作之间的阻塞问题。使得在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。

innodb​

InnoDB 会为每个使用 InnoDB 存储引擎的表添加三个隐藏字段，用于实现数据多版本以及聚集索引，他们的作用如下:

  • DB_TRX_ID(6 字节)： 它是最近一次更新或者插入或者删除该行数据的事务 ID(若是删除，则该行有一个删除位更新为已删除。但并不是真正的进行物理删除，当 InnoDB 丢弃为删除而编写的更新撤消日志记录时，它才会物理删除相应的行及其索引记录。此删除操作称为清除，速度非常快)
  • DB_ROLL_PTR(7 字节)： 回滚指针，指向当前记录行的 undo log 信息(指向该数据的前一个版本数据)
  • DB_ROW_ID(6 字节)： 随着新行插入而单调递增的行 ID。InnoDB 使用聚集索引，数据存储是以聚集索引字段的大小顺序进行存储的，当表没有主键或唯一非空索引时，innodb 就会使用这个行 ID 自动产生聚簇索引。如果表有主键或唯一非空索引，聚簇索引就不会包含这个行 ID 了。这个 DB_ROW_ID 跟 MVCC 关系不大。

ORM​

对象关系映射（Object Relational Mapping，简称 ORM）模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。

简单的说，ORM 是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。

那么，到底如何实现持久化呢？一种简单的方案是采用硬编码方式，为每一种可能的数据库访问操作提供单独的方法。

优点​

与传统的数据库访问技术相比，ORM 有以下优点：

  • 开发效率更高
  • 数据访问更抽象、轻便
  • 支持面向对象封装

缺点​

  • 降低程序的执行效率
  • 思维固定化

从系统结构上来看,采用 ORM 的系统一般都是多层系统，系统的层次多了，效率就会降低。ORM 是一种完全的面向对象的做法，而面向对象的做法也会对性能产生一定的影响 N+1 问题

N+1 是 ORM（对象关系映射）关联数据读取中存在的一个问题。

假设现在有一个用户表（User）和一个余额表（Balance），这两个表通过 user_id 进行关联。现在有一个需求是查询年龄大于 18 岁的用户，以及用户各自的余额。

这个问题并不难，但对于新手而言，可能常常会犯的一个错误就是在循环中进行查询。

$users = User::where("age", ">", 18)->select();
foreach($users as $user){
  $balance = User::getFieldByUserId($user->user_id, "balance");
  $user['balance'] = $balance;
}

通过 Mysql 查询日志，可以看到查询用户表是一次，因为有四个符合该条件的用户，查询用户表关联的余额表是四次。

N+1 问题就是这样产生的：查询主表是一次，查询出 N 条记录，根据这 N 条记录，查询关联的副（从）表，共需要 N 次。所以，应该叫 1+N 问题更合适一些。

其实，如果稍微了解一点 SQL，根本不用这么麻烦，直接使用 IN 一次就搞定了。

对于这类问题，ORM 其实为我们提供了相应的方案，那就是使用『预加载功能』。

使用 with()方法指定想要预加载的关联：

$users = User::where("age", ">", 18)
        ->with("hasBalance")
        ->select();

hasBalance 这个方法让 User 模型与 Balance 模型进行一对一关联，总查询次数由原来的 1+N 变成了现在的 1+1。

Transaction​

事务（Transaction）是一个对数据库执行工作单元。

事务（Transaction）是以逻辑顺序完成的工作单位或序列，可以是由用户手动操作完成，也可以是由某种数据库程序自动完成。

事务（Transaction）是指一个或多个更改数据库的扩展。例如，如果您正在创建一个记录或者更新一个记录或者从表中删除一个记录，那么您正在该表上执行事务。重要的是要控制事务以确保数据的完整性和处理数据库错误。实际上，您可以把许多的 SQLite 查询联合成一组，把所有这些放在一起作为事务的一部分进行执行。

ACID​

事务（Transaction）具有以下四个标准属性，通常根据首字母缩写为 ACID：

  • 原子性（Atomicity）：确保工作单位内的所有操作都成功完成，否则，事务会在出现故障时终止，之前的操作也会回滚到以前的状态。
  • 一致性（Consistency)：确保数据库在成功提交的事务上正确地改变状态。
  • 隔离性（Isolation）：使事务操作相互独立和透明。
  • 持久性（Durability）：确保已提交事务的结果或效果在系统发生故障的情况下仍然存在。

四个特性（ACID），其中原子性是如何实现的？​

从 redolog 的角度​

规定在执行这些需要保证原子性的操作时必须以组的形式来记录的 redo 日志，在进行系统崩溃重启恢复时，针对某个组中的 redo 日志，要么把全部的日志都恢复掉，要么一条也不恢复。在该组中的最后一条 redo 日志后边加上一条特殊类型的 redo 日志，该类型名称为 MLOG_MULTI_REC_END，type 字段对应的十进制数字为 31，该类型的 redo 日志结构很简单，只有一个 type 字段。所以某个需要保证原子性的操作产生的一系列 redo 日志必须要以一个类型为 MLOG_MULTI_REC_END 结尾。

从 undolog 的角度​

InnoDB 存储引擎在实际进行增、删、改一条记录时，都需要先把对应的 undo 日志记下来。一般每对一条记录做一次改动，也可能会对应着 2 条 undo 日志：（每对一条记录的主键值做改动时，会记录 2 条 undo 日志，因为会有对该记录进行 delete mark 操作前，会记录一条类型为TRX_UNDO_DEL_MARK_REC的 undo 日志；之后插入新记录时，会记录一条类型为TRX_UNDO_INSERT_REC的 undo 日志）

一次事务如果有很多 undolog，会进行编号，比如 undolog 1， 2， 3 就是 undo no

当我们向某个表中插入一条记录时，实际上需要向聚簇索引和所有的二级索引都插入一条记录。不过记录 undo 日志时，我们只需要考虑向聚簇索引插入记录时的情况就好了，因为其实聚簇索引记录和二级索引记录是一一对应的，我们在回滚插入操作时，只需要知道这条记录的主键信息，然后根据主键信息做对应的删除操作，做删除操作时就会顺带着把所有二级索引中相应的记录也删除掉。

事务的隔离级别​

在实际应用中，数据库中的数据是要被多个用户共同访问的，在多个用户同时操作相同的数据时，可能就会出现一些事务的并发问题，具体如下。

  • 脏读 指一个事务读取到另一个事务未提交的数据。
  • 不可重复读 指一个事务对同一行数据重复读取两次，但得到的结果不同。
  • 虚读/幻读 指一个事务执行两次查询，但第二次查询的结果包含了第一次查询中未出现的数据。
  • 丢失更新 指两个事务同时更新一行数据，后提交（或撤销）的事务将之前事务提交的数据覆盖了。

丢失更新可分为两类，分别是第一类丢失更新和第二类丢失更新。

  • 第一类丢失更新是指两个事务同时操作同一个数据时，当第一个事务撤销时，把已经提交的第二个事务的更新数据覆盖了，第二个事务就造成了数据丢失。
  • 第二类丢失更新是指当两个事务同时操作同一个数据时，第一个事务将修改结果成功提交后，对第二个事务已经提交的修改结果进行了覆盖，对第二个事务造成了数据丢失。

为了避免上述事务并发问题的出现，在标准的 SQL 规范中定义了四种事务隔离级别，不同的隔离级别对事务的处理有所不同。这四种事务的隔离级别如下。

  • Read Uncommitted（读未提交） 一个事务在执行过程中，既可以访问其他事务未提交的新插入的数据，又可以访问未提交的修改数据。如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据。此隔离级别可防止丢失更新。
  • Read Committed（读已提交） 一个事务在执行过程中，既可以访问其他事务成功提交的新插入的数据，又可以访问成功修改的数据。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。此隔离级别可有效防止脏读。
  • Repeatable Read（可重复读取） 一个事务在执行过程中，可以访问其他事务成功提交的新插入的数据，但不可以访问成功修改的数据。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。此隔离级别可有效防止不可重复读和脏读。
  • Serializable（可串行化） 提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。此隔离级别可有效防止脏读、不可重复读和幻读。但这个级别可能导致大量的超时现象和锁竞争，在实际应用中很少使用。

一般来说，事务的隔离级别越高，越能保证数据库的完整性和一致性，但相对来说，隔离级别越高，对并发性能的影响也越大。因此，通常将数据库的隔离级别设置为 Read Committed，即读已提交数据，它既能防止脏读，又能有较好的并发性能。虽然这种隔离级别会导致不可重复读、幻读和第二类丢失更新这些并发问题，但可通过在应用程序中采用悲观锁和乐观锁加以控制。

事务控制​

使用下面的命令来控制事务：

  • BEGIN TRANSACTION：开始事务处理。
  • COMMIT：保存更改，或者可以使用 END TRANSACTION 命令。
  • ROLLBACK：回滚所做的更改。

事务控制命令只与 DML 命令 INSERT、UPDATE 和 DELETE 一起使用。他们不能在创建表或删除表时使用，因为这些操作在数据库中是自动提交的。

什么是脏读？什么是幻读？​

脏读 ：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

幻读 : 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。例如，一个编辑人员更改作者提交的文档，但当生产部门将其更改内容合并到该文档的主复本时，发现作者已将未编辑的新材料添加到该文档中。 如果在编辑人员和生产部门完成对原始文档的处理之前，任何人都不能将新材料添加到文档中，则可以避免该问题。

mysql 的默认隔离级别是？能解决脏读和幻读吗？​

mysql 的默认隔离级别是可重复读，也有企业生产环境是读已提交​

读未提交(Read UnCommitted)，简称为 RU； 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

读已提交(Read Commited)，简称为 RC； 允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。

可重复读(Repeatable Read)，简称为 RR；对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。

串行化(Serializable)最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

如何解决幻读？​

MVCC 加上间隙锁的方式 （1）在快照读读情况下，mysql 通过 mvcc 来避免幻读。 （2）在当前读读情况下，mysql 通过 next-key 来避免幻读。锁住某个条件下的数据不能更改。

索引的底层实现？​

相较于 B 树，B+树的优势是什么？​

1.单一节点存储更多的元素，使得查询的 IO 次数更少；

2.所有查询都要查找到叶子节点，查询性能稳定；

3.所有叶子节点形成有序链表，便于范围查询。

首先，Ｂ＋树的查找和Ｂ树一样，类似于二叉查找树。起始于根节点，自顶向下遍历树，选择其分离值在要查找值的任意一边的子指针。在节点内部典型的使用是二分查找来确定这个位置。

不同的是，Ｂ＋树中间节点没有卫星数据（索引元素所指向的数据记录），只有索引，而Ｂ树每个结点中的每个关键字都有卫星数据；这就意味着同样的大小的磁盘页可以容纳更多节点元素，在相同的数据量下，Ｂ＋树更加“矮胖”，ＩＯ操作更少。

其次，因为卫星数据的不同，导致查询过程也不同；Ｂ树的查找只需找到匹配元素即可，最好情况下查找到根节点，最坏情况下查找到叶子结点，所说性能很不稳定，而Ｂ＋树每次必须查找到叶子结点，性能稳定。

在范围查询方面，B+树的优势更加明显：B 树的范围查找需要不断依赖中序遍历。首先二分查找到范围下限，在不断通过中序遍历，知道查找到范围的上限即可。整个过程比较耗时。而 B+树的范围查找则简单了许多。首先通过二分查找，找到范围下限，然后同过叶子结点的链表顺序遍历，直至找到上限即可，整个过程简单许多，效率也比较高。