大型網站架構設計
① 大型視頻網站的技術架構方案
國內的不清楚,給你看看YOUTUBE的
YouTube 的架構擴展
在西雅圖擴展性的技術研討會上，YouTube 的 Cuong Do 做了關於 YouTube Scalability 的報告。視頻內容在 Google Video 上有(地址)，可惜國內用戶看不到。
Kyle Cordes 對這個視頻中的內容做了介紹。裡面有不少技術性的內容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來源)
簡單的說 YouTube 的數據流量, "一天的YouTube流量相當於發送750億封電子郵件.", 2006 年中就有消息說每日 PV 超過 1 億,現在? 更誇張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量. 國內的互聯網應用,但從數據量來看,怕是只有 51.com 有這個規模. 但技術上和 YouTube 就沒法子比了.
1. Web 伺服器
YouTube 出於開發速度的考慮，大部分代碼都是 Python 開發的。Web 伺服器有部分是 Apache， 用 FastCGI 模式。對於視頻內容則用 Lighttpd 。據我所知，MySpace 也有部分伺服器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(國內用 Lighttpd 站點不多，豆瓣用的比較舒服。by Fenng)
2. 視頻
視頻的縮略圖(Thumbnails)給伺服器帶來了很大的挑戰。每個視頻平均有4個縮略圖，而每個 Web 頁面上更是有多個，每秒鍾因為這個帶來的磁碟 IO 請求太大。YouTube 技術人員啟用了單獨的伺服器群組來承擔這個壓力，並且針對 Cache 和 OS 做了部分優化。另一方面，縮略圖請求的壓力導致 Lighttpd 性能下降。通過 Hack Lighttpd 增加更多的 worker 線程很大程度解決了問題。而最新的解決方案是起用了 Google 的 BigTable， 這下子從性能、容錯、緩存上都有更好表現。看人家這收購的，好鋼用在了刀刃上。
出於冗餘的考慮，每個視頻文件放在一組迷你 Cluster 上，所謂 "迷你 Cluster" 就是一組具有相同內容的伺服器。最火的視頻放在 CDN 上，這樣自己的伺服器只需要承擔一些"漏網"的隨即訪問即可。YouTube 使用簡單、廉價、通用的硬體，這一點和 Google 風格倒是一致。至於維護手段，也都是常見的工具，如 rsync, SSH 等，只不過人家更手熟罷了。
3. 資料庫
YouTube 用 MySQL 存儲元數據--用戶信息、視頻信息什麼的。資料庫伺服器曾經一度遇到 SWAP 顛簸的問題，解決辦法是刪掉了 SWAP 分區! 管用。
最初的 DB 只有 10 塊硬碟，RAID 10 ，後來追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見這里). 在擴展性方面，路線也是和其他站點類似，復制，分散 IO。最終的解決之道是"分區",這個不是資料庫層面的表分區，而是業務層面的分區(在用戶名字或者 ID 上做文章,應用程序控制查找機制)
YouTube 也用 Memcached.
② 如何評價一個大型網站系統架構設計的好壞
說說我的看法，對不對的供參考吧！
首先，網站也好、其它信息化系統也好，其系統架構設計都不是拍腦袋來的，都是依據一個出發點設計而來，究其所以，就是需求。而這個需求又是從最初的建設初衷來的，也就是說，按說最後做出來的東西應該滿足建設初衷。
所以，簡言之，有什麼樣的需求就有什麼樣的架構設計。因此，要評價架構設計的好壞，就拿需求來衡量。能滿足需求的架構設計，就是對的。不能滿足，或者不能全面滿足的，如果沒有項目建設上的延期認可或者同意擱置的決定，就是不應該的。
注意：我說的需求，並不僅是針對功能范疇的；也包括性能、可用性、安全等方面。所以說需求是全面的內容。
③ 大型分布式網站架構設計與實踐 怎麼樣
可以的，聯系我
④ 大型網站架構該怎麼優化設計
你得把你的網站拿出來看了才知道怎麼優化改進。並不是說每個網站的優化思路都一樣。比內如，你優化結構容之前你得考慮你的長尾關鍵詞要怎麼擴展，長尾詞是不是有規律可循。如果有規律，你可以直接利用程序生成標題，生成內容。要根據你的設計思路去設計網站結構。要是每個網站優化思路都一樣，那為什麼不直接程式化，還拿優化運營來做什麼？自動化多好。但是，這是不現實的。所以，你的提問沒人能幫得到你。
⑤ 大型分布式網站架構設計與實踐 怎麼樣
大型分布式網站架構設計與實踐 這本書 的點評如下：
書中提到了很多大型分布式網站設回計所必須的知識答點，如soa、分布式系統的基礎設施，
系統穩定性設計，數據分析，系統穩定設計的章節寫的很有實踐性，
自檢腳本的編寫、日誌分析命令的妙用，互聯網安全方面之前講類似知識點的，
書中介紹的比較詳細，不錯
還有疑問請追問沒有疑問請採納。
⑥ 如何評價一個大型網站系統架構設計的好壞
如何評價一個大型網站系統架構設計的好壞
看邏輯框架是否ok
⑦ 從0開始逐步邊開發邊運作一個大型網站，該採用怎樣的技術架構（或者技術路線）
這樣的跨度肯定會經歷推倒重來的過程，否則一開始就設計一個能擴展到很大規模的版網站架構會在初期造成權很大的資金和人力負擔。讓開發的負責人給你計算了開發成本，維護成本和開發出來的效果以後你再決定當前階段採用哪一種。顯然一分錢一分貨。
越簡單的時候PHP越有優勢，越復雜JAVA越有優勢，JSP只是JAVA WEB開發中的一項技術，到最後都不一定需要使用。為了不浪費人手，如果你確定將來要往大網站發展一開始就該採用JAVA或.NET，這樣在重新開發時至少能充分利用之前的人員經驗。
該採用怎樣的技術架構不是三兩句話能說清楚的，具體問題具體分析。
再簡單也不建議使用JSP+SERVLET+JAVABEAN
SSH之類的架構本來就是為了簡化開發工作量，提高代碼質量和可維護性而生的。除非追求極致變態的性能的人才會去用servlet，而且實際體驗可能根本幾乎沒差別，只要不把SSH用得太爛。架構復雜了，也不過是在這些主流技術上改改，封裝封裝，自然是使用同一語言比PHP轉JAVA容易太多了。
⑧ 求 《大型分布式網站架構設計與實踐》陳康賢 全章 PDF
我幫你下好了共享的我的網路雲盤裡面了請去下載記得好評哦~哈哈
⑨ 大型網站架構模式有哪些
1.分布式
對於大型網站，分層和分割的一個主要目的是為了切分後的模塊便於分布式部署，即將不同模塊部署在不同的伺服器上，通過遠程調用協同工作。分布式意味著可以使用更多的計算機完成同樣的功能，計算機越多，CPU、內存、存儲資源也就越多，能夠處理的並發訪問和數據量就越大，進而能夠為更多的用戶提供服務。
2.分層
分層是企業應用系統中最常見的一種架構模式，將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和調用組成一個完整的系統。
分層結構在計算機世界中無處不在，網路的7層通信協議是一種分層結構；計算機硬體、操作系統、應用軟體也可以看作是一種分層結構。在大型網站架構中也採用分層結構，將網站軟體系統分為應用層、服務層、數據層。
3.分割
如果說分層是將軟體在橫向方面進行切分，那麼分割就是在縱向方面對軟體進行切分。
網站越大，功能越復雜，服務和數據處理的種類也越多，將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，一方面有助於軟體的開發和維護；另一方面，便於不同模塊的分布式部署，提高網站的並發處理能力和功能擴展能力。
4.集群
使用分布式雖然已經將分層和分割後的模塊獨立部署，但是對於用戶訪問集中的模塊（比如網站的首頁），還需要將獨立部署的伺服器集群化，即多台伺服器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。
5.緩存
緩存就是將數據存放在距離計算最近的位置以加快處理速度。緩存是改善軟體性能的第一手段，現代CPU越來越快的一個重要因素就是使用了更多的緩存，在復雜的軟體設計中，緩存幾乎無處不在。大型網站架構設計在很多方面都使用了緩存設計。
6.非同步
計算機軟體發展的一個重要目標和驅動力是降低軟體耦合性。事物之間直接關系越少，就越少被彼此影響，越可以獨立發展。大型網站架構中，系統解耦合的手段除了前面提到的分層、分割、分布等，還有一個重要手段是非同步，業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式非同步執行進行協作。