dns的遞歸解析過程還是挺繁瑣的，要知道一個域名可能有cname、ns 而請求的cname、ns可能還有cname、ns，如果按照線性的處理每個請求那邏輯就變成毛線團了

dnspod的處理還是挺巧妙的，通過一個公共的數據集dataset將所有域名對應的a、cname、ns等類型的數據作為單獨的條目存入，當有需要某個域名的信息時先去dataset找，找不到在加入qlist請求根，有專門的線程不間斷的將qlist輪詢dataset找（這里只要次數允許，沒得到想要的結果就輪詢所有qlist到dataset找雖然可以簡化邏輯分離的徹底但是會是個性能瓶頸，后面有方案）當根返回以后只是簡單的將記錄(通常是一個域名的cname、ns或者a)存入dataset(而不是繼續流程，因為根據這個返回是cname還是ns或者a處理不同邏輯復雜，而這樣處理對于用到相同域名的請求還有優化作用)，剩下的工作交給那邊不間斷輪詢的線程

Dnspod主要由3個run（若干個線程）組成

run_sentinel  監聽53端口接收客戶端請求，將請求放到隊列中

run_fetcher   從隊列中取出請求，根據qname取得最后一級cname，查看本地dataset 是否有記錄，如果有則返回，沒有則將該請求放入qlist中

run_quizzer    

1.不間斷的遍歷qlist，只要狀態為PROCESS_QUERY且dataset中沒有的就向對應的根發送請求。

2.通過epoll等待根返回，解析返回的數據加入 dataset

3.檢查記錄的ttl，在將記錄加入dataset時還會將這些記錄以紅黑樹的形式組織起來，取得ttl最早到期的，將其放入qlist中等待刷新，注意這里不是刪除，如果收不到不返回則該記錄一直存在

關于dataset的實現

dataset是使用哈希表實現的，本質上是個二維數組，將域名哈希成一個值，模上數組的數量作為下標，找到對應的數組接著遍歷查找，根據需要可以擴大數組的數量提升性能。

我們的優化手段

之前提到dnspod的qlist會不間斷輪詢，屬于主動查詢，對性能有不小的影響，這里我們采取的做法是被動(類似回調的方式)，我們將請求的域名和類型分類，相同的放在一組，當dataset找不到向根發出請求后我們并不每次主動輪詢，而是在等到應答后，觸發該域名和類型的請求組，讓他們根據自己的邏輯走下一步（一般是先找該域名的最后一級cname，根據這個cname查是否存在他的對應請求類型的記錄，一般是a或者ns，如果沒有，則找這個cname的ns）

以上可以看出dataset很重要，負載也不小，還經常需要并發訪問，這里我們每次接收到根的回復后，除了將記錄的答案加進dataset，還創建一個臨時的dataset，只存該次回復的信息，在后面的流程會優先到這里去找，沒有的再找dataset。