JDBC的架构设计

Posted 2021-04-10 正经地扯淡

本文探讨JDBC需要解决的问题及如何解决和设计的，包括：

• JDBC要解决的问题

• 数据库事务

• JDBC的架构设计

• JDBC代码注意点

• Spring是如何处理事务

• 什么是事务的传播特性

• Redis事务与数据库事务的区别

问题

在《》中提到，三层架构一般分为：

• Presentation tier 表现层

• Logic tier 业务逻辑层

• Data access tier 数据访问层

那业务逻辑层与数据访问层是如何通信的呢？（假设数据访问层使用的是数据库进行数据持久化，这也是目前比较普遍的做法）

单看「业务逻辑层」和「数据访问层」，这是明显的CS风格：

• 「业务逻辑层」是Client

• 「数据访问层」是Server

CS风格的约束如下：

• Server组件提供了一组服务,并监听对这些服务的请求（这里就是数据库服务），

• Client组件通过一个连接器将请求发送到Server,希望执行一个服务（执行sql），

• Server可以拒绝这个请求,也可以执行这个请求并将响应发送回Client（sql执行结果）。

除了上面的约束外，针对数据库访问而言，还应该包括如下约束：

• 兼容各种数据库。不能每个数据库都有一套接口，这样会导致业务逻辑层与数据访问层的紧耦合。

• 事务支持。需要支持数据库事务，否则数据会出现混乱。

设计

针对上面的约束，可以抽象出四个组件：

• 连接组件：对与数据访问层的连接的抽象

• 执行组件：执行对数据库的操作的抽象

• 结果组件：对返回操作后的结果的抽象

• 适配组件：适配各个数据库，就是对各个数据库的抽象

这就是JDBC的结构：

• Connection：连接组件。提供统一的API建立数据库连接。

• Statement：执行组件。针对各种执行有不同的实现，Statement，PreparedStatement,CallableStatement。提供统一的API执行sql。

• ResultSet：结果组件，对结果的抽象，提供统一的API操作结果数据。

• Driver：适配组件，对各个不同的数据库操作进行适配，统一为一套对外一致的API。各个Driver统一由DriverManager进行管理。

基于上面的设计，也就统一了JDBC操作数据库的流程：

• 注册驱动

• 建立连接

• 创建执行对象

• 执行语句

• 处理结果

• 释放资源

如果你google一下JDBC代码，一般会得到类似下面的代码：

 // 1.注册驱动
Class.forName("com.mysql.jdbc.Driver"); // 这一行代码实际早就不需要了！！！
// 2.建立连接
Connection conn = DriverManager.getConnection(url, user, password);
// 3.创建执行对象
Statement st = conn.createStatement();
// 4.执行语句
ResultSet rs = st.executeQuery("select * from table1");
// 5.处理结果while (rs.next()) {
 ......
}
// 6.释放资源
rs.close();
st.close();
conn.close();

实际上，早就已经不需要第一步「注册驱动」的代码了！在google第一页的十条结果中，只有一条结果提到了此问题！

你可以尝试一下，将第一行代码注释掉，程序还是能正常的执行。原因就是现在的JDBC驱动一般都使用了SPI来自动的注册驱动了，不再需要手动的去注册了。

SPI你可以认为是Java原生提供的的依赖注入！以mysql的驱动为例：

• 在mysql的驱动包META-INF目录下，有一个services目录

• 里面有个文件，叫java.sql.Driver。里面的内容为

• com.mysql.jdbc.Driver

• com.mysql.fabric.jdbc.FabricMySQLDriver

• 名称是接口，文件里的内容是实现

• JVM会根据上面的配置，去找对应的类，并把它加载进去

• DriverManager通过ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);这行代码加载驱动，将其加到驱动列表中进行管理。实现注册驱动的逻辑

性能优化

从上面的代码可以看到，每次进行sql查询的时候，都需要创建连接。我们都知道创建连接是个很耗时的操作，如何能降低创建连接的开销呢？

在《》中，已经给出答案了。就是引入「缓存」！

这里的「缓存」就是连接池！即：

• 先创建一批连接，一般是在应用启动时

• 当需要连接的时候，直接从连接池中获取

• 操作完了之后，将连接再还到连接池中

如果你了解IO多路复用或EDA架构风格，那么你可能会有个疑问。为什么数据库连接不使用IO多路复用技术呢？

IO多路复用或EDA架构风格可以参考《》！

其实在《》里已经给出了答案：如果请求数据量太大或处理时间很长！即使是主从Reactor模型，线程池也会被耗尽！耗尽后，导致后续的请求积压。

关系数据库的底层原理决定了其性能瓶颈在于磁盘读写，也就是说如果使用IO多路复用，瓶颈会出现在执行线程（数据库查询的磁盘操作），而不在IO通信。使用IO多路复用并不会提高数据库的访问，而且编程模型要复杂得多。

而redis能使用IO多路复用的原因是它主要是内存操作，速度要比磁盘操作快得多，瓶颈更可能出在IO通信上。

什么是事务

JDBC相关的另一个大的主题就是事务！

满足ACID四个特性的数据库操作，称为数据库事务

这里的事务指数据库本地事务,不包括分布式事务，分布式事务后续讨论！

四个特性包括：

• 原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行

• 一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束

• 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行

• 持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中

其中，隔离性又分为四种隔离级别，隔离级别从严格到宽松依次为：

• 可串行性（Serializability）：所有的事务依次逐个执行。这是最严格的的隔离级别，实际就是对事务进行排队，一个一个的执行，保证了每个事务的独立性，但是严重的影响了性能。如果有一个事务的执行耗时很长，那么后面的事务就全部等待。此隔离级别基本不会使用。

• 可重复读取（Repeatable Read）：一个事务在整个过程中可以多次重复执行某个查询。相对宽松的隔离级别，即在一个事务中某个查询，多次执行时，所得到的数据内容是一样的，但是得到的数据条数不一定是一样的，即所谓的幻读。

• 已提交读（Read Committed）：一个事务只能读取另一个事务已经提交的数据。更宽松的隔离级别，此隔离级别可能引起幻读和不可重复读。这是大部分数据库的默认隔离级别。

• 未提交读（Read Uncommitted）：一个事务可以读取另一个事务修改但还没有提交的数据。最宽松的隔离级别，此隔离级别可能引起幻读，不可重复读，脏读。

---

• 幻读（行）：一个事务中多次读取，取到另外一个事务已经提交的新增数据(表级)

• 不可重复读：多次读取同一个数据返回结果有所不同(行级)

• 脏读：一个事务读取到另外一个事务未提交的更新的数据（行级）

事务在代码中的体现就是conn.setAutoCommit(false),conn.commit(),conn.rollback()：

......
// 2.建立连接
Connection conn = DriverManager.getConnection(url, user, password);
// 关闭自动提交，开启事务
conn.setAutoCommit(false);
Statement st = conn.createStatement();
try {
 ResultSet rs = st.executeQuery("select * from table1");
 // 提交事务
 conn.commit();
} catch(Exception e) {
 conn.rollback(); // 出现异常进行事务回滚
}
......

Spring中的事务

Spring通过Transactional注解来简化了事务的管理。

Transactional对事务的处理流程如下：

• 开启事务

• 将conn对象保存到ThreadLocal中

• 执行sql。「这里就是你写代码的地方」

• 从ThreadLocal中取回conn对象

• 提交事务

Transactional的属性包括：

• isolation：配置事务的隔离级别

• readOnly：配置只读。默认false。需要事务才能生效

• rollbackFor：配置事务回滚。默认在遇到RuntimeException时进行回滚

• propagation：配置事务的传播特性

事务的传播特性：

• propagation=Propagation.NOT_SUPPORTED：针对某个方法不开启事务

• propagation=Propagation.REQUIRED：如果有事务，那么加入事务，没有的话新创建一个, 默认的事务支持

• propagation=Propagation.REQUIREDS_NEW：不管是否存在事务，都创建一个新的事务，原来的挂起，新的执行完毕，继续执行老的事务

• propagation=Propagation.MANDATORY：必须在一个已有的事务中执行，否则抛出异常

• propagation=Propagation.NEVER：不能在一个事务中执行，就是当前必须没有事务，否则抛出异常

• propagation=Propagation.SUPPORTS：其他bean调用这个方法，如果在其他bean中声明了事务，就是用事务。没有声明，就不用事务。

• propagation=Propagation.NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中，如果没有活动的事务，则按照REQUIRED属性执行，它使用一个单独的事务

• propagation=Propagation.REQUIRED,readOnly=true：只读，不能更新，删除

• propagation=Propagation.REQUIRED,timeout=30：超时30秒

• propagation=Propagation.REQUIRED,isolation=Isolation.DEFAULT：数据库隔离级别

事务总结

redis的事务

从表面看redis事务和jdbc事务很类似，都是下面的流程：

• 开始事务「redis通过MULTI指令执行」

• 输入需要执行的命令

• 执行事务「redis通过EXEC指令执行」

实际上有本质的区别。redis的事务实际上就是指令的批量执行，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

总结

本文通过业务逻辑层与数据持久层的通信约束，来阐述JDBC的设计及总结本地事务的相关知识点，同时与redis做了一个简单的比较。