1. mongo_connect 哪来的有点陌生, 这东西不好调试的话临时闭包到 run_spider 里测试一下? 怀疑有些变量传递到进程里面有地方不太对, 多进程类似于各种并行计算的一个特点就是: 尽量无状态无副作用, 里面的各种依赖 /参数 /上下文都尽量隔离干净
2. 本地调试可以运行但线上不行的话, 可能的地方特别多(难怪虚拟化和 go 那么火了)
2.1 最大可能是网络本身就不通(防火墙规则啊, 网卡 ip 不对啊, 非局域网啊, 非开放端口啊), 但是如果关了多进程会 ok, 网络应该不是问题. 可以临时把 PoolProcessExecutor 改成多线程那个, 反正接口一样的, 而且爬虫这玩意本来就没必要多进程
2.2 Python 版本有区别, 个别底层依赖有差异, 这个少见但也遇到过
2.3 第三方依赖的版本或者 C 依赖有差异, 尽量排除这种情况, 以前我遇到过类似情况, 换个版本居然就通了
2.4 检查是不是每个进程都超时, 有一定可能是程序里面或者 mongodb 那边有奇怪的死锁
看了几个长篇大论的回复, 说的也没啥问题, 为啥遭到那么强烈的回怼...
如果是其他社区, 估计也没这么多苦口婆心反而更多幸灾乐祸 + 满嘴 YYDS 的段子手. 没必要一个个怼回去, 上士无争, 选听得进的听, 听不进的以后自己也会自然明白对错.
提个不一定有用的建议: 正视自己的自学能力, 不想放弃编程就老老实实啃那几本基础课程, 语言学多了用处不大, 写到简历上被问住反而会扣分, 精研一两门然后有目的性地做好一两件事吧. 语言或者框架学多了只是 "术" 上的专攻, 基础打牢受益终身
本身跨学科道阻且长, 把编程当兴趣力度不够, 热爱它然后趁着年轻为它拼一把
PS:
1. 特地回头搜了下 geek 这个词... 以前一直以为是 linus 那样的, 翻译让我大开眼界了.
2. 现在卷这个词已经到了滥用的地步了, 没必要一直挂在嘴边, 蓝海向红海竞争过渡都是必然趋势, 并发问题没处理好只是个借口, 主要原因还是可被替代(对方比你便宜或者其他地方比你有优势).
3. 内行看文档, 外行看教程, 尽早把习惯改一改.
ddl 估计不是我以为的那个 ddl.....
你们项目管理靠嘴么, 这都不走那就是他们给太多了吧, 忍忍算了
@
7y 不算前辈... 后端日常用的不多, 已经转 fastapi 了, 喜欢原版或者折腾的可以继续 starlette, 我是怕麻烦那部分... 目前看起能一统江湖的协程 ORM 有了几个, 但是真正统一的还不太行, 各家都在努力造生态
用 starlette 的话, 他们 encode 出的兼容性都比较不错, 当年搭配他们家的 databases; fastapi 作者整了个 sqlmodel 但我看的时候 asyncio 部分文档都没写完...
其他的话, awesome-asgi 或者 Awesome fastapi 之类的里面会有一些, 反正我用过的都只算可用
以前的想不起来了, 最近会用到的是图片转 html 让我直接看文件夹里多张图, 低代码爬虫追剧 B 站追更, 某上网软件节点检测切换, 批量删除视频, 批量操作 chrome...
别好像, 直接去医院, 大夫说我是干眼症还开了点结膜炎的眼药水, 实际上楼上们说的症状我貌似都没有, 就是偶尔有异物感
最后安排了一个月 4 次的睑脂腺按摩, 那酸爽, 第一次弄的时候说这么多... 然后莫名有一种失明后重见天日的感觉, 之后路效果没那么明显了
1. 名字要有意义
2. 名字要有创意
3. 名字要容易记
根据系统用途, 联想到各路天神的技能或者古典神话算了
日志监控系统谛听
爬虫系统千里眼
报警提醒系统顺风耳
财务系统叫财神爷
稳定不宕机的叫六道轮回
不稳定容易宕机的叫八卦炉(天天炸炉)
考勤系统五指山
信息管理系统生死簿
客户关系管理系统扫把星
进销存系统五脏庙
内网 IM 系统小雷音寺
外网 IM 系统大雷音寺
随便想想一大堆
VPN 是正经出路, 早架早享受, 隧道用久了感觉太扯淡了
别人当年也劝过我别拿兴趣当饭碗... 工作年限越久转职越纠结, 因为公司可能更倾向于为你的 "工作经验" 买单, 而不是你的未来可能性
如果实在纠结, 再面几家以前没把握的试试?
go 的市场有点虚, 看似是大趋势, 但还是很吃生态, 社区生态虽然也火热, 但很多大厂还是更相信自家闭源生态, 站出来开源的不占多数, 如果运气好进了一家氛围不错的确实能成功转型, 运气不好就难说了可能前期非常吃力, 因为指望工作中掌握一门技术的要么运气极好要么满盘皆输
至于内卷这个事, 是那些刚入行没其他竞争力只能靠偏门竞争的人折腾的, 你又不跟他们在一条起跑线上怕什么
早年间用的 processon, 然后现在白瓢的
draw.io 存在 Google Drive 上
之前拜托同事也折腾私有 pipy 到 maven 上, 后来嫌麻烦, 直接走内网 git: 的方式安装了...
是 linux 的话 alias 先凑合用用? 很早以前我好像也有这问题, 各种清理 cache 然后 -vvvv 也没啥办法. 刚才搜 pip search private priority 也没发现什么好的建议
@
keith1126 感谢课代表
昨天给我看的一愣一愣的... 另一个新闻还没晃过神来以为这边又出幺蛾子了
高中的生活已经这么精彩了, 后生可畏
@
ifplusor 只是说适合走事件触发, 但是也可以当 rpc 解耦玩同步, 门槛低上限高, 就看架构师水平了
我这边 faas 就是当微服务用, aws 上 boto3 直接同步调用也没啥问题, 用自带的 rest gateway 也很容易配置各种鉴权限流, 就是要花点钱而且 30 秒超时有时候不太习惯.
关键是释放了不少计算资源, 各种适用场景就不赘述了, 这功能解耦粒度比微服务还细, 管它是什么语言实现的反正调用一个函数名字传入内容我就要指定结果
对于低频高计算(平时的定时任务)类型的任务, 比 spot 实例管理起来简单, 真有那种耗时长的再考虑竞价实例. 给我印象最深的就是解决现在公司缺运维导致的机器资源要么长久空闲要么恶意抢占, 钱都花刀把上了
简单地说, 你那边的计算密集任务依然可以留一个调度中心, 有任务在 Serverless 上跑等结果好了返回就行了, 一个 CPU 几百协程还是挺有意思的.
一句话: 没有银弹, all-in 有风险
登录了下还活着, 不知道是小概率时间还是有什么共性
如果问题真的很大, Reddit 或者邮件组之类的是不是该吵起来了
faas 减少运维成本带来的优势明摆着在那了, 至于说绑定什么的, 对象存储和数据库该迁还是得迁, 不可能在一家吊死
去年跟 aws 顾问聊到现在越来越多企业开始布局各类云基础设施, 有的尝试 all-in serverless 也没毛病, 大厂玩家们, 更是多家云混合一起用, 不会只用一家的
至于现状... 去年技术分享了 serverless 同事们不怎么愿意迁, 然后临时调去帮着运维砍成本, 提出来的把花钱的架构拆到 Serverless / spot 竞价实例 / K8S (这几个也是顾问赞同的) 一项都没通过, 只能说习惯是个挺可怕的东西, 不过因为运维走了不愿意担风险也能 "李姐"
最佳实践什么的, 国内相关文章都不多, 之前调研是硬啃的官方文档, 比较麻烦的大概就是服务治理相关经验, 但是哪的服务不用治理的, 现在公司里机器跑的已经乱成一锅粥各种抢资源...
至于成本真的是之前没想到的低, 迁了俩日常定时爬虫任务, 连免费额度都没用光... 之前 faas 貌似都用在 s3 触发的图片裁剪和视频截图上面了
就个人而言, 还是挺希望去一家 all-in Serverless 或者别的云原生相关涨涨经验的, 就竞价实例号称节省 90% 成本这东西, 我就愿意写一大堆无状态 slave 过足瘾的
Select Language