04月22日
一、今日完成情况
- 完成营销比赛PPT内容整合
- 完成数据抽取,进行简单的数据处理,让李明洋可以使用的程度
- 解决问题:数据表的选择和创建写入
- 解决问题:提示词报错,关键字无法获取的问题,一个是数据库当中没有这个字段的关系,还有是提示词写错的关系。
- 和xxy一起完成技术方案数据采集,并且发到群聊当中
二、今日感悟
- 核心业务数据:
- 今天关于数据批量处理起了一个头,然后如果李明阳那边没有问题的话,我可以批量采集数据。这个数据无法系统性的使用,因为的话我目前没有打通数据运行到哪里进行一个达、打标。也就是说我需要知道我当前的这个数据处理运行到数据库的哪一个位置了?未来不是从零开始,而是从那个断点开始,而且还要处理并发加锁的问题。
- 今日工作总结:
- 关于营销比赛的 PPT 的话,AI 真是太好用了,可以生成非常好的框架图,我只需要把提示的图、参考图给它,然后把对应的文本给他就可以了。
- 明日工作计划:
- 明天我需要把数据批量处理打标的任务给完成。
- 每天需要完成。后天要讲的老板的课的 PPT,还有相关的内容的理解。
- 明天晚上的话要去费老师的课程收作业,可以思考一下课程可以做一些什么事情。
- 明天还需要整合一下通信网络基础的 PPT。最好分一下工,对后续的 PPT 演讲视频。明天还需要完成通讯网络基础,我这一部分的图的演示,并且整合成一个4页的 PPT。
- 今日学习成长:
- 今天工作量部分不是很多,但是至少思路上比较清晰了,然后费老师那边也汇报了,知道下一步的重点是什么,果然对我这种七杀。化压力为动力的情况下的话,还是需要一点强度的。在权威的一些要求,还有在截止日期的督促下,我的效率是非常非常高的
三、备注
- 无
四、打通MacBook链接实验室服务器数据库
你的 Mac → 2. 腾讯云服务器 (tecent-lab-server) → 3. 实验室服务器 (121.48.163.69) → 4. MongoDB 数据库 (27018 端口)
前提说明
- 数据库所在机器:tecent-lab-server(你当前登录的 Docker 容器)
- MongoDB 信息:
- 地址:容器内
localhost:27018 - 账号:
root - 密码:
rootdb@ - 认证库:
admin
- 地址:容器内
- 你已能通过
ssh tecent-lab-server免密登录该容器
二、MongoDB Compass 连接
打开 Compass,直接使用下面的连接字符串:
mongodb://root:rootdb@@localhost:27018/?authSource=admin
填写说明:
- 直接粘贴到 URI 输入框
- 无需修改任何参数
- 点击
Connect连接
三、不想终端卡住?后台运行隧道
Mac 终端执行(后台静默运行,不占用终端):
ssh -fN -L 27018:121.48.163.69:27018 tecent-lab-server
执行后直接回到 Mac 命令行,隧道在后台运行
四、用完关闭隧道
方式1:前台隧道
直接按 Ctrl + C 终止终端进程即可
方式2:后台隧道
pkill -f "ssh.*27018"
五、连接失败快速排查
- 确认隧道命令对象是
tecent-lab-server,不是lab-server - 确认隧道终端未关闭、未报错
- 在
tecent-lab-server内测试端口:
有返回字符则端口正常,无返回则 MongoDB 未启动/端口错误curl localhost:27018 - Compass 务必填写
authSource=admin
五、使用个人用户打开所需数据库
MacBook 外网连接实验室 MongoDB 完整配置笔记
一、基础信息
- 专用数据库:
task-2025-10-20 - 认证数据库:
admin - 专用读写用户:
kipley - 密码:
188390 - 目标 MongoDB 地址:
121.48.163.69:27018
二、SSH 隧道启动命令
1. 前台运行隧道(推荐,可查看状态)
ssh -4 -N -L 27018:121.48.163.69:27018 tecent-lab-server
执行后终端保持挂起即为隧道正常,不可关闭终端
2. 后台静默运行隧道(不占用终端)
ssh -4 -fN -L 27018:121.48.163.69:27018 tecent-lab-server
三、MongoDB Compass 连接 URI(直接粘贴)
mongodb://kipley:188390@localhost:27018/?authSource=admin
四、完整使用流程
- 执行上述隧道命令,确保无
channel open failed报错 - 打开 MongoDB Compass
- 新建连接,直接粘贴连接 URI
- 点击连接,仅会显示
task-2025-10-20一个数据库 - 拥有该库完整读写权限,无其他库访问权限
五、关闭隧道
1. 前台隧道
直接在终端按 Ctrl + C
2. 后台隧道
pkill -f "ssh.*27018"
六、连接异常排查
- 报错
connection closed:隧道未打通,重新执行隧道命令 - 报错认证失败:检查用户名、密码、
authSource=admin是否正确 - 端口占用:更换本地端口,如
27019,同步修改 URI 端口号 - 隧道报错:强制使用 IPv4 参数
-4,避免 IPv6 兼容问题
六、梳理一下任务
1、周四晚上九点:去费老师网络安全教室收作业
2、周五下午2点钟,在学生活动中心和之江实验室老师交流
3、周五晚上9:00,老板课程PPT汇报
4、周四白天-周五白天,老板课程PPT熟悉,了解原理并且整合所有PPT
5、周四白天,完成数据抽取的基本工作的完成,实现一个样本,几百条数据还是要有的(测试Deepseek API并发能力)
6、周五白天之前,网络通信基础,完成所有PPT内容的数据整合和分析,包括人员分工。
7、周五白天:找费老师工作汇报和对接,关于数据抽取的部分。
6、周六:规划Windows实验费老师的要求,去实现跑通一下,一周内完成
7、周六:规划小丁、小冉课程的报告的PPT分工和汇报
8、周六:
六、数据批量处理打标问题
你这个目标可以实现成一套兼容、可重跑、可人工控制的机制:源集合“领取式打标” + 单独 ldh_job_checkpoints。关键点是:打标不能只用一个 processed_at,而要带上**job_key / run_id / version** 这类“批次/版本”信息,这样你未来想“重新开始”时,只要换一个标识即可,不需要清掉旧标。
方案核心(不漏 + 可重跑)
1) 源集合字段(建议)
在源文档上新增这些字段(按需):
ldh_status:"pending" | "leased" | "done" | "failed"ldh_job_key: 任务标识(和 checkpoint 里的保持一致)ldh_run_id: 本次运行唯一 ID(比如时间戳/UUID)ldh_leased_at,ldh_lease_expires_at: 领取锁(防止并发重复领到同一条)ldh_done_atldh_fail_count,ldh_last_error
2) “领取任务”怎么做(不漏的关键)
用 MongoDB 的原子操作 findOneAndUpdate 去“领取”一条 pending:
- 查询条件:
ldh_status != "done"或者ldh_job_key != 当前 job_key(看你怎么定义“完成”) - 更新:把它标记成
leased,写入ldh_run_id,并设置lease_expires_at = now + N分钟 - 这样多进程/多线程都不会领到同一条(除非 lease 过期)
处理成功后再把状态改成 done;失败则改成 failed 并记录错误,后续可以重试(例如 fail_count < 3 才允许再领)。
ldh_job_checkpoints 里存什么
它不再只是 last_id,而是记录任务整体的运行信息:
job_key(唯一)active_run_idstatus(running/paused/completed)updated_at- 可选:统计(done/failed 数量、吞吐、最后错误等)
有了“领取式”,即使没有
last_id也能跑;checkpoint 更多是用于可视化、暂停/恢复、统计、以及“人工重置”。
你关心的点:未来想重新开始处理,之前打过标怎么办?
最方便、最安全的做法是**“版本化/换 job_key(或 run_id)”**,不要清空字段。
推荐:用 job_key(或 job_version)实现“一键重跑”
你可以把 job_key 设计成包含版本,例如:
job_key = "task-2025-10-20/google_news_copy->ldh_processed_news_events@v1"- 想重跑就改成
@v2
然后你的“是否需要处理”的判断改为:
- 只处理
ldh_job_key != 当前 job_key的文档(哪怕它以前 done 过 v1,也会作为 v2 的 pending 再处理)
这样你人工“重新开始”的操作就变成:
- 把脚本里的
JOB_VERSION/JOB_KEY改一下(或用环境变量传入) - 不需要手动清库、不需要批量 unset 字段
备选:提供人工“重置开关”(两种方式)
- 方式 1(推荐):环境变量
FORCE_RERUN=1→ 程序启动时自动切换到新job_key(比如在旧版本号上 +1,或用时间戳生成)。 - 方式 2(侵入性更大):手工在 MongoDB 执行一次更新,把旧标记清掉/改回 pending(例如把所有
ldh_status:"done"改回 pending)。缺点是容易误操作、范围大。
兼容性怎么保证(你提的“未来其它 collection 同理”)
- 统一约定源集合字段前缀:比如都叫
ldh_* - 统一
job_key规则:{db}/{source}->{target}@{version} - 所有 collection 都可复用同一套“领取式 + lease + done/failed”逻辑
- checkpoint 集合只按
job_key存一条记录即可
如果你同意这个方向,我建议你最终的“人工可控入口”就两个环境变量:
JOB_VERSION(或直接JOB_KEY):想重跑就改版本LEASE_MINUTES/MAX_RETRIES:控制领取锁和失败重试
你希望“重跑”时目标集合 ldh_processed_news_events 是覆盖更新同一条 source_id(保留历史只更新字段),还是保留历史结果并写入新集合(例如 ldh_processed_news_events_v2)?这会影响 job_key 的设计以及目标集合的写入策略。
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 kipleyarch@gmail.com