<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    Tin's Blog

    You are coming a long way, baby~Thinking, feeling, memory...

      BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
      128 隨筆 :: 0 文章 :: 221 評論 :: 0 Trackbacks
    在中文網(wǎng)織年會上和啄木鳥老大HD討論了一下好看簿的架構(gòu)問題,而后老黃寫了一個blog entry:
    架構(gòu)考量-選擇的難度
    里面談到了架構(gòu)一個高支撐能力的Web 2.0應(yīng)用需要考慮的架構(gòu)選型問題,對我很有幫助。我也回復(fù)一下他的建議:

    非常不好意思,今天檢查google reader才發(fā)現(xiàn)HD老大記錄了這個談話。而我都沒有在blog里面記錄這個事情。不過和HD老大的談話回來我還是仔細(xì)消化了一下。關(guān)于交換機(jī)的事情我已經(jīng)反思了,后來在切換服務(wù)器的時候的確發(fā)現(xiàn)了百兆和千兆的區(qū)別,rsync在百兆網(wǎng)絡(luò)下的確造成了我們的切換宕計時間變長。當(dāng)時我們停止服務(wù)15分鐘,如果是千兆網(wǎng)絡(luò)估計5分鐘以內(nèi)就可以了,所以如HD所說,我們也許應(yīng)該選擇HW的千兆。
    關(guān)于文件服務(wù)的問題,我想目前的關(guān)鍵還是需要看看是否有熱點(diǎn)數(shù)據(jù)。不過對于網(wǎng)站來說,由于首頁和離首頁深度比較近的頁面被訪問的可能性要明顯的高,所以如果使用squid做反向代理肯定可以減輕靜態(tài)文件服務(wù)的壓力。但是問題也在這里,一定要流量對靜態(tài)文件有壓力的時候再加Squid。
    其實(shí)本次切換的主要問題是將動態(tài)服務(wù)與靜態(tài)服務(wù)分開。因?yàn)闆]有選擇純磁盤陣列用光纖或者iSCSI的方式掛在到動態(tài)服務(wù)器(因?yàn)樵鹊?950充當(dāng)了文件服務(wù)器),所以為了不浪費(fèi)計算資源我們將動態(tài)服務(wù)器(8G內(nèi)存,Raid1和15k rpm硬盤)和靜態(tài)服務(wù)器(8G內(nèi)存,Raid5和750G X 6的7200 rpm硬盤)分開處理,這樣動態(tài)服務(wù)器跑Django,靜態(tài)服務(wù)器跑Lighttpd。他們之間只需要一個讀寫的通訊,因?yàn)槭莾?nèi)部通訊,所以用http是沒有意義的。用NFS可能是最直接的方法。用SAN或者iSCSI的方式其實(shí)也是可行的,前者是成本問題,而后者是浪費(fèi)計算資源的問題,所以我們自然的按HD的意思上了NFSv4。
    然后又引出MogileFS的問題。其實(shí)這是個大文件存儲的真諦問題。如果數(shù)據(jù)量達(dá)到一定程度,單個節(jié)點(diǎn)不可以承受的時候,那么我們只能選擇數(shù)據(jù)分片,可以時髦的叫做shard,如google做的map reduce的GFS。或者干脆就自己寫個簡單的數(shù)據(jù)索引,然后路由分區(qū)一下,這個概念就是MogileFS。MogileFS就是利用多個有自己的計算資源的靜態(tài)服務(wù)器來分區(qū)存儲并管理它們的一個準(zhǔn)分布式文件系統(tǒng)(因?yàn)镸ogileFS不支持隨機(jī)訪問,只是整存整取,所以說是準(zhǔn)文件系統(tǒng)),它已經(jīng)能解決我們Web 2.0應(yīng)用的問題了,F(xiàn)lickr也是這么干的……選用它或者自己做是個看起來和做起來都挺簡單的問題,只是它比什么都不需要改變的NFS還是稍微麻煩一點(diǎn)。所以這個作為未來的一種被選方案。其實(shí)呼應(yīng)一下HD在方案分析里面說的應(yīng)付流量壓力的目標(biāo),MogileFS只是用來解決存儲壓力的一個方式。
    關(guān)于FS,我最近也作了Research,發(fā)現(xiàn)這還真是一個坑呀,非常大的坑。XFS、JFS、nb的ZFS都是好方案,但是大文件系統(tǒng)還要考慮分區(qū)表格式,MBR已經(jīng)成了限制,用GPT吧你還不好引導(dǎo)(因?yàn)槿绻愣际谴笥脖P的話,單弄一個小的上MBR引導(dǎo),其它再分GPT,勢必要浪費(fèi)一塊硬盤,非常不劃算),然后LVM解決引導(dǎo)問題吧用起來還不踏實(shí)(畢竟它的條帶化不是硬件的Raid那樣可靠),然后你又需要去對比那幾個FS,反正頭大。最后還是硬著頭皮上了XFS。
    我覺得架構(gòu)考量就像HD所說的,你有無數(shù)選擇,這些選擇造成了噪音,然后在你四處碰壁的時候,你可能選擇了第一個可以用的方案去實(shí)施。而實(shí)際上你會很快發(fā)現(xiàn)更好的方案……架構(gòu)的重構(gòu)代價是可怕的……所以有了更好的方案可能也不會實(shí)施,或者要很久以后再實(shí)施。所以,這個經(jīng)驗(yàn)是需要年頭的,也許,也許,很多的方案都讓被實(shí)施者稱為了學(xué)徒練手的冬瓜,腦袋上的傷口只有冬瓜自己知道。雖然我作為學(xué)徒……看著也疼。我發(fā)誓,下次我一定做到更好!

    相關(guān)的好看簿故事,我把好看簿服務(wù)器升級的過程用照片故事的形式記錄下來了,歡迎大家參觀:
    http://www.haokanbu.com/story/2991/

    還有關(guān)于中國網(wǎng)志2007的記錄
    http://www.haokanbu.com/story/3022/

    posted on 2007-11-28 22:39 Tin 閱讀(2867) 評論(1)  編輯  收藏 所屬分類: 開源 、擴(kuò)展與調(diào)優(yōu) 、Django

    評論

    # re: Re:架構(gòu)考量-選擇的難度 2008-05-17 22:09 膠粘劑
    力量啊  回復(fù)  更多評論
      

    主站蜘蛛池模板: 麻豆亚洲AV永久无码精品久久 | 区三区激情福利综合中文字幕在线一区亚洲视频1 | 亚洲欧洲无码AV不卡在线| 亚洲精品蜜桃久久久久久| 亚洲片一区二区三区| 无码专区一va亚洲v专区在线| 国产一区二区免费在线| 国产成人免费a在线视频色戒 | 一级毛片在线完整免费观看| 日韩亚洲翔田千里在线| 国产天堂亚洲精品| 老司机免费午夜精品视频| 老司机精品视频免费| 美女羞羞免费视频网站| 特级毛片A级毛片免费播放| 黄色大片免费网站| 一级毛片在线播放免费| 爽爽爽爽爽爽爽成人免费观看| 少妇性饥渴无码A区免费 | 免费毛片毛片网址| 一区二区三区免费视频网站| 中文字幕无线码中文字幕免费| 97超高清在线观看免费视频| 无码av免费一区二区三区试看| 日本人的色道免费网站| 成年女人视频网站免费m| 国产一级淫片免费播放| 久久亚洲欧洲国产综合| 无码专区—VA亚洲V天堂| 亚洲成a人片毛片在线| 亚洲精品V天堂中文字幕| 成人午夜免费视频| 久久精品视频免费播放| 日韩av无码成人无码免费 | 一级成人a毛片免费播放| 在线精品一卡乱码免费| 国产伦一区二区三区免费| 亚洲中文字幕在线第六区| 久久亚洲精品无码AV红樱桃| 亚洲人成网亚洲欧洲无码| 9久热这里只有精品免费|