https://yennj12.js.org/yennj12_blog_V4/tags/redis-stream/Recent content in Redis Stream on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 10 Sep 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part5-system-code-structure-zh/Thu, 10 Sep 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ragflow-intro-part5-system-code-structure-zh/大多數人讀開源專案的原始碼，是從 README 跳到 main()，看幾個函式，然後說「架構我懂了」。 真正的答案是：一個系統的架構不在程式碼裡，在進程拓撲、佇列語意、失敗處理與擴充邊界裡。 哪些東西是無狀態的？任務失敗會怎樣？要加一倍吞吐要改什麼？這三個問題答得出來，才算讀懂。 這篇文章回答的就是這三個問題。 前言 Part 1 到 Part 4 拆完了資料的完整生命週期。本篇回到工程層：這些邏輯是怎麼被組織成一個能跑、能擴、能維護的系統的。 要處理的問題： ① 有幾個進程？誰是無狀態的？擴充要改哪個參數？ ② 一個 HTTP 請求從 nginx 到資料庫，經過幾層？ ③ 非同步任務系統的語意：投遞、消費、確認、取消、重試、超時 ④ 兩套 DAG 引擎（Agent Canvas / Ingestion Pipeline）為什麼要兩套？ ⑤ 為什麼一個 Python 專案的 GitHub 主要語言標成 Go？ 一、程式碼地圖 先給一張完整的目錄職責表。這張表的來源是 repo 自帶的 AGENTS.md（專案給 AI coding agent 的操作指引），它比 docs/ 更貼近當前程式碼。 ragflow/ │ ├── api/ Python API server（Quart + Peewee） │ ├── ragflow_server.py 進程入口（6.5 KB） │ ├── apps/ │ │ ├── restful_apis/ 29 個 API 藍圖（dataset / document / chunk / chat …） │ │ ├── services/ API 層的服務（薄，做參數轉換與編排） │ │ └── auth/ 認證 │ ├── db/ │ │ ├── db_models.