CTO談豆瓣網和校內網技術架構變遷

CTO談豆瓣網和校內網技術架構變遷

豆瓣網CTO洪強寧講述網站架構變遷

羅馬不是一天建成的,豆瓣的技術架構也是隨著用戶規模的增長一直在持續變化中。洪強寧,2002年畢業于清華大學,現任北京豆瓣互動科技有限公司首席架構師。洪強寧和他帶領的技術團隊致力于用技術改善人們的文化和生活品質,在網站架構、性能、可伸縮性上進行深入研究。豆瓣網曾獲軟件中國2006年度最佳技術應用網站。

校內網CTO黃晶講述網站架構變遷

每個網站的發展都會按照一個大致相同的路線去完成,當然這里說的是每個相對成功的網站。

第一階段:

這一階段沒有太大的訪問量,甚至只有一臺服務器就搞定了所有的訪問。DB和前端的代碼全都在一起,壓力不高。憶者注:我覺得在alexa沒進五萬的時候,只要不是特殊的應用,基本都在此列吧。

第二階段:

網站初具規模,DB壓力大增,單獨的一臺DB已經滿足不了現在的訪問量,開始考慮讀寫分離的Master-slave庫,使用三個及以上的服務器。憶者注:這時網站的alexa基本上會在1-3萬的位置,每天的ip在5-10w的樣子,當然,DB我們都認為是MySql。

第三階段:

訪問量繼續增加,增加到了DB的壓力在Master的機器上非常的明顯了,Master開始出現吃不消的情況,出現寫耗盡。主從也已經不能滿足要求,需要進一步解決負載問題,此時要引入MysqlProxy程序,進行中間層代理,實現負載均衡,易于擴展。憶者注:這時網站已經不可限量了,先恭喜下你的網站能用到這段。

第四階段:

網站繼續發展,進而出現了數據量的成倍增長,原來的N臺DB都出現了一個問題,數據量巨大,無法完成正常速度的讀寫。此時,需要對網站按功能進行垂直劃分,比如用戶注冊登錄是一部分、UGC又是另一部分。與此同時,對數據本身進行水平劃分,也就是Hash散表或者是散庫。

第五階段:

真的沒了。再往下玩就滅了。

其實再進一步第五第六階段,就是無法預想的未來了,也許有什么突飛猛進的科學技術發明也說不好。

附:豆瓣BeansDB的設計與實現

Qcon 2011:Beansdb 的設計與實現

View morepresentationsfromDavies Liu

花瓣網的系統架構和消息隊列系統

花瓣網的系統架構和消息隊列系統 - SlideShare

Yupoo! (花瓣網/又拍云) 架構中的消息與任務系統

View morepresentationsfromDahui Feng

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容