【Java】Flyway数据库管理工具的基本原理

最近实习做的几个项目都用到了Flyway来做数据库的版本管理，顺便了解了下基本原理，做个记录。
详细的使用就不写了，网上教程很多。

1. 工作流程

在一个空数据库上部署集成了Flyway的应用：

1. 因为数据库是空的，Flyway会先创建这个数据库。

2. Flyway在数据库中创建一张表flyway_schema_histor，用于记录migration的执行情况（跟踪数据库状态）。

3. Flyway扫描migration脚本，并按版本号顺序执行。

   • 默认的查找 migration 的路径为 classpath:db/migration：
     • 对应 SQL 文件可放置在src/main/resources/db/migration 下；
     • Java 类可放置在 src/main/java/db/migration 下。
       

4. 变更数据库只需创建一个版本号更高的新migration脚本，下次启动项目时flyway会自动按版本号顺序执行版本号大于flyway_schema_histor表中版本号的脚本

2. 版本号校验算法

flyway在升级数据库时会计算之前已经升级过的脚本的checkSum（CRC32算法，循环冗余校验码），与数据库的checkSum进行对比。

老脚本如果内容发生变化，checkSum校验失败（所以一般老版本的脚本不能修改），抛出异常

注意，文件中版本号后面要隔两个下划线！文件中版本号后面要隔两个下划线！文件中版本号后面要隔两个下划线！比如上图中V1.5.20240627_modify_size.sql文件中，版本号后面只隔了一条下划线，所以这个脚本一直不执行，折腾了好久才发现。。。

3. 锁机制

3.1 为什么数据库管理工具需要锁

上面进行数据库版本更新的changset只需，也只能执行一次。如果我们部署了多个服务实例，就需要锁机制来保证这个changset不会被重复执行。

其实就是分布式锁的经典场景，比如部署了两个service实例，那么肯定需要保证他们互斥访问数据库，也要互斥地管理数据库，Flyway来说就是互斥地执行新脚本，也就是互斥地访问更改flyway_schema_histor表

3.2 flyway的锁机制

flyway作为数据库相关的工具，采用的分布式锁的实现方案是基于数据库实现的。

基于数据库实现分布式锁一般有两种：

• 基于数据库表：比如Liquibase维护了一张databasechangeloglock表来实现分布式锁。

  • 这样有个缺点就是一个service获取锁后还没释放就宕机了，其锁记录一直在DB中，其他线程就无法获取锁。需要手动清理脏锁。

• 基于数据库排他锁：flyway，直接for update

  @Override
  protected void doLock() throws SQLException {
  		jdbcTemplate.execute("SELECT * FROM " + this + " FOR UPDATE");
  }
  

  • 如果某个持有锁的服务器宕机，其数据库链接也会断开，加在表上的排他锁也会自动释放。不会有Liquibase的那种问题。

Reference

flyway使用
基于数据库实现分布式锁