一、緣起
《深入淺出搜尋架構（上篇）
》詳細介紹了前三章：
（1）全網搜尋引擎架構與流程
（2）站內搜尋引擎架構與流程
（3）搜尋原理與核心資料結構
《深入淺出搜尋架構（中篇）
》介紹了：
（4）流量資料量由小到大，常見搜尋方案與架構變遷
（5）資料量、併發量、擴充套件性架構方案
本篇將討論：
58同城為何能實時檢索出1秒鐘之前發布的帖子
？搜尋引擎的實時性架構
，是本文將要討論的問題。
二、實時搜尋引擎架構
大資料量、高併發量情況下的搜尋引擎為了保證實時性，架構設計上的兩個要點：
（1）索引分級
（2）dump&merge
索引分級 《
深入淺出搜尋架構（上篇）
》介紹了搜尋引擎的底層原理，在資料量非常大的情況下，為了保證倒排索引的高效檢索效率，任何對資料的更新，並不會實時修改索引，一旦產生碎片，會大大降低檢索效率。
既然索引資料不能實時修改，如何保證最新的網頁能夠被索引到呢？
索引分為全量庫、日增量庫、小時增量庫。
如下圖所述：
（1）300億資料在全量索引庫中
（2）1000萬1天內修改過
的資料在天庫中
（3）50萬1小時內修改過的資料在小時庫中
當有修改
請求發生時，
只會操作最低級別的索引
，例如小時庫。
當有查詢請求發生時，會同時查詢各個級別的索引，將結果合併，得到最新的資料：
（1）全量庫是緊密儲存的索引，無碎片，速度快
（2）天庫是緊密儲存，速度快
（3）小時庫資料量小，速度也快
資料的寫入和讀取都是實時的，所以58同城能夠檢索到1秒鐘之前發布的帖子，即使全量庫有300億的資料。
新的問題來了：小時庫資料何時反映到天庫中，天庫中的資料何時反映到全量庫中呢？
dump&merge
這是由兩個非同步的工具完成的：
：將merger
：將離線的資料合併到高一級別的索引中去
小時庫，一小時一次，合併到天庫中去；
天庫，一天一次，合併到全量庫中去；
這樣就保證了小時庫和天庫的資料量都不會特別大；
如果資料量和併發量更大，還能增加星期庫，月庫來緩衝。
三、總結
超大資料量，超高併發量，實時搜尋引擎的兩個架構要點： （
1）索引分級 （
2）dump&merge
如《深入淺出搜尋架構（上篇）
》中所述，全網搜尋引擎分為spider, search&index, rank三個部分。本文描述的是search&index如何實時修改和檢索，
spider子系統如何能實時找到全網新生成的網頁
，又是另外乙個問題，未來撰文講述。
希望大家有收穫，幫轉喲。
==【完】==
百度檢索技巧
1.基本檢索技術 與 運算 增加搜尋範圍。運算子為 空格 或 非 運算 減除無關資料。運算子為 減號前後必須留一空格，語法是 a b 有時候，排除含有某些詞語的資料有利於縮小查詢範圍。例如，要搜尋關於 武俠 但不含 古龍 的資料，可使用如下查詢 或 運算 並行搜尋。運算子為 使用 a b 來搜尋 a...
百度檢索小技巧
我這裡分享下自己親測並覺得，可用性比較高的一些小技巧。減號排除，縮小範圍 直接檢索的結果圖 正確的寫法 強制檢索 雙引號 我們要先注意的是這個雙引號一定要在半形輸入法 也稱為英文輸入法 下進行輸入，而不是在中文輸入法下的雙引號。直接檢索的結果圖 加上雙引號的檢索結果 發現沒有？加上雙引號不僅檢索結果...
百度實時主動推送url
提交方式 提高了很多站長所需的東西。你一看便知。2 post推送示例 進行輸出流的緩衝 out.flush 通過bufferedreader輸入流來讀取url的響應 in new bufferedreader new inputstreamreader conn.getinputstream str...