公司成功導入 Cache，然後規定每次都要重新確認

昨天才確認過的事情，今天再確認一次。
上週已經寫下決定，這週又從背景介紹開始。

重新確認，有時很必要。

但如果條件沒變，也沒有新資訊，我們是不是仍在重跑同一套流程？

答案可以重用，但要有失效規則

最近我做了一個小專案：

tiny-dns-router

一個用 Python 實作的本地 DNS 轉送服務，依網域後綴，把查詢送到指定的上游 DNS 伺服器。

其中一個研究重點，是 Cache。

假設有人問：

「這個網域的 IP 是什麼？」

系統向上游查詢，得到答案。

幾秒後，又有人問同樣的問題。

如果答案符合快取重用條件，就不必再向上游問一次。

但查過，不代表可以永遠沿用。

DNS 用 TTL（Time to Live）限制快取可重用的時間。這是允許重用的期限，不是資料必然最新或正確的保證。

尤其是資料變動快的時候。

就像有些公司的組織圖，星期五還是最新版本。

星期一就變成歷史文獻了。

重複查詢中的快取收益

這次在原生 macOS loopback 上，我用設定了 6 ms 延遲的受控上游，比較啟用與停用快取的差異。

在重複查詢的 UDP 情境中，每次試驗都從空快取開始，按預定每 3 ms 一筆的排程送出 120 筆查詢。查詢重複使用四種鍵，涵蓋正向與否定回應。

兩種模式各有三次試驗。先計算每次試驗的 p50 延遲，再分別取三次結果的中位數：

停用 Cache：7.33 ms。
啟用 Cache：0.69 ms。

延遲從客戶端實際發起查詢算到回覆驗證完成，不含發送前的排程等待。

上游查詢次數的中位數，則從 120 次降到 4 次。

這組結果顯示：在這個重複查詢情境裡，重用答案能減少上游工作，也降低查詢延遲。

但換成每次都不同的 unique-query workload，收益就很有限。

這個快取沒有讓所有 DNS 問題都變快。

它改善的是符合重用條件、能夠命中的查詢。

不存在，與沒有回答，是兩件事

這次也實作了 Negative Caching，也就是否定快取。

例如收到上游符合規則的「網域不存在」回應，可以依否定快取的條件與期限暫存。

但有兩件事，必須分清楚：

上游回覆「不存在」。
以及上游沒有回答。

不然你打電話給財務部，沒人接。

系統立刻宣布：

「財務部不存在。」

這不是 Negative Caching。

這是組織重整。

逾時、傳輸錯誤與符合規則的否定回應，需要不同的處理。

不能因為沒有取得答案，就製造一個看似肯定的答案。

量測範圍、資源限制與故障處理

除了快取，這個服務也包含 UDP/TCP 轉送、依網域後綴路由、快取容量限制，以及逾時後切換上游等處理。

因為能回答正常查詢，只是系統行為的一部分。

還要確認資料怎麼過期、資源如何受限，以及上游失敗時怎麼處理。

macOS 與 Colima Linux 各通過相同的 40 項測試；兩個平台合計完成 72 次量測，取得 8,640 筆正確回覆。

這仍然是一個工程實驗。

固定負載結果不代表最大吞吐量。
Loopback 不代表真實 Internet。
Colima Linux 的量測與原生 macOS 分開報告。

它不是 Production Resolver，也沒有提供 DNSSEC validation。

快取容量限制針對項目數與儲存回應的位元組數，不是整個程序的 RAM 硬上限。

對我來說，這個專案的價值，是把路由政策、快取、資源限制與故障處理接在一起，讓行為能被測試與量測。

團隊需要答案的重用規則

放回團隊流程，也有一個值得問的問題：

「什麼條件下，既有答案可以直接使用？」

條件改變、答案過期或決策風險升高時，重新確認可能是必要的。

但我們也需要說清楚：

誰負責維護答案？
哪些變化會使它失效？
什麼情況必須重新驗證？
沒有新資訊時，誰有權依既有決定繼續往前走？

建立知識庫，只完成了一部分。

答案保存下來之後，團隊還需要說清楚，什麼時候可以直接沿用。

否則，大家辛苦寫文件、整理 FAQ、留下決策紀錄。

某天有人問：

「這件事以前處理過嗎？」

「有，完整紀錄就在知識庫。」

「很好，那我們安排一個會議，重新確認一下。」

原來公司不是沒有 Cache。

只是每份答案使用前，都得再開一次會。

效果就像 TTL 永遠是零。

原創程式碼與文件採 MIT License；第三方依賴保留各自授權。

#SystemsEngineering #Networking #DNS #Python