1. MySQL 事务有哪些隔离级别、分别有什么特点，以及 MySQL 的默认隔离级别是什么？

在MySQL中事务的隔离级别是为了解决常见的并发问题，在保证数据库性能的同时保持事务的隔离性，常见的并发问题有：

1. 脏读：如果一个事务读到了另一个未提交事务修改过的数据，那就意味着发生了脏读(Dirty Read)。

2. 不可重复读：如果一个事务只能读到另一个已经提交的事务修改过的数据，并且其他事务每对该数据进行一次修改并提交后，该事务都能查询得到最新值，那就意味着发生了不可重复读(Non-Repeatable Read);

1. 幻读：如果一个事务先根据某些条件查询出一些记录，之后另一个事务又向表中插入了符合这些条件的记录，原先的事务再次按照该条件查询时，能把另一个事务插入的记录也读出来，那就意味着发生了幻读(Phantom reading)。

三个并发问题的区别如下：

• 脏读的重点在于未提交。脏读应该是三个里面最好理解的，其定义很轻易便能理解，一个事务中读取了另外一个事务未提交的数据，是先修改再读；

• 不可重复读的重点在于对单条数据读取了两遍。T1先读取了一遍，而后T2修改该数据并提交，最后T1再次读取了该数据发现与之前的不同；

• 幻读的重点在于针对一类条件对一系列数据读取了两遍。比较特殊的点在于幻读是具备条件的查询，这种查询可能查出来的并不只有一条数据，而在两次查询过程中另外一个事务对查询的结果集中的某条数据进行了变动。 针对于上述的并发问题，在SQL标准中设立了以下4个隔离级别：

  • READ UNCOMMITTED：未提交读。所有事务都可以看到其他未提交事务的执行结果；

  • READ COMMITTED：已提交读。一个事务只能看见已经提交事务所做的改变；

  • REPEATABLE READ：可重复读。确保了同一事务的多个实例在并发读取数据时，会看到同样的数据行；

  • SERIALIZABLE：可串行化。强制事务串行，并发效率很低。

下面表格展示了在SQL标准中规定的并发事务执行过程中可能发生的现象，其中✔️代表可能发生现象，❌代表不可能发生现象：

不同的数据库厂商对SQL标准中规定的4中隔离级别的支持是不一样的。其中MySQL的默认隔离级别为REPEATABLE READ，即可重复读在该隔离级别下可以很大程度上禁止了幻读现象的发生。

2. 讲一下 Redis 的单线程模型，IO 多路复用是什么？(Redis为什么快？)

在Redis 6.0以前，Redis的核心网络模型选择用单线程来实现。

对于一个 DB 来说，CPU 通常不会是瓶颈，因为大多数请求不会是 CPU 密集型的，而是 I/O 密集型。具体到 Redis的话，如果不考虑 RDB/AOF 等持久化方案，Redis是完全的纯内存操作，执行速度是非常快的，因此这部分操作通常不会是性能瓶颈，Redis真正的性能瓶颈在于网络 I/O，也就是客户端和服务端之间的网络传输延迟，因此 Redis选择了单线程的 I/O 多路复用来实现它的核心网络模型。

实际上更加具体的选择单线程的原因如下：

• 避免过多的上下文切换开销：如果是单线程则可以规避进程内频繁的线程切换开销，因为程序始终运行在进程中单个线程内，没有多线程切换的场景。

• 避免同步机制的开销：如果 Redis选择多线程模型，又因为 Redis是一个数据库，那么势必涉及到底层数据同步的问题，则必然会引入某些同步机制，比如锁，而我们知道 Redis不仅仅提供了简单的 key-value 数据结构，还有 list、set 和 hash 等等其他丰富的数据结构，而不同的数据结构对同步访问的加锁粒度又不尽相同，可能会导致在操作数据过程中带来很多加锁解锁的开销，增加程序复杂度的同时还会降低性能。

• 简单可维护：如果 Redis使用多线程模式，那么所有的底层数据结构都必须实现成线程安全的，这无疑又使得 Redis的实现变得更加复杂。

总而言之，Redis选择单线程可以说是多方博弈之后的一种权衡：在保证足够的性能表现之下，使用单线程保持代码的简单和可维护性。

IO多路复用

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用如下场合：

• 当客户处理多个描述字时（一般是交互式输入和网络套接口），必须使用I/O复用。

• 当一个客户同时处理多个套接口时，而这种情况是可能的，但很少出现。

• 如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用。

• 如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用。

• 如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用。

与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减小了系统的开销。

3. 什么是 BIO、NIO、AIO？

BIO、NIO、AIO都是Java中网络编程的I/O模型。

BIO（Blocking IO ）是JDK1.4之前的传统IO模型，特点就是同步阻塞等待数据，直到数据读取完毕才会返回结果，线程会一直阻塞在read/write 方法上，不能处理其他的IO请求，它的并发性能比较差。

NIO（Non-Blocking IO）是Java 1.4之后新增的IO模型，它支持同步非阻塞式的IO操作。NIO采用了多路复用器来处理IO请求，通过一个线程处理多个IO请求，实现了高并发处理。NIO主要有三个核心概念：Selector、Channel、Buffer。Selector负责监听多个Channel上的事件，Channel可以理解为对原始IO的封装，Buffer则是对数据的封装。

AIO（Asynchronous IO）是Java 1.7之后新增的IO模型，它支持异步非阻塞IO操作。与NIO不同的是，AIO在进行读写操作时不需要像NIO一样一直轮询，而是通过回调函数的方式在数据准备好后通知应用程序进行数据的读取，这样可以更加高效地利用系统资源，提高吞吐量。但是AIO在处理小文件和小数据量时的性能并不如NIO。

三者区别

BIO 同步阻塞IO，即打算约女神，给女神发短信后，没见到女神就一直等在宿舍楼下。

NIO 同步非阻塞IO，即打算约女神，给女神发短信后，没见到女神就一直发短信。

NIO java中的NIO，就是打算约女神，你让宿管大妈去挨个看每一个下楼的妹子，女神下楼了大妈就通知你。

AIO 就是打算约女神，你发完短信，你就去玩游戏了，女神下楼了，发短信给你，你才出现。