本發(fā)明涉及互聯(lián)網(wǎng)高速緩存應(yīng)用技術(shù)領(lǐng)域,特別是涉及一種域名解析請求的處理方法、裝置及服務(wù)器。
背景技術(shù):
Nginx是一個高性能的HTTP(Hyper Text Transfer Protocol,超文本傳輸協(xié)議)和反向代理服務(wù)器,也是一個IMAP(Internet Mail Access Protocol,因特網(wǎng)郵件訪問協(xié)議)/POP3(Post Office Protocol-Version 3,郵局協(xié)議版本3)/STMP(Simple Mail Transfer Protocol,簡單郵件傳輸協(xié)議)代理服務(wù)器。使用Nginx搭建的高速緩存Cache服務(wù)器,收到客戶端發(fā)送的HTTP(Hyper Text Transfer Protocol,超文本傳輸協(xié)議)請求后,先檢查請求文件是否已在本地磁盤存儲,如果有,直接取本地存儲文件發(fā)給客戶端,如果沒有,需要代理客戶端向源站獲取請求的文件,這個動作稱為回源?;卦窗ㄒ韵虏襟E:第一步是進(jìn)行域名解析,獲取源站IP地址,第二步是向源站發(fā)送HTTP請求,第三步是接收請求的文件,發(fā)送給客戶端,并根據(jù)HTTP響應(yīng)頭字段確定是否緩存到本地磁盤。在回源第一步的域名解析中,Nginx可以配置多個DNS(Domain Name System,計(jì)算機(jī)域名系統(tǒng))服務(wù)器,但是會采用輪詢調(diào)度Round Robin的方式輪流查詢,即第一個解析請求發(fā)給DNS服務(wù)器1,第二個解析請求發(fā)給DNS服務(wù)器2,第n個請求發(fā)給DNS服務(wù)器n。當(dāng)某個DNS服務(wù)器異常時(shí),Nginx發(fā)送的域名解析請求可能會超時(shí)收不到響應(yīng)或者可能收到服務(wù)失敗server failure的響應(yīng),這樣Nginx就會回源失敗,從而導(dǎo)致客戶端服務(wù)失敗,影響用戶體驗(yàn)。
技術(shù)實(shí)現(xiàn)要素:
本發(fā)明的目的在于提供一種域名解析請求的處理方法,用以解決現(xiàn)有技術(shù) 中服務(wù)器域名回源時(shí)因某個DNS服務(wù)器異常導(dǎo)致回源失敗,從而使得用戶設(shè)備無法獲取請求資源的問題。
為了實(shí)現(xiàn)上述目的,本發(fā)明實(shí)施例提供一種域名解析請求的處理方法,包括:
接收攜帶有域名信息的域名解析請求;
根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求;
接收所述第一服務(wù)器根據(jù)所述域名解析請求中的域名信息返回的域名解析有效響應(yīng)消息;
根據(jù)所述域名解析有效響應(yīng)消息,從源站獲取請求資源。
其中,根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的步驟包括:
按照配置文件中對多個第一服務(wù)器設(shè)置的優(yōu)先級順序,由高到低依次向一第一服務(wù)器發(fā)送所述域名解析請求。
其中,根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的步驟包括:
同時(shí)向配置文件中多個第一服務(wù)器發(fā)送域名解析請求。
其中,所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的源站IP地址。
其中,根據(jù)所述域名解析有效響應(yīng)消息,從源站獲取請求資源的步驟包括:
向第二服務(wù)器發(fā)送所述域名解析有效響應(yīng)消息,使所述第二服務(wù)器與所述源站建立資源請求連接;
通過所述第二服務(wù)器與所述源站的資源請求連接,從源站獲取請求資源。
其中,還包括:
在接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息時(shí),停止向下一個第一服務(wù)器發(fā)送所述域名解析請求;或者
在接收到所述第一服務(wù)器返回的域名解析失敗消息或域名解析請求超時(shí)無響應(yīng)時(shí),向下一個第一服務(wù)器發(fā)送所述域名解析請求,直到接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息為止。
本發(fā)明實(shí)施例還提供一種域名解析請求的處理裝置,包括:
第一接收模塊,用于接收攜帶有域名信息的域名解析請求;
發(fā)送模塊,用于根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求;
第二接收模塊,用于接收所述第一服務(wù)器根據(jù)所述域名解析請求中的域名信息返回的域名解析有效響應(yīng)消息;
資源獲取模塊,用于根據(jù)所述域名解析有效響應(yīng)消息,從源站獲取請求資源。
其中,所述發(fā)送模塊包括:
優(yōu)先級發(fā)送子模塊,用于按照配置文件中對多個第一服務(wù)器設(shè)置的優(yōu)先級順序,由高到低依次向一第一服務(wù)器發(fā)送所述域名解析請求。
其中,所述發(fā)送模塊包括:
同時(shí)發(fā)送子模塊,用于同時(shí)向配置文件中多個第一服務(wù)器發(fā)送域名解析請求。
其中,所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的源站IP地址。
其中,所述資源獲取模塊包括:
發(fā)送子模塊,用于向第二服務(wù)器發(fā)送所述域名解析有效響應(yīng)消息,使所述第二服務(wù)器與所述源站建立資源請求連接;
資源獲取子模塊,用于通過所述第二服務(wù)器與所述源站的資源請求連接,從源站獲取請求資源。
其中,還包括:
第一發(fā)送處理模塊,用于在接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息時(shí),停止向下一個第一服務(wù)器發(fā)送所述域名解析請求;
第二發(fā)送處理模塊,用于在接收到所述第一服務(wù)器返回的域名解析失敗消息或域名解析請求超時(shí)無響應(yīng)時(shí),向下一個第一服務(wù)器發(fā)送所述域名解析請求,直到接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息為止。
本發(fā)明實(shí)施例還提供一種服務(wù)器,包括如上述實(shí)施例所述的域名解析請求的處理裝置。
本發(fā)明的上述技術(shù)方案的有益效果如下:
本發(fā)明的上述方案中,通過采用預(yù)設(shè)的域名解析模式向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名 回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
附圖說明
圖1為本發(fā)明實(shí)施例域名解析請求的處理方法的基本步驟示意圖;
圖2為本發(fā)明實(shí)施例域名解析請求的處理裝置的組成結(jié)構(gòu)示意圖;
圖3為本發(fā)明實(shí)施例域名解析請求的處理方法中根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的第一具體處理流程框圖;
圖4為本發(fā)明實(shí)施例域名解析請求的處理方法中根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的第二具體處理流程框圖;
圖5為本發(fā)明實(shí)施例基于DNS代理服務(wù)器的域名解析系統(tǒng)基本框圖。
具體實(shí)施方式
為使本發(fā)明要解決的技術(shù)問題、技術(shù)方案和優(yōu)點(diǎn)更加清楚,下面將結(jié)合附圖及具體實(shí)施例進(jìn)行詳細(xì)描述。
本發(fā)明針對現(xiàn)有技術(shù)中服務(wù)器域名回源時(shí)因某個DNS服務(wù)器異常導(dǎo)致回源失敗,從而使得用戶設(shè)備無法獲取請求資源的問題,提供一種域名解析請求的處理方法,通過采用預(yù)設(shè)的域名解析模式向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
第一實(shí)施例
如圖1所示,本發(fā)明實(shí)施例提供一種域名解析請求的處理方法,包括:
步驟11,接收攜帶有域名信息的域名解析請求;
步驟12,根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求;
這里,第一服務(wù)器可以是DNS服務(wù)器,當(dāng)然也可以是其他具有域名解析功能的服務(wù)器。
步驟13,接收所述第一服務(wù)器根據(jù)所述域名解析請求中的域名信息返回的域名解析有效響應(yīng)消息;
步驟14,根據(jù)所述域名解析有效響應(yīng)消息,從源站獲取請求資源。
本發(fā)明實(shí)施例的域名解析請求的處理方法,通過采用預(yù)設(shè)的域名解析模式向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
優(yōu)選地,本發(fā)明實(shí)施例中所述步驟12可以進(jìn)一步包括:
步驟121,按照配置文件中對多個第一服務(wù)器設(shè)置的優(yōu)先級順序,由高到低依次向第一服務(wù)器發(fā)送所述域名解析請求。
這里,在配置文件中已預(yù)先設(shè)置了多個第一服務(wù)器的優(yōu)先級順序。優(yōu)先級設(shè)置的原則可以根據(jù)多個第一服務(wù)器的工作效率確定。比如,第一服務(wù)器域名解析式出現(xiàn)異常的概率等。
優(yōu)選地,本發(fā)明實(shí)施例中所述步驟12還可以進(jìn)一步包括:
步驟122,同時(shí)向配置文件中多個第一服務(wù)器發(fā)送域名解析請求
本步驟中,同時(shí)向多個第一服務(wù)器發(fā)送域名解析請求,當(dāng)該多個第一服務(wù)器中只要有一個第一服務(wù)器返回域名解析有效響應(yīng)消息,則本次域名解析成功。
這里,當(dāng)該多個第一服務(wù)器中不止一個第一服務(wù)器返回域名解析有效響應(yīng)消息時(shí),最先獲取的域名解析有效響應(yīng)消息被實(shí)際使用。本域名解析模式提高了域名解析的成功率及域名解析的效率。
具體的,本發(fā)明實(shí)施例中所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的源站IP地址。
優(yōu)選地,本發(fā)明實(shí)施例中所述步驟14可以進(jìn)一步包括:
步驟141,向第二服務(wù)器發(fā)送所述域名解析有效響應(yīng)消息,使所述第二服務(wù)器與所述源站建立資源請求連接;
這里,第二服務(wù)器可以是Nginx服務(wù)器。向第二服務(wù)器發(fā)送的域名解析有效響應(yīng)消息中包括域名解析請求中域名信息對應(yīng)的源站IP地址,第二服務(wù)器獲取該源站IP地址,根據(jù)所述IP地址查詢到所述源站,并與所述源站建立資源請求連接。
步驟142,通過所述第二服務(wù)器與所述源站的資源請求連接,從源站獲取請求資源。
本發(fā)明實(shí)施例的域名解析請求的處理方法,還包括:
步驟15,在接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息時(shí),停 止向下一個第一服務(wù)器發(fā)送所述域名解析請求;
步驟16,在接收到所述第一服務(wù)器返回的域名解析失敗消息或域名解析請求超時(shí)無響應(yīng)時(shí),向下一個第一服務(wù)器發(fā)送所述域名解析請求,直到接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息為止。
這里需要說明的是,步驟15及步驟16為本發(fā)明實(shí)施例中所述步驟121之后的具體處理步驟,如此提高了域名解析的成功率。
本發(fā)明的上述方案中,通過采用預(yù)設(shè)的域名解析模式向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
第二實(shí)施例
如圖2所示,本發(fā)明實(shí)施例還提供一種域名解析請求的處理裝置,包括:
第一接收模塊21,用于接收攜帶有域名信息的域名解析請求;
這里,域名信息是指由一串用點(diǎn)分隔的名字組成的因特網(wǎng)上某一臺計(jì)算機(jī)或計(jì)算機(jī)組的名稱,用于在數(shù)據(jù)傳輸時(shí)標(biāo)識計(jì)算機(jī)的電子方位。
發(fā)送模塊22,用于根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求;
這里,第一服務(wù)器可以是DNS服務(wù)器,當(dāng)然也可以是其他具有域名解析功能的服務(wù)器。
第二接收模塊23,用于接收所述第一服務(wù)器根據(jù)所述域名解析請求中的域名信息返回的域名解析有效響應(yīng)消息;
資源獲取模塊24,用于根據(jù)所述域名解析有效響應(yīng)消息,從源站獲取請求資源。
本發(fā)明實(shí)施例中所述發(fā)送模塊22可以具體包括:
優(yōu)先級發(fā)送子模塊,用于按照配置文件中對多個第一服務(wù)器設(shè)置的優(yōu)先級順序,由高到低依次向一第一服務(wù)器發(fā)送所述域名解析請求。
這里,所述配置文件中已預(yù)先設(shè)置了多個第一服務(wù)器的優(yōu)先級順序。優(yōu)先級設(shè)置的原則可以根據(jù)多個第一服務(wù)器的工作效率確定。比如,第一服務(wù)器域名解析式出現(xiàn)異常的概率等。
本發(fā)明實(shí)施例中所述發(fā)送模塊22還可以包括:
同時(shí)發(fā)送子模塊,用于同時(shí)向配置文件中多個第一服務(wù)器發(fā)送域名解析請求。
這里需說明的是,同時(shí)向多個第一服務(wù)器發(fā)送域名解析請求,當(dāng)該多個第一服務(wù)器中只要有一個第一服務(wù)器返回域名解析有效響應(yīng)消息,則本次域名解析成功。
這里,當(dāng)該多個第一服務(wù)器中不止一個第一服務(wù)器返回域名解析有效響應(yīng)消息時(shí),最先獲取的域名解析有效響應(yīng)消息被實(shí)際使用。本域名解析模式提高了域名解析的成功率及域名解析的速度。
具體的,所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的源站IP地址。
具體的,本發(fā)明實(shí)施例中所述資源獲取模塊24可以包括:
發(fā)送子模塊,用于向第二服務(wù)器發(fā)送所述域名解析有效響應(yīng)消息,使所述第二服務(wù)器與所述源站建立資源請求連接;
這里,第二服務(wù)器可以是Nginx服務(wù)器。向第二服務(wù)器發(fā)送的域名解析有效響應(yīng)消息中包括域名解析請求中域名信息對應(yīng)的源站IP地址,第二服務(wù)器獲取該源站IP地址,根據(jù)所述IP地址查詢到所述源站,并與所述源站建立資源請求連接。
資源獲取子模塊,用于通過所述第二服務(wù)器與所述源站的資源請求連接,從源站獲取請求資源。
本發(fā)明實(shí)施例的域名解析請求的處理裝置,還可包括:
第一發(fā)送處理模塊25,用于在接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息時(shí),停止向下一個第一服務(wù)器發(fā)送所述域名解析請求;
第二發(fā)送處理模塊26,用于在接收到所述第一服務(wù)器返回的域名解析失敗消息或域名解析請求超時(shí)無響應(yīng)時(shí),向下一個第一服務(wù)器發(fā)送所述域名解析請求,直到接收到任一第一服務(wù)器返回的域名解析有效響應(yīng)消息為止。
這里需要說明的是,第一發(fā)送處理模塊25及第二發(fā)送處理模塊26為本發(fā)明實(shí)施例中所述優(yōu)先級發(fā)送子模塊中的具體處理模塊。
本發(fā)明實(shí)施例還提供一種服務(wù)器,包括如上述實(shí)施例中所述的域名解析請求的處理裝置。
本發(fā)明的上述方案中,通過采用預(yù)設(shè)的域名解析模式向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
第三實(shí)施例
如圖3所示,為本發(fā)明實(shí)施例的域名解析請求的處理方法中根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的第一具體處理流程框圖。下面結(jié)合該圖具體說明該域名解析請求的處理流程。
為了更清楚的理解本發(fā)明實(shí)施例的域名解析請求的處理流程,這里,需要說明的是,該處理流程的實(shí)施的前提是,使用Nginx搭建的高速緩存Cache服務(wù)器,在接收到客戶端發(fā)送的HTTP請求后,檢測本地磁盤是否已緩存請求的資源,在確定本地沒有緩存所述請求的資源時(shí),需要增加一代理服務(wù)器來實(shí)施該域名解析請求的處理流程,最終獲取客戶端請求的資源。具體過程如下:
步驟301,客戶端向Nginx服務(wù)器發(fā)送HTTP請求;
這里,客戶端也稱為用戶端,是指與服務(wù)器相對應(yīng),為客戶提供本地服務(wù)的程序。
步驟302,Nginx服務(wù)器檢測本地磁盤是否已緩存請求的請求資源,,確定本地沒有緩存所述請求的請求資源;
步驟303,Nginx服務(wù)器向DNS代理服務(wù)器發(fā)送域名解析請求;
本步驟中,域名解析請求中攜帶有域名信息。
步驟304,DNS代理服務(wù)器按照配置文件中對多個DNS服務(wù)器設(shè)置的優(yōu)先級順序,由高到低依次向一DNS服務(wù)器發(fā)送所述域名解析請求;
步驟305,DNS服務(wù)器向DNS代理服務(wù)器回復(fù)應(yīng)答或DNS服務(wù)器異常不響應(yīng);
步驟306,DNS代理服務(wù)器在確定DNS回復(fù)的應(yīng)答為有效響應(yīng)時(shí),執(zhí)行步驟307,否則,執(zhí)行步驟304。
這里,在DNS代理服務(wù)器檢測到域名解析請求超時(shí)無響應(yīng)或接收到DNS服務(wù)器返回的無效應(yīng)答,返回執(zhí)行步驟304,向下一個DNS服務(wù)器發(fā)送所述域名解析請求。
步驟307,DNS代理服務(wù)器向Nginx服務(wù)器回復(fù)域名解析有效響應(yīng)消息;
這里,所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的IP地址。
步驟308,Nginx服務(wù)器與源站建立連接獲取客戶端請求的請求資源;
這里,Nginx服務(wù)器根據(jù)獲取的IP地址向源站發(fā)送HTTP請求,源站根據(jù)該HTTP請求返回對應(yīng)的請求資源。
步驟309,Nginx服務(wù)器將獲取到的請求資源發(fā)送給客戶端,并判斷是否緩存到本地磁盤。
這里,所述請求資源中攜帶有是否將所述請求資源緩存到本地磁盤的指示消息。
本發(fā)明的上述方案中,通過采用預(yù)設(shè)的域名解析模式,具體為按照配置文件中對多個第一服務(wù)器設(shè)置的優(yōu)先級順序,向至少一個服務(wù)器發(fā)送域名解析請求,提高了域名解析的成功率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
第四實(shí)施例
如圖4所示,為本發(fā)明實(shí)施例的域名解析請求的處理方法中根據(jù)預(yù)設(shè)的域名解析模式向至少一個第一服務(wù)器發(fā)送所述域名解析請求的第二具體處理流程框圖。下面結(jié)合該圖具體說明該域名解析請求的處理流程。
為了更清楚的理解本發(fā)明實(shí)施例的域名解析請求的處理流程,這里,需要說明的是,該處理流程的實(shí)施的前提是,使用Nginx搭建的高速緩存Cache服務(wù)器,在接收到客戶端發(fā)送的HTTP請求后,檢測本地磁盤是否已緩存請求的資源,在確定本地沒有緩存所述請求的資源時(shí),需要增加一代理服務(wù)器來實(shí)施該域名解析請求的處理流程,最終獲取客戶端請求的資源。具體過程如下:
步驟401,客戶端向Nginx服務(wù)器發(fā)送HTTP請求;
這里,客戶端也稱為用戶端,是指與服務(wù)器相對應(yīng),為客戶提供本地服務(wù)的程序。
步驟402,Nginx服務(wù)器檢測本地磁盤是否已緩存請求的請求資源,,確定本地沒有緩存所述請求的請求資源;
步驟403,Nginx服務(wù)器向DNS代理服務(wù)器發(fā)送域名解析請求;
本步驟中,域名解析請求中攜帶有域名信息。
步驟404,DNS代理服務(wù)器同時(shí)向配置文件中多個DNS服務(wù)器發(fā)送所述 域名解析請求;
這里,DNS服務(wù)器一次性同時(shí)向多個DNS服務(wù)器發(fā)送所述域名解析請求。
步驟405,DNS服務(wù)器向DNS代理服務(wù)器回復(fù)應(yīng)答;
這里,配置文件中的多個DNS服務(wù)器中只要有一個DNS服務(wù)器返回域名解析有效響應(yīng)消息,則本次域名解析成功。
當(dāng)所述多個DNS服務(wù)器中不止一個DNS服務(wù)器返回域名解析有效響應(yīng)消息時(shí),最先獲取的域名解析有效響應(yīng)消息被實(shí)際使用。本域名解析模式提高了域名解析的成功率及域名解析的速度。
步驟406,DNS代理服務(wù)器將最先獲取的域名解析有效響應(yīng)消息發(fā)送給Nginx服務(wù)器;
這里,所述域名解析有效響應(yīng)消息包括所述域名信息對應(yīng)的IP地址。
步驟407,Nginx服務(wù)器與源站建立連接獲取客戶端請求的請求資源;
這里,Nginx服務(wù)器根據(jù)獲取的IP地址向源站發(fā)送HTTP請求,源站根據(jù)該HTTP請求返回對應(yīng)的請求資源。
步驟408,Nginx服務(wù)器將獲取到的請求資源發(fā)送給客戶端,并判斷是否緩存到本地磁盤。
這里,所述請求資源中攜帶有是否將所述請求資源緩存到本地磁盤的指示消息。
需要說明的是,本發(fā)明實(shí)施例及上述第三實(shí)施例中域名解析請求的處理方法均可在如圖5所示的域名解析系統(tǒng)基本框架下實(shí)施。
本發(fā)明的上述方案中,通過采用預(yù)設(shè)的域名解析模式,具體為同時(shí)向配置文件中多個第一服務(wù)發(fā)送域名解析請求,提高了域名解析的成功率及域名解析效率,保證服務(wù)器域名回源時(shí)用戶設(shè)備能獲取到其請求的資源,提升了用戶體驗(yàn)。
以上所述是本發(fā)明的優(yōu)選實(shí)施方式,應(yīng)當(dāng)指出,對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說,在不脫離本發(fā)明所述原理的前提下,還可以作出若干改進(jìn)和潤飾,這些改進(jìn)和潤飾也應(yīng)視為本發(fā)明的保護(hù)范圍。