feat: job-execute 支持垂直分库 #3265

[wangyu096]

背景

1. 当前 Job-execute 执行引擎只能使用单个 db，导致 db 负载高，主从延迟严重，风险大。
2. 由于单 db 数据量太大，会导致后续水平分库分表迁移的时候db 出现性能问题，影响应用

所以，先拆分单个 db 为垂直分库模式，把不同的表分散到多个 db 上，降低单个 db 的负载，并为后续水平分库分表数据做好准备。

设计

垂直分库设计

分成固定的三个 db，把job-execute的表分散到三个 DB 上。之所以采用这种固定的方式，原因是：

1. 根据经验，这种拆分方式比较合理
2. 改造成本，固定方式较为简单

另外，由于垂直分片的方式仍然有局限性，比如只是扩大了有限的承载能力(几倍），比如表之间的 join关系、事务在垂直分片模式下都会受到限制，所以该方案仅作为过渡方案，等后续水平分库上线之后，该方案将不再支持。

无损迁移方案

常规的迁移方案是数据双写 -> 数据校验补偿 -> 切读写到新集群。由于双写改造工作量比较大，所以在实施垂直分片迁移的时候不采用该方案，而是采用在切换期间短暂阻塞db 读写请求的方式（影响窗口小，大概 10-20s)。这样做的好处就是改造简单一些，然后也是相对无损的，只需要阻塞写请求一小段时间。

准备阶段：
应用层改造，支持运行期间动态切换数据源。

实施阶段：

1. dba 开启主从同步
2. 主从同步0延迟之后，job通过广播开始通知所有服务实例停止读写db
3. dba 断开主从同步（需要确认数据完全同步到新的集群）
4. job 切读、写请求到新集群

重点 Review代码：

1. 引入新的动态属性，支持在运行时修改属性值并借助 spring-cloud-kubernetes-config-watcher 和 spring-cloud-bus 的消息通知机制，动态切换数据源 （backend/commons/common/com.tentcent.bk.job.common.toggle.prop)

2. 垂直分片 (backend/commons/common-mysql )

3. db 无损迁移：PropBasedDynamicDataSource.java ReadWriteLockDbMigrateAspect.java

[jsonwan]

大量线程阻塞在这里，随着请求累积，可能导致Tomcat工作线程耗尽，影响到后续其他请求，建议只阻塞必要的写请求，可提前压测验证观察程序表现。