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

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

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

  1

2

3

4

5

6

7

7.2

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

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

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

第一階段:服務器

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

第二階段:負載均衡

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

第三階段:性能

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

第四階段:.net

網站繼續發展,進而出現了數據量的成倍增加,原來的N臺DB都出現了一個問題,數據量巨大,沒法完成正常速度的讀寫。此時,須要對網站按功能進行垂直劃分,好比用戶註冊登陸是一部分、UGC又是另外一部分。與此同時,對數據自己進行水平劃分,也就是Hash散表或者是散庫。設計

第五階段:

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

其實再進一步第五第六階段,就是沒法預想的將來了,也許有什麼日新月異的科學技術發明也說很差。

 

附:豆瓣BeansDB的設計與實現

Qcon 2011:Beansdb 的設計與實現

View more presentations from Davies Liu

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

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

相關文章
相關標籤/搜索