BK-CI项目中数据库分片规则保存更新的优化实践

背景介绍

在分布式系统开发中，数据库分片(Sharding)是一种常见的数据水平切分策略，它能够有效解决单表数据量过大导致的性能问题。BK-CI作为一款持续集成平台，在处理大规模构建数据时也采用了分片技术来提升系统性能。

问题发现

在BK-CI项目开发过程中，开发团队发现了一个关于分片规则保存更新的潜在并发问题。具体表现为：当多个线程同时尝试保存或更新分片规则时，可能会出现规则重复插入的情况，导致数据不一致。

深入分析后发现，问题的根源在于事务提交与分布式锁释放的时序控制不当。原有实现中存在一个关键时序问题：数据库事务在分布式锁释放之后才提交。这种时序安排会导致一个时间窗口，在这个窗口期内：

1. 线程A获取分布式锁并开始事务
2. 线程A执行规则校验和插入操作
3. 线程A释放分布式锁
4. 线程B获取分布式锁
5. 线程B执行规则校验(此时线程A的事务尚未提交，线程B看不到未提交的数据)
6. 线程B执行插入操作
7. 线程A的事务最终提交
8. 线程B的事务提交

这种情况下，就会导致相同规则被重复插入，违反了业务规则。

解决方案

针对这一问题，开发团队提出了明确的解决方案：确保事务在锁范围内提交。具体实现要点包括：

1. 将事务的提交操作移到try代码块内部
2. 确保在释放分布式锁之前完成事务提交
3. 保持异常处理逻辑不变，确保出现异常时能够正确回滚

这种调整保证了以下关键时序：

1. 线程A获取分布式锁并开始事务
2. 线程A执行规则校验和插入操作
3. 线程A提交事务
4. 线程A释放分布式锁
5. 线程B获取分布式锁时，能够看到线程A已提交的数据

实现细节

在实际代码实现中，主要调整了事务边界与锁范围的关系。伪代码示例展示了优化前后的对比：

优化前：

获取分布式锁
try {
   开始事务
   // 业务逻辑
} finally {
   释放分布式锁
   提交事务 // 错误的时序
}

优化后：

获取分布式锁
try {
   开始事务
   // 业务逻辑
   提交事务 // 正确的时序
} finally {
   释放分布式锁
}

这种调整虽然看似简单，但对于保证数据一致性至关重要。它遵循了分布式系统设计中的一个基本原则：临界区资源(这里是数据库记录)的访问必须被完整保护，包括其可见性。

技术考量

在实现这一优化时，开发团队考虑了以下几个技术因素：

1. 事务隔离级别：MySQL默认的REPEATABLE READ隔离级别下，一个事务内看到的数据视图是固定的，这加剧了原有问题的影响。

2. 锁粒度：分布式锁的粒度需要恰到好处，既要保证并发控制的有效性，又不能过度影响系统性能。

3. 异常处理：即使在事务提交后、锁释放前出现异常，系统也需要有恰当的恢复机制。

4. 性能影响：将事务提交放在锁持有期间会略微增加锁持有时间，但相比数据一致性的保障，这种代价是可以接受的。

实践建议

基于BK-CI项目的这一优化经验，可以总结出一些适用于类似场景的最佳实践：

1. 明确资源保护边界：对于需要分布式锁和数据库事务共同保护的资源，必须明确两者的作用范围和交互关系。

2. 遵循操作时序：对于需要先写后读的场景，确保写操作的可见性在释放并发控制之前完成。

3. 设计评审重点：在代码评审时，应该特别关注分布式锁与事务的交互时序，这往往是并发问题的温床。

4. 测试策略：针对这类问题，需要设计专门的并发测试用例，模拟多线程争用场景。

总结

BK-CI项目中对分片规则保存更新的优化，展示了分布式系统中处理并发控制的一个典型场景。通过调整事务提交与锁释放的时序，有效解决了潜在的数据一致性问题。这一案例也提醒开发者，在分布式系统设计中，不仅要关注单个组件的正确性，更要重视不同机制之间的交互和时序关系。只有全面考虑这些因素，才能构建出健壮可靠的分布式应用。