亚洲成A∨人片在线观看不卡,亚洲国产系列一区二区三区,亚洲黄网站wwwwww

zeus.xiao — Thu, 04 Jun 2009 02:43:00 GMT

声明:本文转自BlueDavy之技术Blog(http://m.tkk7.com/BlueDavy/archive/2008/09/03/226749.html)
之前也有一些介�l�大型网站架构演变的文章�Q�例如LiveJournal的、ebay的，都是非常值得参考的�Q�不�q�感觉他们讲的更多的是每�ơ演变的�l�果�Q�而没有很详细的讲��Z��么需要做�q�样的演变，再加上近来感觉有不少同学都很难明白�ؓ什么一个网站需要那么复杂的技术，于是有了写这��文章的��x��Q�在�q�篇文章中将阐述一个普通的�|�站发展成大型网站过�E�中的一�U�较为典型的架构演变历程和所需掌握的知识体�p�，希望能给想从事互联网行业的同学一点初步的概念�Q?)�Q�文中的不对之处也请各位多给点徏议，让本文真正�v到抛砖引玉的效果�?br />

架构演变�W�一步：物理分离webserver和数据库

最开始，�׃��某些��x��Q�于是在互联�|�上搭徏了一个网站，�q�个时候甚��x��可能��L��都是�U�借的�Q�但�׃��q�篇文章我们只关注架构的演变历程�Q�因此就假设�q�个时候已�l�是托管了一��C��机，�q�且有一定的带宽了，�q�个时候由于网站具备了一定的特色�Q�吸引了部分��问，逐渐你发现系�l�的压力��来��高�Q�响应速度��来��慢�Q�而这个时候比较明昄��是数据库和应用互相媄响，应用出问题了�Q�数据库也很�Ҏ��出现问题�Q�而数据库出问题的时候，应用也容易出问题�Q�于是进入了�W�一步演变阶�D�：��应用和数据库从物理上分��，变成了两台机器，�q�个时候技术上没有什么新的要求，但你发现��实起到效果了，�pȝ��又恢复到以前的响应速度了，�q�且支撑住了更高的流量，�q�且不会因�ؓ数据库和应用形成互相的媄响�?/span>

看看�q�一步完成后�pȝ��的图�C�：

�q�一步涉及到了这些知识体�p�：

�q�一步架构演变对技术上的知识体�p�d��本没有要求�?br />

架构演变�W�二步：增加��面�~�存

好景不长�Q�随着讉K��的�h��来��多�Q�你发现响应速度又开始变慢了�Q�查扑֎�因，发现是访问数据库的操作太多，��D��数据�q�接竞争�Ȁ烈，所以响应变慢，但数据库�q�接又不能开太多�Q�否则数据库机器压力会很高，因此考虑采用�~�存机制来减��数据库�q�接资源的竞争和�Ҏ��据库�ȝ��压力�Q�这个时候首先也�怼�选择采用squid �{�类似的机制来将�pȝ��中相寚w��态的��面�Q�例如一两天才会有更新的��面�Q�进行缓存（当然�Q�也可以采用��页面静态化的方案）�Q�这��L��序上可以不做修改�Q�就能够很好的减��对webserver的压力以及减��数据库�q�接资源的竞争，OK�Q�于是开始采用squid来做相对静态的��面的缓存�?/span>

看看�q�一步完成后�pȝ��的图�C�：

�q�一步涉及到了这些知识体�p�：

前端��面�~�存技术，例如squid�Q�如想用好的话还得深入掌握下squid的实现方式以及缓存的失效��法�{��?br />

架构演变�W�三步：增加��面片段�~�存

增加了squid做缓存后�Q�整体系�l�的速度��实是提升了�Q�webserver的压力也开始下降了�Q�但随着讉K��量的增加�Q�发现系�l�又开始变的有些慢了，在尝��C��squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存�v来呢�Q�因此考虑采用�c�M��ESI之类的页面片�D늼�存策略，OK�Q�于是开始采用ESI来做动态页面中相对静态的片段部分的缓存�?/span>

看看�q�一步完成后�pȝ��的图�C�：

�q�一步涉及到了这些知识体�p�：

��面片段�~�存技术，例如ESI�{�，想用好的话同样需要掌握ESI的实现方式等�Q?/span>

架构演变�W�四步：数据�~�存

在采用ESI之类的技术再�ơ提高了�pȝ��的缓存效果后�Q�系�l�的压力��实�q�一步降低了�Q�但同样�Q�随着讉K��量的增加�Q�系�l�还是开始变慢，�l�过查找�Q�可能会发现�pȝ��中存在一些重复获取数据信息的地方�Q�像获取用户信息�{�，�q�个时候开始考虑是不是可以将�q�些数据信息也缓存�v来呢�Q�于是将�q�些数据�~�存到本地内存，改变完毕后，完全�W�合预期�Q�系�l�的响应速度又恢复了�Q�数据库的压力也再度降低了不��?/span>

看看�q�一步完成后�pȝ��的图�C�：

�q�一步涉及到了这些知识体�p�：

�~�存技术，包括像Map数据�l�构、缓存算法、所选用的框架本�w�的实现机制�{��?/span>

架构演变�W�五步：增加webserver

好景不长�Q�发现随着�pȝ��讉K��量的再度增加�Q�webserver机器的压力在高峰期会上升到比较高�Q�这个时候开始考虑增加一台webserver�Q�这也是��Z��同时解决可用性的问题�Q�避免单台的webserver down机的话就没法使用了，在做了这些考虑后，军_��增加一台webserver�Q�增加一台webserver�Ӟ��会碰��C��些问题，典型的有�Q?br /> 1、如何让讉K��分配到这两台机器上，�q�个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS�q�类的��Y件负载均衡方案；
2、如何保持状态信息的同步�Q�例如用户session�{�，�q�个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息�{�机制等�Q?br /> 3、如何保持数据缓存信息的同步�Q�例如之前缓存的用户数据�{�，�q�个时候通常会考虑的机制有�~�存同步或分布式�~�存�Q?br /> 4、如何让上传文�g�q�些�c�M��的功能��l�正常，�q�个时候通常会考虑的机制是使用�׃�n文�g�pȝ��或存储等�Q?br /> 在解决了�q�些问题后，�l�于是把webserver增加��Z��两台�Q�系�l�终于是又恢复到了以往的速度�?/span>

看看�q�一步完成后�pȝ��的图�C�：

�q�一步涉及到了这些知识体�p�：

负蝲均衡技术（包括但不限于��g负蝲均衡、��Y件负载均衡、负载算法、linux转发协议、所选用的技术的实现�l�节�{�）、主备技术（包括但不限于ARP�ƺ骗、linux heart-beat�{�）、状态信息或�~�存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现�l�节�{�）、共享文件技术（包括但不限于NFS�{�）、存储技术（包括但不限于存储讑֤��{�）�?/span>

架构演变�W�六步：分库

享受了一�D�|��间的�pȝ��讉K��量高速增长的�q�福后，发现�pȝ��又开始变慢了�Q�这�ơ又是什么状况呢�Q�经�q�查找，发现数据库写入、更新的�q�些操作的部分数据库�q�接的资源竞争非常激烈，��D��了系�l�变慢，�q�下怎么办呢�Q�此时可选的�Ҏ��有数据库集群和分库策略，集群斚w��像有些数据库支持的�ƈ不是很好�Q�因此分库会成�ؓ比较普遍的策略，分库也就意味着要对原有�E�序�q�行修改�Q�一通修改实现分库后�Q�不错，目标辑ֈ�了，�pȝ��恢复甚至速度比以前还快了�?/span>