网站架构学习笔记–Tailrank架构
关键字: 网站架构 MySQL Apache
来源：Todd Hoff的文章http://www.highscalability.com/tailrank-architecture-learn-how-track-memes-across-entire-blogosphere
Tailrank网站提供blog文章热点新闻跟踪服务，同时从8个月前开始许可其爬虫程序Spinn3r
Tailrank要解决的是如何高效处理海量数据，及如何分析并精确索引其抓取的内容
其要技术难点在于建立伸缩性好并高容 继续阅读 »
大规模网络服务交付模式:http://docs.google.com/Presentation?id=dd78njkn_33hmvnknxd
听不错的一篇PPT文章
一、LiveJournal发展历程LiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能：
博客，论坛
社会性网络，找到朋友
聚合，把朋友的文章聚合在一起
LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。
在上线后，LiveJournal实现了非常快速的增长：
2004年4月份：280万注册用户。
2005年4月份：680万注册用户。
2005年8月份：790万注册用户。
达到了每秒钟上千次的页面请求及处理。
使用了大量MySQL服务器。
使用了大量通用组件。
二、LiveJournal架构现状概况
继续阅读 »
作者：疯狂代码
大型网站架构系列之一 不得不考虑的问题
前言：这两天机器坏了，正在送修中，写个系列的大型网站架构的文章，希望对有志在互联网做出一番事业的站长朋友们一些帮助。
注意：这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架构都是必须要面对的。
文入正题：
首先讨论一下大型网站需要注意和考虑的问题
A. 海量数据的处理。
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
B. 数据并发的处理
在一些时候，2.0的CTO都 有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者 多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
C. 文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量 是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。 继续阅读 »
之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:-)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
高性能web应用的基本系统结构：
a) 基本结构：
负载均衡=>反向代理=>静态内容缓存=>静态内容=>动态应用加速=>动态应用=>数据缓存=>数据存储=>分布式应用
b) 负载均衡：负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性，避免了网络关键部位出现单点失效。
i. 负载均衡有两方面的含义：
1. 首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；
2. 其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
ii. 常见的负载均衡方法：
1. DNS轮询：适合静态内容的简单均衡机制；
2. 智能DNS：在广域网中，对适合分布的静态内容可以做到智能判断用户来源，提供最近的Cache分发服务器方便用户就近高速访问；
3. 反向代理：将外部请求转发给内部的多台服务器，从而达到负载均衡的目的；同时可以将负载均衡和高速缓存结合在一起，提高性能；随着并发连接数量的增加，代理服务器本身的负载也变得非常大，最后反向代理服务器本身会成为服务的瓶颈。
4. 四层交换：
5. 内容交换(七层交换/URL交换):
a) 在HTTP请求和报头中有很多对负载均衡有用的信息。可以从这些信息中获知客户端所请求的URL和网页，负载均衡设备就可以将 所有的图像请求引导到一个图像服务器，或者根据URL的数据库查询内容调用CGI程序，将请求引导到一个专用的高性能数据库服务器。
b) 可以根据HTTP报头的cookie字段来使用Web内容交换技术改善对特定客户的服务；
c) 如果能从HTTP请求中找到一些规律，还可以充分利用它作出各种决策；
d) 除了TCP连接表的问题外，如何查找合适的HTTP报头信息以及作出负载平衡决策的过程，是影响Web内容交换技术性能的重要 问题。如果Web服务器已经为图像服务、SSL对话、数据库事务服务之类的特殊功能进行了优化，那么采用这个层次的流量控制将可以提高网络的性能。
c) 反向代理：（并入负载均衡一节）
d) 静态内容缓存：通常与反向代理合并在一起，提供静态内容（HTML页面，图片，js脚本，css文件等等）缓存。
e) 静态内容：CMS、Blog、Wiki等静态化应用。
f) 动态应用加速：利用Apache的MPM模式或者Zend、eAccelarator等加速引擎为动态应用加速。
g) 动态应用：网站核心功能SNS、交友、互动等等。
h) 数据缓存：memcached。
i) 数据存储：内存、磁盘文件或者数据库。
j) 分布式应用：分布式文件存储、数据库集群。
继续阅读 »
