BKCI项目中数据库分片规则保存的并发控制优化实践

背景介绍

在分布式系统开发中，数据库分片规则的保存是一个关键操作，需要保证在高并发环境下的数据一致性和正确性。BKCI（BlueKing Continuous Integration）作为一款持续集成工具，在处理大规模构建任务时，对数据库分片规则的并发访问控制尤为重要。

问题分析

在BKCI项目的早期实现中，数据库分片规则的保存逻辑存在一个潜在的问题：数据库事务的提交发生在分布式锁释放之后。这种实现方式可能导致以下问题：

1. 并发访问异常：当线程A获取锁并开始事务后，如果事务还未提交就释放了锁，线程B可能立即获取锁并执行规则校验。由于线程A的事务尚未提交，线程B无法看到最新的数据状态，可能导致重复插入等数据不一致问题。

2. 数据可见性问题：在分布式系统中，事务隔离级别和锁的配合使用至关重要。过早释放锁而事务未提交，违背了"先提交后释放"的基本原则。

解决方案

针对上述问题，BKCI团队实施了以下优化措施：

1. 调整事务提交时机：将事务的提交操作移到try代码块内部，确保在释放分布式锁之前完成数据库事务的提交。这样其他线程获取锁时，一定能看到前一个线程已提交的数据变更。

2. 完善异常处理：在事务提交失败时，确保能够正确回滚事务并释放锁，避免死锁情况的发生。

3. 代码结构优化：重构了相关代码，使其逻辑更加清晰，便于后续维护和扩展。

技术实现细节

优化后的代码逻辑遵循以下流程：

1. 获取分布式锁
2. 开始数据库事务
3. 执行业务逻辑和数据操作
4. 提交事务
5. 释放分布式锁
6. 异常处理中确保事务回滚和锁释放

这种实现方式确保了ACID特性中的隔离性和一致性，特别是在高并发场景下：

• 原子性：通过数据库事务保证
• 一致性：通过业务规则校验和锁机制保证
• 隔离性：通过锁和事务的配合保证
• 持久性：通过数据库机制保证

实践效果

经过优化后，BKCI在以下方面得到了显著改善：

1. 数据一致性：彻底解决了因并发访问导致的数据重复插入问题。
2. 系统稳定性：减少了因数据不一致导致的系统异常情况。
3. 性能影响：虽然锁持有时间略有增加，但由于事务处理时间通常很短，对整体性能影响可以忽略。

经验总结

通过这次优化，我们总结了以下几点经验：

1. 在分布式系统中，锁和事务的配合使用需要特别注意时序问题。
2. 事务提交应该在锁范围内完成，这是保证数据一致性的基本原则。
3. 代码审查和测试时，需要特别关注并发场景下的边缘情况。
4. 分布式锁和数据库事务是两个维度的控制机制，需要协同工作才能保证系统正确性。

这种优化思路不仅适用于BKCI项目，对于其他需要处理高并发数据库访问的分布式系统也具有参考价值。特别是在需要保证数据唯一性和一致性的场景下，合理设计锁和事务的配合机制至关重要。