最新

大家好，HN。<p>我是滑铁卢大学的一名工程系学生，正在构建有状态的 AI 代理，我一直遇到同样的问题：每当我的 Python 脚本崩溃或断开连接时，底层的 Puppeteer 或 Ollama 进程就会一直孤零零地运行，占用 RAM，直到节点因内存溢出而自我终止。标准的负载均衡器会破坏粘性会话，而被动的 HTTP 超时对于清理来说又太慢了。<p>我找不到一个好的本地进程池，能够真正可靠地清理已死的有状态会话，所以我用 Go 语言构建了 Herd。<p>它使用一个持久流（gRPC/Unix 套接字）严格地作为“死亡男人开关”。如果你的客户端脚本死亡，流就会中断。Herd 会注册 EOF 并立即向工作进程发送 SIGKILL 信号（依赖于 Linux 上的 Pdeathsig）。对于实际的繁重数据，你只需通过 Herd 的内部代理发送 HTTP 流量，它会将流量直接路由到活动进程端口。<p>我的实际目标是将其变成一个多节点分布式网格，带有 Redis 注册中心，客户端可以退出，边缘网关会将它们路由回持有其有状态内存的确切 pod。<p>但我知道在有漏洞的本地引擎之上构建分布式网格是死路一条。单节点清理必须首先做到完美。<p>我很乐意让你们来“吐槽”这个架构。具体来说：在生产环境中，依赖 Pdeathsig 作为本地“死亡男人开关”是否足够健壮，还是我太天真了，现在就得咬紧牙关，把所有东西都封装在 cgroups 和微型虚拟机中？<p>代码库链接：<a href="https://github.com/herd-core/herd" rel="nofollow">https://github.com/herd-core/herd</a>