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 镜像丢上去跑就可以了。

“你电脑内存多大”
“1T”
“哈哈哈真是小白，哪来 1T 的内存，那是硬盘”
“没错啊（打开机箱亮出主板上 8 条 128G ECC 内存）”

“你项目多大并发”
“10 万”
“哈哈哈你知道 10 万并发是什么概念吗”
“没错啊（打开日志 /监控上的某一时间范围的数据统计，那里显示着峰值时每秒有 10 万次左右的请求）”

异曲同工之妙（ dog

观念问题，一堆黄色的告警中往往隐藏着潜在 bug ，机器都能看出来的问题为什么要视而不见，所以我从业以来就是全部清理的，前期比较蛋疼因为 IDE 一升级加了规则又会多好多告警，不过我也会专门清理完。带人也是这么宣导的（前提是工具链统一），基本上呆的每个团队我都会在第一个月持续灌输这个理念，基本上后面就不会出现了。

其实带来的好处很多的，比如新增的代码里 IDE 告警了，你会很敏感，会多思考一下，特别是以前写 PHP 的时，IDE 能发现的告警基本上都是一些潜在 bug 。

换位思考一下，2 个功能差不多的代码库，一个 IDE 能提示出 2000 个告警，另一个库几乎没有告警，你会觉得哪个质量好？

@dzdh 我觉得主要看你们是否把调整配置当成一次发版（更新容器）进行操作，如果不会线上 reload 那的确可以直接单个文件一把梭。

reload 用于一般用于蓝绿部署，nginx unit 的条件路由可以很好的控制流量，比如通过特定 header 字段和值进行流量切换，比如把测试账号引流到特定节点。

另外不建议把 nginx 和 php-fpm 分开部署，因为 php 的 curl 功能过于强大，如果代码逻辑不严谨或者缺乏安全团队测试，不恰当使用 curl 的话，会被和 gopher 组合构造出任意代码给 php-fpm 执行（相当于后门）。

@dzdh nginx unit 说白了就是更容易编程化的 nginx ，你也可以把 json 写到文件，然后给 post json 文件的 curl 命令做个 alias ，就能达到修改配置文件 + nginx -s reload 的效果