一、調(diào)度不準(zhǔn)問題及修正方式局限性

在字節(jié)跳動的業(yè)務(wù)生態(tài)中，HTTPDNS 承擔(dān)著為抖音、今日頭條、西瓜視頻等核心應(yīng)用提供域名解析服務(wù)的重任。但目前我們所采用的業(yè)界主流緩存機(jī)制（火山Cache1.0），卻存在著調(diào)度不準(zhǔn)的問題：

業(yè)界主流緩存機(jī)制的問題

緩存粒度：城市-運營商

致命缺陷：當(dāng)自身IP庫與權(quán)威DNS服務(wù)器不同，易發(fā)生調(diào)度不準(zhǔn)，可能影響用戶體驗

主流調(diào)度修正機(jī)制的局限性

針對 HTTPDNS 調(diào)度不準(zhǔn)風(fēng)險，業(yè)界主流處置流程采用 “發(fā)現(xiàn)-定位-修復(fù)” 三步閉環(huán)機(jī)制，具體如下：

1. 發(fā)現(xiàn)：通過監(jiān)控告警、業(yè)務(wù)異常反饋等方式，識別存在調(diào)度偏差的解析場景；
2. 定位：結(jié)合訪問日志、鏈路追蹤數(shù)據(jù)等，定位調(diào)度不準(zhǔn)的具體域名、源IP段和目標(biāo) IP 段；
3. 修復(fù)：通過技術(shù)手段修正解析結(jié)果，核心修復(fù)方式包含以下兩類（均存在顯著局限性）：

• 地址庫升級：基于外部供應(yīng)商數(shù)據(jù)聚合構(gòu)建的 IP 地址庫，即使實時更新，仍難與外部 CDN 廠商的映射保持一致。
• 臨時劫持：手動配置解析劫持規(guī)則修正解析結(jié)果，不僅操作流程繁瑣、耗時長，且需人工維護(hù)大量靜態(tài)配置；若規(guī)則未得到及時維護(hù)，易引發(fā)解析結(jié)果異常。

二、Cache2.0 架構(gòu)優(yōu)化

緩存粒度技術(shù)方案對比

緩存粒度設(shè)計直接影響 DNS 解析精準(zhǔn)度，主流廠商的方案存在明顯差異：

緩存鍵精細(xì)化重構(gòu)

我們綜合考量調(diào)度精準(zhǔn)度、工程復(fù)雜度以及成本，決定將緩存粒度由“城市+運營商”細(xì)化為“網(wǎng)段”。

傳統(tǒng)方案（國內(nèi)某廠商/火山Cache1.0）

• 緩存粒度：城市+運營商
• 污染范圍：整個城市運營商
• 調(diào)度準(zhǔn)確性：低

Cache2.0方案

• 緩存粒度：網(wǎng)段
• 污染范圍：單個網(wǎng)段
• 調(diào)度準(zhǔn)確性：高

網(wǎng)段自適應(yīng)劃分算法

背景：外部 CDN 廠商的調(diào)度結(jié)果會隨網(wǎng)絡(luò)拓?fù)浜驼{(diào)度策略持續(xù)變化，而靜態(tài)網(wǎng)段庫劃分方式固定，難以實時跟蹤調(diào)度結(jié)果變化。為解決這一問題，網(wǎng)段庫動態(tài)劃分算法通過“數(shù)據(jù)輸入—一致性校驗—網(wǎng)段調(diào)整—結(jié)果輸出”的閉環(huán)流程，實現(xiàn)了網(wǎng)段庫的自適應(yīng)動態(tài)劃分。

具體流程如下：

1. 數(shù)據(jù)輸入

• 收集客戶端IP—CDN IP映射數(shù)據(jù)

數(shù)據(jù)來源：主動撥測結(jié)果；HTTPDNS 遞歸節(jié)點日志。

數(shù)據(jù)范圍：主流CDN廠商的解析結(jié)果。

• 網(wǎng)段歸屬判斷：

若相鄰客戶端IP的CDN IP 歸屬同一運營商，則該組CIP可合并為連續(xù)網(wǎng)段。

將合并后的連續(xù)網(wǎng)段輸出，作為探測網(wǎng)段數(shù)據(jù)集。

2. 一致性校驗

• 將探測網(wǎng)段數(shù)據(jù)集與存量CIDRDB網(wǎng)段庫進(jìn)行逐網(wǎng)段對比，檢查 “映射一致性”。
• 若存在映射不一致，則觸發(fā)網(wǎng)段調(diào)整流程。

3. 網(wǎng)段調(diào)整

• 合并：探測數(shù)據(jù)集的網(wǎng)段比現(xiàn)有庫粗，合并為大網(wǎng)段。
• 拆分：探測數(shù)據(jù)集的網(wǎng)段比現(xiàn)有庫細(xì)，拆分為小網(wǎng)段。

4. 結(jié)果輸出

• 生成優(yōu)化后的新CIDRDB網(wǎng)段庫。
• 替換存量網(wǎng)段庫，實現(xiàn)動態(tài)更新。

5. 持續(xù)迭代

• 重復(fù)上述流程，實現(xiàn)網(wǎng)段庫的自適應(yīng)動態(tài)劃分。

緩存策略優(yōu)化

為解決緩存粒度細(xì)化可能導(dǎo)致的命中率下降問題，Cache2.0 引入了四重優(yōu)化策略，最終實現(xiàn)了如下收益：

緩存命中率提高了15%，緩存量、CPU 使用和出網(wǎng)流量降低了約70%。

1. 兩級一致性哈希分流

火山 HTTPDNS 的流量轉(zhuǎn)發(fā)以一致性哈希思想為核心，將用戶請求鏈路（用戶→LB→緩存層→遞歸層）拆分為兩級哈希調(diào)度：

一級調(diào)度（LB→緩存層）：以“源 IP + 域名”為哈希鍵。使用LB的一致性哈希策略，將同一用戶對同一域名的請求統(tǒng)一路由至固定的 HTTPDNS 節(jié)點，避免傳統(tǒng)輪詢導(dǎo)致的請求分散。

二級調(diào)度（緩存層→遞歸層）：以“域名 + 網(wǎng)段” 為哈希鍵。以 “域名 + 客戶端網(wǎng)段” 作為哈希鍵，與緩存粒度完全對齊，確保某一“域名 + 網(wǎng)段”對應(yīng)的查詢請求均定向到唯一的遞歸層節(jié)點。

兩級哈希協(xié)同調(diào)度，解決了緩存的碎片化問題，同時單一節(jié)點故障影響范圍極小。

2. 緩存分級管理

在 HTTPDNS 場景中，不同域名對解析精度的需求不同。高優(yōu)先級域名（如API 調(diào)用、直播 / 點播流媒體分發(fā)）對解析精準(zhǔn)性要求高，跨網(wǎng)可能導(dǎo)致訪問延遲增加；而低精度需求域名（如302域名）采用過細(xì)緩存會浪費存儲資源，頻繁回源也會增加權(quán)威 DNS 壓力。

為實現(xiàn)緩存資源的精細(xì)化分配，火山 HTTPDNS 將緩存體系劃分為“網(wǎng)段緩存、城市 - 運營商緩存、全局緩存” 三級，各級緩存適配不同應(yīng)用場景。

• 網(wǎng)段緩存：作為最高精度層級，聚焦高優(yōu)先級業(yè)務(wù)場景 ：一方面適配高優(yōu)域名（如抖音 API 調(diào)用、圖片分發(fā)、點播 / 直播流媒體傳輸?shù)葘珳?zhǔn)性敏感的域名），另一方面服務(wù)重點集群（如 ToB 企業(yè) HTTPDNS 服務(wù)、ToB 專屬公共 DNS 服務(wù)），通過網(wǎng)段級細(xì)粒度緩存確保解析結(jié)果與用戶實際網(wǎng)絡(luò)鏈路高度匹配，降低訪問延遲。
  
• 城市 - 運營商緩存：定位中等精度層級，適配普通域名場景：針對調(diào)度精準(zhǔn)度要求較低的域名，以 “城市 + 運營商” 為緩存單元，平衡緩存命中率與存儲開銷。
  
• 全局緩存：作為基礎(chǔ)精度層級，專門適配非智能解析域名：針對不支持 CDN 動態(tài)調(diào)度、解析結(jié)果無地域 / 運營商差異的域名（如靜態(tài)官網(wǎng)、通用工具類服務(wù)域名），采用全局統(tǒng)一緩存策略，所有用戶查詢共享同一緩存結(jié)果，最大化提升緩存命中率，降低回源請求壓力。

3. 緩存更新分級策略

在 HTTPDNS 系統(tǒng)中，統(tǒng)一的主動刷新策略雖然能保證緩存命中率，但存在明顯問題：對不需要精細(xì)調(diào)度的域名浪費了存儲資源，增加了下游壓力。

基于以上問題，火山 HTTPDNS引入 “主動刷新 + 被動刷新”分級策略，以域名優(yōu)先級和業(yè)務(wù)需求為依據(jù)，將緩存更新機(jī)制分為兩類：

• 后臺線程主動刷新機(jī)制：針對高優(yōu)域名（白名單），保留后臺線程主動刷新，確保緩存持續(xù)有效、用戶請求直接命中最新數(shù)據(jù)。
• 用戶請求被動刷新機(jī)制：針對普通域名或非智能解析域名，由請求觸發(fā)緩存更新，按需刷新，無需常駐后臺刷新線程，降低資源消耗。

通過這種分級更新策略，高優(yōu)先級域名仍能保證低延遲和高命中率，同時普通域名的刷新開銷顯著降低。

4. 緩存預(yù)取機(jī)制

依托 “緩存空間局部性原理”，火山 HTTPDNS 設(shè)計了緩存預(yù)取機(jī)制。當(dāng)某條緩存請求（如 A 網(wǎng)段域名解析）觸發(fā)更新時，系統(tǒng)不僅刷新目標(biāo)網(wǎng)段緩存，還會同步更新與其具有 “親緣關(guān)系” 的網(wǎng)段緩存（“親緣關(guān)系”指地理相鄰、同運營商節(jié)點覆蓋的網(wǎng)段）。這種 “單次請求觸發(fā)批量預(yù)取” 的設(shè)計能夠提前將關(guān)聯(lián)網(wǎng)段緩存置于準(zhǔn)備狀態(tài)，提升后續(xù)請求的命中率。

以抖音直播域名的實際訪問場景為例，預(yù)取機(jī)制的運作過程如下：

• 本網(wǎng)段更新：當(dāng)用戶 A（IP 歸屬北京聯(lián)通 10.0.1.0/24 網(wǎng)段）發(fā)起直播域名解析請求時，系統(tǒng)首先刷新其所屬的 10.0.1.0/24 網(wǎng)段緩存。
• 預(yù)取更新：系統(tǒng)同時刷新與 10.0.1.0/24 網(wǎng)段具有親緣關(guān)系的網(wǎng)段緩存，例如北京聯(lián)通下的相鄰網(wǎng)段（10.0.2.0/24、10.0.3.0/24），確保這些網(wǎng)段緩存也處于準(zhǔn)備狀態(tài)。

隨后，當(dāng)用戶 B（10.0.2.0/24）或用戶 C（10.0.10.0/24）發(fā)起相同直播域名的解析請求時，由于對應(yīng)網(wǎng)段緩存已提前預(yù)取，無需等待回源即可直接命中緩存，顯著降低訪問延遲。

三、全鏈路效能提升

1. 服務(wù)端調(diào)度精準(zhǔn)度提高

借助網(wǎng)段級緩存，用戶獲取的 IP 地址更加精準(zhǔn)。按服務(wù)端日志數(shù)據(jù)口徑，調(diào)度不準(zhǔn)比例從萬分之六下降至萬分之二，降幅 60%，有效緩解了傳統(tǒng)粗粒度緩存導(dǎo)致的“城市級緩存污染”問題。

2. 客戶端性能優(yōu)化

• 成功率：核心 feed 接口，在弱網(wǎng)+非連接復(fù)用場景下提升 1.15%。
• 耗時：非連接復(fù)用場景耗時減少14ms。

3. 用戶體驗提升

• 性能指標(biāo)：首刷及啟動耗時下降。
• 用戶指標(biāo)：用戶行為指標(biāo)（send 與 click）正向，用戶活躍度提升。

本方案通過服務(wù)端精準(zhǔn)調(diào)度 → 客戶端性能優(yōu)化 → 用戶體驗提升，實現(xiàn)了全鏈路效能提升。

四、持續(xù)演進(jìn)方向

共享緩存

目前，各機(jī)房的負(fù)載均衡策略與緩存策略未能完全對齊（部分采用隨機(jī)轉(zhuǎn)發(fā)，部分雖然使用一致性哈希但粒度不一致），導(dǎo)致同一數(shù)據(jù)在多個實例中被重復(fù)緩存，資源利用率偏低，緩存命中率也有待提升。

未來，我們計劃構(gòu)建一個分層共享的高可用緩存體系：

• 在同一機(jī)房內(nèi)，實例通過一致性哈希協(xié)同分工，每臺實例既是分片緩存，也能代理轉(zhuǎn)發(fā)請求，從而減少重復(fù)存儲并提升命中率。
• 在跨機(jī)房層面，按區(qū)域部署二級緩存節(jié)點，作為容量更大、延遲更低的共享中心，承接一級未命中的請求，降低跨區(qū)域訪問和上游壓力。與此同時，引入熱點數(shù)據(jù)副本、請求合并和故障轉(zhuǎn)移等機(jī)制，保證高并發(fā)和異常情況下的穩(wěn)定性與可用性。

通過這一演進(jìn)，整體架構(gòu)將逐步升級為層次化、分布式且具備高可用能力的緩存網(wǎng)絡(luò)，為業(yè)務(wù)的持續(xù)擴(kuò)展提供堅實支撐。