《資料結構與演算法之美》專欄最重要的基礎篇馬上就要講完了，我從前面的文章中挑選了幾個例子，稍加修改，組成了一套測試題。你先不要著急看答案，自己先想一想怎麼解決，測一測自己對之前的知識掌握的程度。
\n如果有**卡殼或者不怎麼清楚的，可以回過頭再複習一下。正所謂溫故知新，這種通過實際問題查缺補漏的學習方法，非常利於你鞏固前面講的知識點，你可要好好珍惜這次機會哦！
\n\n
\n\n
相關章節
\n17 | 跳表：為什麼redis一定要用跳表來實現有序集合？
\n題目解析
\n這個問題既要通過id來查詢，又要通過積分來查詢，所以，對於獵頭這樣乙個物件，我們需要將其組織成兩種資料結構，才能支援這兩類操作。
\n我們按照id，將獵頭資訊組織成雜湊表。這樣，就可以根據id資訊快速的查詢、刪除、更新獵頭的資訊。我們按照積分，將獵頭資訊組織成跳表這種資料結構，按照積分來查詢獵頭資訊，就非常高效，時間複雜度是o(logn)。
\n我剛剛講的是針對第乙個、第二個操作的解決方案。第三個、第四個操作是類似的，按照排名來查詢，這兩個操作該如何實現呢？
\n我們可以對剛剛的跳表進行改造，每個索引結點中加入乙個span欄位，記錄這個索引結點到下乙個索引結點的包含的鍊錶結點的個數。這樣就可以利用跳表索引，快速計算出排名在某一位的獵頭或者排名在某個區間的獵頭列表。
\n實際上，這些就是redis中有序集合這種資料型別的實現原理。在開發中，我們並不需要從零開始**實現乙個雜湊表和跳表，我們可以直接利用redis的有序集合來完成。
\n\n
電商交易系統中，訂單資料一般都會很大，我們一般都分庫分表來儲存。假設我們分了10個庫並儲存在不同的機器上，在不引入複雜的分庫分表中介軟體的情況下，我們希望開發乙個小的功能，能夠快速地查詢金額最大的前k個訂單（k是輸入引數，可能是1、10、1000、10000，假設最大不會超過10萬）。如果你是這個功能的設計開發負責人，你會如何設計乙個比較詳細的、可以落地執行的設計方案呢？
\n為了方便你設計，我先交代一些必要的背景，在設計過程中，如果有其他需要明確的背景，你可以自行假設。
\n\n
相關章節
\n12 | 排序（下）：如何用快排思想在o(n)內查詢第k大元素？
\n題目解析
\n解決這個題目的基本思路我想你應該能想到，就是借助歸併排序中的合併函式，這個我們在排序（下）以及堆的應用那一節中講過。
\n我們從每個資料庫中，通過select order by limit語句，各取區域性金額最大的訂單，把取出來的10個訂單放到優先順序佇列中，取出最大值（也就是大頂堆堆頂資料），就是全域性金額最大的訂單。然後再從這個全域性金額最大訂單對應的資料庫中，取出下一條訂單（按照訂單金額從大到小排列的），然後放到優先順序佇列中。一直重複上面的過程，直到找到金額前k（k是使用者輸入的）大訂單。
\n從演算法的角度看起來，這個方案非常完美，但是，從實戰的角度來說，這個方案並不高效，甚至很低效。因為我們忽略了，資料庫讀取資料的效能才是這個問題的效能瓶頸。所以，我們要儘量減少sql請求，每次多取一些資料出來，那一次性取出多少才合適呢？這就比較靈活、比較有技巧了。一次性取太多，會導致資料量太大，sql執行很慢，還有可能觸發超時，而且，我們題目中也說了，記憶體有限，太多的資料載入到記憶體中，還有可能導致oom。
\n所以，一次性不能取太多資料，也不能取太少資料，到底是多少，還要根據實際的硬體環境做benchmark測試去找最合適的。
\n\n
我們知道，cpu資源是有限的，任務的處理速度與執行緒個數並不是線性正相關。相反，過多的執行緒反而會導致cpu頻繁切換，處理效能下降。所以，執行緒池的大小一般都是綜合考慮要處理任務的特點和硬體環境，來事先設定的。
\n當我們向固定大小的執行緒池中請求乙個執行緒時，如果執行緒池中沒有空閒資源了，這個時候執行緒池如何處理這個請求？是拒絕請求還是排隊請求？各種處理策略又是怎麼實現的呢？
\n相關章節
\n題目解析
\n這個問題的答案涉及佇列這種資料結構。佇列可以應用在任何有限資源池中，用於排隊請求，比如資料庫連線池等。實際上，對於大部分資源有限的場景，當沒有空閒資源時，基本上都可以通過「佇列」這種資料結構來實現請求排隊。
\n這個問題的具體答案，在佇列那一節我已經講得非常詳細了，你可以回去看看，這裡我就不贅述了。
\n\n
這個功能並不複雜，它是通過維護乙個很大的ip位址庫來實現的。位址庫中包括ip位址範圍和歸屬地的對應關係。比如，當我們想要查詢202.102.133.13這個ip位址的歸屬地時，我們就在位址庫中搜尋，發現這個ip位址落在[202.102.133.0, 202.102.133.255]這個位址範圍內，那我們就可以將這個ip位址範圍對應的歸屬地「山東東營市」顯示給使用者了。
\n
[202.102.133.0, 202.102.133.255] 山東東營市 \n[202.102.135.0, 202.102.136.255] 山東煙台 \n[202.102.156.34, 202.102.157.255] 山東青島 \n[202.102.48.0, 202.102.48.255] 江蘇宿遷 \n[202.102.49.15, 202.102.51.251] 江蘇泰州 \n[202.102.56.0, 202.102.56.255] 江蘇連雲港\n在龐大的位址庫中逐一比對ip位址所在的區間，是非常耗時的。假設在記憶體中有12萬條這樣的ip區間與歸屬地的對應關係，如何快速定位出乙個ip位址的歸屬地呢？
\n相關章節
\n15 | 二分查詢（上）：如何用最省記憶體的方式實現快速查詢功能？
\n題目解析
\n這個問題可以用二分查詢來解決，不過，普通的二分查詢是不行的，我們需要用到二分查詢的變形演算法，查詢最後乙個小於等於某個給定值的資料。不過，二分查詢最難的不是原理，而是實現。要實現乙個二分查詢的變形演算法，並且實現的**沒有bug，可不是一件容易的事情，不信你自己寫寫試試。
\n關於這個問題的解答以及寫出bug free的二分查詢**的技巧，我們在二分查詢（下）那一節有非常詳細的講解，你可以回去看看，我這裡就不贅述了。
\n\n
\n我們希望自助開發乙個簡單的系統，不希望借助和維護過於複雜的三方系統，比如資料庫（mysql、redis等）、分布式儲存系統（gfs、bigtable等），並且我們單台機器的效能有限，比如硬碟只有1tb，記憶體只有2gb，如何設計乙個符合我們上面要求，操作高效，且使用機器資源最少的儲存系統呢？
\n\n
題目解析
\n這個問題可以分成兩部分，第一部分是根據元資訊的搜尋功能，第二部分是判重。
\n第一部分，我們可以借助搜尋引擎中的倒排索引結構。關於倒排索引我會在實戰篇詳細講解，我這裡先簡要說下。
\n第二部分關於判重，我們要基於本身來判重，所以可以用雜湊演算法，對內容取雜湊值。我們對雜湊值建立雜湊表，這樣就可以通過雜湊值以及雜湊表，快速判斷是否存在。
\n我這裡只說說我的思路，這個問題中還有詳細的記憶體和硬碟的限制。要想給出更加詳細的設計思路，還需要根據這些限制，給出乙個估算。詳細的解答，我都放在在雜湊演算法（下）那一節裡到了，你可以自己回去看。
\n\n
我們知道，雜湊表的查詢效率並不能籠統地說成是o(1)。它跟雜湊函式、裝載因子、雜湊衝突等都有關係。如果雜湊函式設計得不好，或者裝載因子過高，都可能導致雜湊衝突發生的概率公升高，查詢效率下降。
\n在極端情況下，有些惡意的攻擊者，還有可能通過精心構造的資料，使得所有的資料經過雜湊函式之後，都雜湊到同乙個槽裡。如果我們使用的是基於鍊錶的衝突解決方法，那這個時候，雜湊表就會退化為鍊錶，查詢的時間複雜度就從o(1)急劇退化為o(n)。
\n如果雜湊表中有10萬個資料，退化後的雜湊表查詢的效率就下降了10萬倍。更直觀點說，如果之前執行100次查詢只需要0.1秒，那現在就需要1萬秒。這樣就有可能因為查詢操作消耗大量cpu或者執行緒資源，導致系統無法響應其他請求，從而達到拒絕服務攻擊（dos）的目的。這也就是雜湊表碰撞攻擊的基本原理。
\n如何設計乙個可以應對各種異常情況的工業級雜湊表，來避免在雜湊衝突的情況下，雜湊表效能的急劇下降，並且能抵抗雜湊碰撞攻擊？
\n\n
題目解析
\n我經常把這道題拿來作為面試題考察候選人。雜湊表可以說是我們最常用的一種資料結構了，程式語言中很多資料型別，都是用雜湊表來實現的。儘管很多人能對雜湊表都知道一二，知道有幾種雜湊表衝突解決方案，知道雜湊表操作的時間複雜度，但是理論跟實踐還是有一定距離的。光知道這些基礎的理論並不足以開發乙個工業級的雜湊表。
\n所以，我在雜湊表（中）那一節中詳細給你展示了乙個工業級的雜湊表要處理哪些問題，以及如何處理的，也就是這個問題的詳細答案。
\n這六道題你回答得怎麼樣呢？或許你還無法100%回答正確，沒關係。其實只要你看了解析之後，有比較深的印象，能立馬想到哪節課裡講過，這已經說明你掌握得不錯了。畢竟想要完全掌握我講的全部內容還是需要時間沉澱的。對於《資料結構與演算法之美》這門專欄的學習，你一定不要心急，慢慢來。只要方向對了就都對了，剩下就交給時間和努力吧！
\n
測一測你的演算法階段學習成果
資料結構與演算法之美 專欄最重要的基礎篇馬上就要講完了，我從前面的文章中挑選了幾個例子，稍加修改，組成了一套測試題。你先不要著急看答案，自己先想一想怎麼解決，測一測自己對之前的知識掌握的程度。n如果有 卡殼或者不怎麼清楚的，可以回過頭再複習一下。正所謂溫故知新，這種通過實際問題查缺補漏的學習方法，非...
測一測你的演算法階段學習成果
資料結構與演算法之美 專欄最重要的基礎篇馬上就要講完了，我從前面的文章中挑選了幾個例子，稍加修改，組成了一套測試題。你先不要著急看答案，自己先想一想怎麼解決，測一測自己對之前的知識掌握的程度。如果有 卡殼或者不怎麼清楚的，可以回過頭再複習一下。正所謂溫故知新，這種通過實際問題查缺補漏的學習方法，非常...
測一測你的演算法階段學習成果
資料結構與演算法之美 專欄最重要的基礎篇馬上就要講完了，我從前面的文章中挑選了幾個例子，稍加修改，組成了一套測試題。你先不要著急看答案，自己先想一想怎麼解決，測一測自己對之前的知識掌握的程度。如果有 卡殼或者不怎麼清楚的，可以回過頭再複習一下。正所謂溫故知新，這種通過實際問題查缺補漏的學習方法，非常...