大型网站架构设计
① 大型视频网站的技术架构方案
国内的不清楚,给你看看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.异步
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前面提到的分层、分割、分布等，还有一个重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。