文章目录
- 1. 工作流程
- 2. 版本号校验算法
- 3. 锁机制
- 3.1 为什么数据库管理工具需要锁
- 3.2 flyway的锁机制
- Reference
最近实习做的几个项目都用到了Flyway来做数据库的版本管理,顺便了解了下基本原理,做个记录。
详细的使用就不写了,网上教程很多。
1. 工作流程
在一个空数据库上部署集成了Flyway的应用:
-
因为数据库是空的,Flyway会先创建这个数据库。
-
Flyway在数据库中创建一张表flyway_schema_histor,用于记录migration的执行情况(跟踪数据库状态)。
-
Flyway扫描migration脚本,并按版本号顺序执行。
- 默认的查找 migration 的路径为 classpath:db/migration:
- 对应 SQL 文件可放置在src/main/resources/db/migration 下;
- Java 类可放置在 src/main/java/db/migration 下。
- 默认的查找 migration 的路径为 classpath:db/migration:
-
变更数据库只需创建一个版本号更高的新migration脚本,下次启动项目时flyway会自动按版本号顺序执行版本号大于flyway_schema_histor表中版本号的脚本
2. 版本号校验算法
flyway在升级数据库时会计算之前已经升级过的脚本的checkSum(CRC32算法,循环冗余校验码),与数据库的checkSum进行对比。
老脚本如果内容发生变化,checkSum校验失败(所以一般老版本的脚本不能修改),抛出异常
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使用
基于数据库实现分布式锁