目錄

• • 目錄
  • 前言
  • 正文
    • 題目分析
    • 索引設計
    • 程式碼展示
    • 關鍵優化
  • 後記

前言

經過初賽的篩選後，我們就進入了複賽（名副其實的廢話）。接下來我簡單介紹下我們隊伍參加複賽一些情況吧。複賽相對初賽而言題目針對性比較強，所以對於比賽之外的人而言沒啥可以學習的地方。因此我這裡只記錄一些開發過程中的一些體會，至於我們隊伍的程式碼上的一些細節(處理流程、索引結構等)，有興趣的可以直接去看原始碼，這樣會更清楚些。

正文

題目分析

複賽的任務就是對幾個淘寶的訂單檔案建立索引，最後實現幾個查詢介面，索引構建過程、索引的結構、查詢的過程以及快取策略都是自己來控制。可以參考開源的Nosql資料庫的設計，但不能直接使用非工具類的第三方庫。

程式的執行分為兩個階段，準備階段與查詢階段, 每個階段各限時一小時。

業務方需要選手支援下面幾種查詢方法：

1. 提供交易ID，查詢某次交易的某些屬性
2. 查詢某位買家某個時間範圍內的所有交易 資訊，輸出結果按交易時間從大到小排列
3. 查詢某個商品的全部交易訂單，輸出結果 按交易訂單號從小到大排序
4. 對某個商品的所有交易資訊進行求和

索引設計

我們隊伍最終使用的是二級索引，由於內容較多，在此只列出orderid的索引結構圖：

對此感興趣的朋友可以直接去看我們隊伍的答辯ppt，裡邊就有詳細的介紹。

程式碼展示

詳見程式碼倉庫

關鍵優化

• 索引構建過程中，單執行緒讀寫->多執行緒讀寫->讀寫分離
• 不對原始檔案hash，而是隻對索引進行hash(效能提高了5倍左右，達到了一個新的里程碑
  )
• 加快範圍查詢
  
  • 一、二級索引放磁碟 =》二級索引存Cache =》二級索引treemap格式存Cache =》根據hash後文件排序
  • 優化一級索引查詢
  • 縮減為一次讀盤
• 源資料的cache選擇
  

  為了減少詢盤，充分利用記憶體 ： FIFO策略 =》無替換cache good表 =》無替換cache buyer表

• 其他一些優化手段
  
  • 使用stringtokennizer代替split
  • 優化RandomAccessFile的readline方法，減少硬碟io
  • 壓縮重複資料，減少對記憶體的佔用

後記

感悟：

• 抓住主要瓶頸點，再去優化細節，往往解決一個大的瓶頸點，便是一個里程碑。而細節則會起到錦上添花的作用。
• 複賽在最後一刻衝到了第一的位置，然後在答辯時卻被複賽第二名的隊伍反超，只獲得了亞軍。雖然沒能拿到“全場最佳”，但對於這樣的結果我也已經很滿意了。冠軍隊伍確實厲害，對賽題進行了系統的分析與架構設計，而我們的大部分程式碼都是跟著感覺走，這應該就是我們兩隊的差距了。所以從這次比賽中，我最大的感悟就是碼程式碼真的不能再只跟著感覺走了，一定要系統地進行分析，充分利用所有能夠利用的資源，這樣的碼程式碼姿勢才是最正確的。