bash# 确保在项目根目录
cd deep_research
# 检查 Docker 是否运行
docker info
# 确保已登录 Docker Hub
docker login
bash# 方法一:使用脚本自动构建(推荐)
./build-slim.sh
# 方法二:指定构建Linux 版本
## MacOS (ARM架构)
TARGET_PLATFORM=linux/arm64 ./build-slim.sh
## Linux (x86架构)
TARGET_PLATFORM=linux/amd64 ./build-slim.sh
# 方法三:手动构建 Linux 版本
docker build --platform=linux/amd64 \
--build-arg BUILDPLATFORM=linux/amd64 \
--build-arg TARGETPLATFORM=linux/amd64 \
-t golovin0623/deep-research:amd64-slim \
-f Dockerfile.slim .
bash# 克隆项目
git clone https://github.com/Calcium-Ion/new-api.git
cd /Users/liangfeng/evn/projects/new-api
# 创建环境配置文件
cp .env.example .env
适用于主要进行前端代码修改的场景。
bashcd /Users/liangfeng/evn/projects/new-api
FRONTEND_BASE_URL=http://localhost:5173 go run main.go
1. 问题概述
生产环境中,一个基于 SOFA 框架的定时任务在执行过程中,出现了严重的数据不一致现象:任务调度执行上游服务 A 创建指令数据,服务 A 在逻辑中(同事通过手动事务)进行了提交;随后调用服务 B,服务 B 能成功查询到该指令数据,但在尝试更新数据状态时失败(异常被内部捕获处理)。然而,流程结束后检查数据库,发现服务 A 创建的指令数据完全消失,且数据库层面未记录到该数据的成功提交日志。此现象不符合预期的业务逻辑和数据库 ACID 特性。
令人比较费解的是,尽管在异常流程中,服务 B 能够成功查询到由服务 A 创建的数据,并且其内部尝试更新数据时发生的失败异常得到了妥善的捕获和处理(未向外抛出),服务 A 创建的本应持久化的数据最终却从数据库中完全消失,同时数据库层面也未能追踪到该数据成功提交的事务日志。
后续通过一项关键的验证步骤——在生产环境中临时移除对服务 B 的调用后,此数据丢失问题便不再复现。
2. 问题背景与详细现象描述
@Transactional
),但服务 A 早期被描述为“手动提交事务”,可能存在手动 JDBC 事务代码与 @Transactional
的混合使用。系统中未使用分布式事务中间件(如 Seata)。UPDATE
操作时发生错误。具体错误原因未在本次排查中明确(可能是锁竞争、约束违反等),但这本身不是数据丢失的直接原因。try-catch
块捕获了 UPDATE
操作抛出的异常,仅在日志中打印了 error 信息,没有将异常重新抛出。因此,从调用栈来看,服务 B 的方法是“正常”返回给服务 A 的。DELETE
语句来删除这条指令数据的代码。