dns的遞歸解析過程還是挺繁瑣的，要知道一個域名可能有cname、ns 而請求的cname、ns可能還有cname、ns，如果按照線性的處理每個請求那邏輯就變成毛線團了
dnspod的處理還是挺巧妙的，通過一個公共的數(shù)據(jù)集dataset將所有域名對應(yīng)的a、cname、ns等類型的數(shù)據(jù)作為單獨的條目存入，當有需要某個域名的信息時先去dataset找，找不到在加入qlist請求根，有專門的線程不間斷的將qlist輪詢dataset找（這里只要次數(shù)允許，沒得到想要的結(jié)果就輪詢所有qlist到dataset找雖然可以簡化邏輯分離的徹底但是會是個性能瓶頸，后面有方案）當根返回以后只是簡單的將記錄(通常是一個域名的cname、ns或者a)存入dataset(而不是繼續(xù)流程，因為根據(jù)這個返回是cname還是ns或者a處理不同邏輯復(fù)雜，而這樣處理對于用到相同域名的請求還有優(yōu)化作用)，剩下的工作交給那邊不間斷輪詢的線程
Dnspod主要由3個run（若干個線程）組成
run_sentinel 監(jiān)聽53端口接收客戶端請求，將請求放到隊列中
run_fetcher 從隊列中取出請求，根據(jù)qname取得最后一級cname，查看本地dataset 是否有記錄，如果有則返回，沒有則將該請求放入qlist中
run_quizzer
1.不間斷的遍歷qlist，只要狀態(tài)為PROCESS_QUERY且dataset中沒有的就向?qū)?yīng)的根發(fā)送請求。
2.通過epoll等待根返回，解析返回的數(shù)據(jù)加入 dataset
3.檢查記錄的ttl，在將記錄加入dataset時還會將這些記錄以紅黑樹的形式組織起來，取得ttl最早到期的，將其放入qlist中等待刷新，注意這里不是刪除，如果收不到不返回則該記錄一直存在
關(guān)于dataset的實現(xiàn)
dataset是使用哈希表實現(xiàn)的，本質(zhì)上是個二維數(shù)組，將域名哈希成一個值，模上數(shù)組的數(shù)量作為下標，找到對應(yīng)的數(shù)組接著遍歷查找，根據(jù)需要可以擴大數(shù)組的數(shù)量提升性能。
我們的優(yōu)化手段
之前提到dnspod的qlist會不間斷輪詢，屬于主動查詢，對性能有不小的影響，這里我們采取的做法是被動(類似回調(diào)的方式)，我們將請求的域名和類型分類，相同的放在一組，當dataset找不到向根發(fā)出請求后我們并不每次主動輪詢，而是在等到應(yīng)答后，觸發(fā)該域名和類型的請求組，讓他們根據(jù)自己的邏輯走下一步（一般是先找該域名的最后一級cname，根據(jù)這個cname查是否存在他的對應(yīng)請求類型的記錄，一般是a或者ns，如果沒有，則找這個cname的ns）
以上可以看出dataset很重要，負載也不小，還經(jīng)常需要并發(fā)訪問，這里我們每次接收到根的回復(fù)后，除了將記錄的答案加進dataset，還創(chuàng)建一個臨時的dataset，只存該次回復(fù)的信息，在后面的流程會優(yōu)先到這里去找，沒有的再找dataset。