常见错误了，异步循环里别用同步的库，time.sleep 改 asyncio.sleep

我在用的是 code01 第一代 4800H 版，完全符合要求，不过现在只能买到 2 手了，而且电流声有些大的，机械革命的控制台限制充电阈值不是很行，我的一年多就鼓包了，自己换的话还算便宜不到 300 ，不过后面很影响我后面选它。

比较新的款就惠普的战 x 和战 66 的 14 寸版 英特尔 12 代酷睿系列咯，其中战 66 的版本是 ddr4 内存升级起来比较便宜。这些厂商在内存上都有些傻的，明明支持 64g 内存，宣传却说只支持 32g 。

再重一点的有雷神 TBook 16 （ 1.75kg ），和机械革命无界 16 同款模具。

至于联想，它轻薄本系列从来不考虑内存扩展，不用考虑了。

看你没提到对于存储的要求，提一下如果第二硬盘位是 2242 规格的，好的固态有点难买到，最近 framework 出的 2242 2t 的 ssd 被一群 steam deck 玩家给买空了

NestJS 比较正统,Midway 会被阿里味毒打,Directus 比较适合单人干活偷懒省事

node-red

连 mysql 用的什么库？
在异步 IO 里面用同步阻塞的库是个比较常见的错误用法，表现就是一处阻塞处处阻塞，如果内部各种 IO 操作一个地方用了同步阻塞的就会出现这种问题。
平时做好异常监控，比如接入 Sentry ，提早发现问题吧。

软考历年架构师真题看一下，有一说一里面很多题都挺潮的。

雷军之前演讲时有一句话不错，就是公司账上必须保留 18 个月的现金。

这句话拿来劝刚工作的人也一样的，攒够能生活 18 个月的现金，你的心态会平和很多。

不一定要 all in one ，任务调度、发送请求、解析内容、数据入库等可以用微服务的理念拆分开来，这样也方便扩展和重构，这玩意没有万金油的。
从事件驱动的玩法上看，在异步里面做 cpu 复杂度高的计算都会降低时间循环的效率，所以解析复杂度高的东西都是拆分出去的，避免阻塞发送请求的代码。

如果你观察过云服务商的 serverless ，你会发现它们那些通过队列事件触发的函数本质上也是一个 http 函数，因为可以和 api 网关 /k8s 结合，在更新版本时候可以把新流量导到新版本上，老版本等原有的 http 连接都关闭完就销毁。

我目前在用 Node.js 写的爬虫也是这么设计的，目前是基于 NestJS 这个 web 框架做爬虫，结合 nsq 做任务调度，每个外发请求都是用 http 接口来触发，用 traefik 做网关和灰度切换，再结合 k8s 和部署和健康检查做滚动更新。

目前用的到库：
jsonata：用来解析复杂 json ，降低代码复杂度
cheerio：服务端的 jquery ，在 python 有 BeautifulSoup ，在 java 有 jsoup ，也是类似的功能
cld：语言检测，在 python 里有 langdetect

不过也准备重构了，目前碰到的问题是任务堆积多了之后内存涨得快回落得慢，说白了就是 gc 回收不及时，打算先用 C# 把调度和发送请求的部分重构一下，再不行就换 rust ，解析和入库还是用回 nodejs 。

可行啊，我这样做一年多了，打包成单文件丢 alpine/slim 容器，体积小了很多。
比如拿个简单的 NestJS 的程序打包出来也就四十多 MB 吧，丢到 alpine 也就加 5MB 。
好处是在 serverless 环境里避免了 node_modules 大量碎片文件拖慢解压速度，以达到提升冷启动速度的目的。
唯一的缺点是接入 sentry 这种异常监控告警，定位到的代码不那么准。Deno 接下来重点也在兼容 Node.js ，到时又会多一个打包成可执行文件的方案。

每次看到线程池的八股文，我就有种别样的感觉。

.NET 3.5 (2007 年)就支持 async/await
Golang 1.0 (2012 年)发布。
Node.js 6.x(2016 年)开始实验性支持 async/await ，2017 年的 8.x 正式支持
Python 3.5(2015 年)开始支持 async/await ，不过由于 Python 不是像 Node.js 这样的天生异步，还有大量标准库和第三方库仍然使用的是 IO 阻塞模型，所以刚出来那几年还比较鸡肋。
Ruby 3.0(2020 年)开始支持 Ractor 和 Fiber Scheduler ，我觉得它正在经历 Python 3.5 async/await 刚出来那几年的过程。

2022 的 java 面试经验：我跟面试官聊了一个小时线程池
你说像不像 IE 浏览器？
https://pic2.zhimg.com/80/v2-fdd5ebc5f8a0ca5b6c5cf3618b79650d_720w.jpg

选大而全的。

大而全框架带来的是一整套的成熟的解决方案，不需要自己东拼西凑搞半成品，比如当年屌炸天的 Ruby on Rails ，指导了多少框架，前端工程化惊为天人，缓存利用到极致，ORM 设计更是被现在的框架各种抄。简陋的框架只会让别人去拼凑，最佳实践都很少，也不利于开阔视野。看看 python web 那些从 Flask 转到 Django 的就懂了，还有现在的 FastAPI ，流行度比 Sanic 高多了。

排除单独吹 Serverless 的，因为各大云厂商 Serverless 都支持跑 docker 镜像，自己拿 pkg 打成单个可执行丢 slim/alpine 镜像就搞定了，也就几十 MB ，冷启动快得一批，而且 Deno 接下来重点也在兼容 Node.js ，到时又会多一个打包成可执行文件的方案。再看看云厂商那蹩脚的 layer 层设计，让你把 node_modules 放那里，一堆碎片文件妨碍启动速度，不靠谱，狗看了都摇摇头，搞不好还是网络加载的。

单独面向微服务的也可以排除了，比如 Moleculer ，这年头微服务直接上 k8s 然后纯 http 互相调用，无状态简单得一批，可观察性也好，工具链也成熟，还能精细控制流量。

排除 Midway.js ，阿里的开源大家都懂的，三年前我第一个 Node.js 项目用它就碰到一些弱智 bug ，懒得再看了。

排除没用 TypeScript 的，Sails/Hapi 拜拜。

AdonisJS 的纯 TypeScript 版出来太晚了，挺像 Laravel ，PHP 转型到 Node.js 的会喜欢，不过很多 PHP 都觉得转 go 会更好。

所以没什么好选的了，早知道，还是原道，哦，还是 NestJS 。

@Proxy233 触发器要通过绑定他们的 api 网关才支持 WebSocket ，TCP 不支持

@changdy 在数据库中间件配 hook 就搞定了，不用解析日志

@yangyaofei 没有用工具，自己写了几十行 nodejs 的代码就搞定了。

@changdy 完全没考虑，按我的估算数据量到 10 亿，磁盘占用也不到 500G ，在云厂商那里磁盘拉一下进度条扩容就完事了。而且云厂商对 pg 的分布式不太友好，想引导你去它魔改的云原生的版本，贼贵，还不如后面自己用 citus 扩展自建

从付费消息刚出来就绑卡了。
作为正则表达式苦手，我一般在上面用注释放一段样例数据，下面注释放我要提取的数据部分，然后起个包含 regex 单词的变量，它就会帮我补好正则表达式了，非常节省生命。

一开始我也想踢掉 es （ 2c4g 3 节点，580 元 /月），因为我们业务就一个 2c4g 的 PostgreSQ （一主一从，480 元 /月），一张单表同步到 es 做检索，我想 PostgreSQL 搞全文检索问题应该不大。

场景就一个单表（目前千万级，一年内会亿级）的多字段（ 27 个字段）的由用户发起的不确定条件的联合查询 + 几个字段单方向排序。

一开始我验证的是 PostgreSQL 全文检索，腾讯云升级到 4c8g 的一个月才 980 元，开 zhparser 扩展的确很快，几毫秒就搜出来了，但是任意几个字段组合检索就慢得要死（几百毫秒到 1 秒多），更别说 count 一下条数或者 odery by 了。

而在 es 里，2c4g ，检索速度非常稳定，任意字段组合检索都是十几毫秒，于是我打消了踢掉 es 的念头。

你可能需要的是云函数（ serverless ），https://help.aliyun.com/document_detail/179379.html 阿里云云函数环境最高支持 16 核 32G 内存，做个 docker 镜像丢上去跑就可以了。