Weblate项目中Google翻译API术语表并发创建问题的解决方案

在Weblate项目集成Google翻译API时，开发团队发现了一个与术语表(Glossary)创建相关的并发问题。当多个请求同时尝试创建相同名称的术语表时，系统会抛出"AlreadyExists: Glossary with this name already exists"异常。

问题背景

Weblate作为一款开源本地化平台，经常需要与第三方翻译服务如Google翻译API进行集成。在实现术语表同步功能时，系统需要将本地术语表上传至Google翻译服务。然而，在高并发场景下，多个工作进程可能同时尝试创建相同名称的术语表，导致服务端返回"AlreadyExists"错误。

技术分析

该问题的核心在于缺乏对并发创建请求的优雅处理机制。当多个线程或进程同时调用Google翻译API的create_glossary方法时，第一个请求成功创建术语表后，后续请求会因为名称冲突而失败。这种场景在分布式系统中十分常见，特别是在自动化翻译流程中。

从技术实现上看，Weblate的machinery/googlev3.py文件中create_glossary方法直接调用了Google API客户端，没有预先检查术语表是否已存在，也没有对并发创建做特殊处理。

解决方案

开发团队通过以下方式解决了这个问题：

1. 异常捕获与处理：在create_glossary方法中添加了对AlreadyExists异常的捕获，当遇到术语表已存在的情况时，不再视为错误，而是正常继续流程。

2. 幂等性设计：将术语表创建操作设计为幂等的，无论执行一次还是多次，最终结果都保持一致。这种设计模式在分布式系统中尤为重要。

3. 前置检查：在可能的情况下，先查询术语表是否存在，再决定是否执行创建操作，减少不必要的API调用。

实现意义

这一改进带来了多方面的好处：

• 提高了系统的稳定性，避免了因并发操作导致的意外中断
• 增强了用户体验，用户不会看到因后端并发问题导致的错误信息
• 优化了API调用效率，减少了不必要的重复创建请求
• 为系统的高并发处理提供了更好的基础架构支持

最佳实践建议

对于类似的多服务集成场景，建议开发者：

1. 充分考虑并发操作可能带来的问题
2. 实现适当的重试和错误处理机制
3. 尽可能使关键操作具备幂等性
4. 在文档中明确说明接口的并发特性
5. 考虑使用分布式锁等机制处理高并发场景

这个问题的解决体现了Weblate团队对系统稳定性和用户体验的持续关注，也为其他开发者处理类似问题提供了有价值的参考。