「評論蓋樓」的設計思路

這樣的需求其實挺特殊，每一個「樓」都是一個獨立的「樹」，每一個「樓」都「幾乎」不用依賴其餘的「樓」。
最簡單、最高效的方式是用文件來存 儲每個樓，每一個新聞一個樓，使用xml、json等樹形結構的文件格式來規範評論和新聞內容。這樣每進一個樓只須要訪問一個文件，發評論只是建立一個文 件，把樓蓋高，只是給增長新內容。而新聞列表能夠存儲在數據庫中，也能夠用lucene作索引。

若是必定要用數據庫實現，那麼新聞（主貼）作一張表，評論（回貼）作一張表，評論表中添加新聞id字段做爲與新聞表的外鍵關聯便可。若是要進一步完善樹形結構，評論表上補充一個指回評論表的外鍵便可。

 

若是性能很是重要，這個方式是頗有意義的，並且新聞列表必定是用lucene作索引。
新聞首頁必定不是直接查詢數據庫，而是靜態化該頁面。在後臺作一個輪訓器，按期更新這個靜態頁，若是有重大新聞發生，強制更新該頁面。
新聞內容、評價頁靜態化或者單文件處理，能極大下降服務器壓力，畢竟沒有數據庫操做。天天一個目錄，或者每小時一個目錄，在文件存儲方面就不會對文件系統造成較大壓力。

 

二、
於數據壓力，用數據庫的話，能夠分拆爲每一年、每月再或者每週一個新聞庫，只須要每次新增一個庫便可。具體的處理方式就要看你用的數據庫。
某些狀況下，將當月、重點的新聞單獨提煉出來靜態頁面項目，須要對當月、重點的新聞作大規模的負載均衡，對其餘不重要新聞則使用普通的方式。

新聞內容若是靜態化
優點：可使用apache甚至lighttpd、nginx服務器，對應的處理壓力的能力較強。
方式：能夠用新聞內容自己+新聞模版生成靜態的新聞文件，在新聞文件上用ajax異步加載新聞的評論。
缺點：新聞頁面上的其餘因素成爲開發起來比較麻煩的東西，好比廣告、相關文章鏈

新聞內容若是不靜態化
缺點：使用的服務器受到你的系統的架構的影響，處理壓力的能力受限。
方式：能夠將該新聞的內容、評論等相關因素放在一個xml裏面，訪問該新聞時僅僅讀一個新聞xml，僅一次讀IO，性能上不會有較大壓力。前端能夠再加一個集中式緩存(好比memcached),將讀的次數很是多的新聞存在緩存中，進一步減小IO數。
有點：靈活。