JDBC的架构设计

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

  • JDBC要解决的问题
  • 数据库事务
  • JDBC的架构设计
  • JDBC代码注意点
  • Spring是如何处理事务
  • 什么是事务的传播特性
  • Redis事务与数据库事务的区别

问题

在《架构风格：万金油CS与分层》中提到，三层架构一般分为：

  • Presentation tier 表现层
  • Logic tier 业务逻辑层
  • Data access tier 数据访问层

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

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

  • 「业务逻辑层」是Client
  • 「数据访问层」是Server

CS风格的约束如下：

  • Server组件提供了一组服务,并监听对这些服务的请求（这里就是数据库服务），
  • Client组件通过一个连接器将请求发送到Server,希望执行一个服务（执行sql），
  • Server可以拒绝这个请求,也可以执行这个请求并将响应发送回Client（sql执行结果）。

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

  • 兼容各种数据库。不能每个数据库都有一套接口，这样会导致业务逻辑层与数据访问层的紧耦合。
  • 事务支持。需要支持数据库事务，否则数据会出现混乱。

设计

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

  • 连接组件：对与数据访问层的连接的抽象
  • 执行组件：执行对数据库的操作的抽象
  • 结果组件：对返回操作后的结果的抽象
  • 适配组件：适配各个数据库，就是对各个数据库的抽象

这就是JDBC的结构：

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查询的时候，都需要创建连接。我们都知道创建连接是个很耗时的操作，如何能降低创建连接的开销呢？

在《非功能性约束之性能（1）-性能银弹：缓存》中，已经给出答案了。就是引入「缓存」！

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

  • 先创建一批连接，一般是在应用启动时
  • 当需要连接的时候，直接从连接池中获取
  • 操作完了之后，将连接再还到连接池中

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

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

其实在《EDA风格与Reactor模式》里已经给出了答案：如果请求数据量太大或处理时间很长！即使是主从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：数据库隔离级别

事务总结

JDBC的架构设计

 

redis的事务

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

  • 开始事务「redis通过MULTI指令执行」
  • 输入需要执行的命令
  • 执行事务「redis通过EXEC指令执行」

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

总结

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

posted @ 2020-09-02 15:25  一瑜一琂  阅读(603)  评论(0)  编辑  收藏  举报