Django 源碼小剖: 更高效的 URL 調度器(URL dispatcher)

效率問題

django 內部的 url 調度機制說白了就是給一張有關匹配信息的表, 這張表中有着 url -> action 的映射, 當請求到來的時候, 一個一個(遍歷)去匹配. 中, 則調用 action, 產生相應數據返回; 不中, 則會產生 404 等的錯誤, 而 django 中有內置 404 等錯誤響應方法.

這種方法和 MFC 裏 message map 差很少, 從項目實踐(特別是配置 urls.py 文件)就能夠猜到大概是這樣一種工做模式.

注意上面關於 django url 調度機制的白話描述中的「一個一個」, 這裏就有效率上的問題了. 假若業務邏輯不復雜, 且訪問量不高, 系統是沒有問題的; 但若是業務邏輯太複雜(直觀的表述是 urls.py 中的匹配條目繁雜), 如此加之高訪問量, 會加劇系統的負擔, 試想最壞的狀況是每個請求都會從頭至尾匹配一次, 讓人感到不爽.

一種更好的解決方法

策略仍是有的, 由於業務邏輯不會常常變動, 至少不會沒幾分鐘就變動一次, 因此能夠藉助哈希表來達到快速匹配的目的. 有關哈希表能夠參照以前寫的一篇文章: 私房STL之hash_set和hash_map

哈希表

通常的作法舉例以下:

http://example.com/aaaaa/
http://example.com/bbbbb/
http://example.com/ccccc/
http://example.com/ddddd/
http://example.com/eeeee/
abcde 表示 web 應用的功能模塊.

爲 aaaaa,bbbbb...都計算獲得哈希值 hash(aaaaa),hash(bbbbb)...

當請求 http://example.com/aaaaa/ 到來時候, 提取 aaaaa, 計算哈希值直接在哈希表中定位匹配條目. 通常的作法是這樣, 還能夠順着這樣的思路繼續改進. 譬如, 存在更爲複雜的功能, 並且這個功能在 aaaaa 的基礎上創建起來: http://example.com/aaaaa/xxxxx, 這時候, 也能夠計算 hash(aaaaaxxxxx) 加入到哈希表中.

那是否是每一個請求到來啓動 web 應用程序的時候都要計算 urls.py 中的條目的哈希值? 並不須要, 能夠新建一個 url 服務進程, 只專門維護哈希表, 從 urls.py 中計算哈希表; 通由內存映射技術, web 應用程序能夠方便讀取哈希表, 而且能夠重複利用.

什麼提到會調用 url 對應的 action, 並返回響應數據, django 是怎麼返回的. 我已經在 github 備份了 Django 源碼的註釋: Decode-Django, 有興趣的童鞋 fork 吧.

搗亂 2013-9-18

http://daoluan.net