编辑
2025-04-15
工具
00

国安局、网信办要求关闭。

故只展示搜索深度搜索的效果:

编辑
2025-03-18
工具
00

深度研究助手 Docker 镜像部署手册

一、镜像打包和上传

1. 准备工作

bash
# 确保在项目根目录 cd deep_research # 检查 Docker 是否运行 docker info # 确保已登录 Docker Hub docker login

2. 构建镜像

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 .
编辑
2025-03-13
工具
00

本地调试步骤

1. 环境准备

  • 安装Python 3.9+(小于3.12)
  • 安装Poetry 1.6.1:pip install poetry==1.6.1
  • 获取火山方舟API KEY:访问 火山方舟控制台
  • 开通DeepSeek-R1模型:在 开通管理页 完成

2. 选择搜索引擎

选择一:使用火山方舟零代码联网应用

  • 创建零代码联网应用,获取bot id

  • 推荐配置:

    • 推理接入点:Doubao-pro-32k / Doubao-pro-1.5-32k
    • 联网内容插件:开启
    • 智能改写:关闭
    • 调用方式:强制开启
    • 参考资料回复:自定义回复 选择二:使用Tavily搜索引擎
  • 获取 Tavily API KEY

编辑
2025-03-06
环境部署
00

New-API 开发调试手册

1. 环境准备

  • Node.js 环境
  • Go 开发环境
  • Git
  • 编辑器(推荐 VSCode 或 GoLand)

2. 项目初始化

bash
# 克隆项目 git clone https://github.com/Calcium-Ion/new-api.git cd /Users/liangfeng/evn/projects/new-api # 创建环境配置文件 cp .env.example .env

3. 开发模式一:前端开发模式

适用于主要进行前端代码修改的场景。

3.1 启动后端服务

bash
cd /Users/liangfeng/evn/projects/new-api FRONTEND_BASE_URL=http://localhost:5173 go run main.go
编辑
2025-02-25
工具
00

生产环境数据库数据异常丢失问题复盘排查报告

1. 问题概述

生产环境中,一个基于 SOFA 框架的定时任务在执行过程中,出现了严重的数据不一致现象:任务调度执行上游服务 A 创建指令数据,服务 A 在逻辑中(同事通过手动事务)进行了提交;随后调用服务 B,服务 B 能成功查询到该指令数据,但在尝试更新数据状态时失败(异常被内部捕获处理)。然而,流程结束后检查数据库,发现服务 A 创建的指令数据完全消失,且数据库层面未记录到该数据的成功提交日志。此现象不符合预期的业务逻辑和数据库 ACID 特性。

令人比较费解的是,尽管在异常流程中,服务 B 能够成功查询到由服务 A 创建的数据,并且其内部尝试更新数据时发生的失败异常得到了妥善的捕获和处理(未向外抛出),服务 A 创建的本应持久化的数据最终却从数据库中完全消失,同时数据库层面也未能追踪到该数据成功提交的事务日志。

后续通过一项关键的验证步骤——在生产环境中临时移除对服务 B 的调用后,此数据丢失问题便不再复现。

2. 问题背景与详细现象描述

  • 技术环境:
    • 应用框架: SOFA 框架
    • 核心组件: 定时任务调度机制
    • 数据库: MySQL
    • 事务管理: 主要依赖 Spring 的声明式事务 (@Transactional),但服务 A 早期被描述为“手动提交事务”,可能存在手动 JDBC 事务代码与 @Transactional 的混合使用。系统中未使用分布式事务中间件(如 Seata)。
  • 业务流程:
    1. SOFA 定时任务按预定时间触发。
    2. 定时任务调用服务 A 的业务逻辑。
    3. 服务 A: 生成一条指令数据,并将其持久化到数据库。
    4. 服务 A: 调用服务 B 的接口,传递相关指令信息。
    5. 服务 B: 接收到调用后,首先根据指令 ID 查询数据库,验证指令是否存在。
    6. 服务 B: 如果查询到指令,则尝试更新该指令的状态等信息。
  • 异常现象详细记录:
    • (✓) 查询成功: 服务 B 在执行更新逻辑前,通过日志确认能够成功查询到由服务 A 创建并(理论上已)保存的指令数据。
    • (✗) 更新失败: 服务 B 在对该指令数据执行 UPDATE 操作时发生错误。具体错误原因未在本次排查中明确(可能是锁竞争、约束违反等),但这本身不是数据丢失的直接原因。
    • (✓) 异常内部处理: 服务 B 的代码使用了 try-catch 块捕获了 UPDATE 操作抛出的异常,仅在日志中打印了 error 信息,没有将异常重新抛出。因此,从调用栈来看,服务 B 的方法是“正常”返回给服务 A 的。
    • (✓) 后续流程正常: 服务 B 捕获异常后,其后续的业务代码(如果有的话)继续执行,并且调用服务 B 的服务 A 以及整个定时任务的后续流程(如果服务 A/定时任务在调用 B 后还有其他步骤)在日志层面看起来是正常执行完毕的,没有记录到其他的业务或框架级异常。
    • (✗) 数据最终丢失: 在整个定时任务执行完毕后,通过数据库客户端或后续查询发现,服务 A 最初创建的那条指令数据在数据库中消失了,无法找到。
    • (✗) 无数据库提交日志: DBA 通过检查数据库的相关日志(如 Binlog、Commit Log 等),确认没有找到服务 A 创建的那条指令数据的最终成功提交记录
    • (✓) 无显式删除逻辑: 通过代码审查,确认在服务 A 或服务 B 的正常业务逻辑以及异常处理逻辑中,没有显式编写 DELETE 语句来删除这条指令数据的代码。