揭秘全球最大网站Facebook背后的那些软件,揭秘facebookFacebook独占
揭秘全球最大网站Facebook背后的那些软件,揭秘facebookFacebook独占
2010年6月，Google公布全球Top 1000网站。Facebook独占鳌头。
以Facebook现在的经营规模，诸多传统服务器的技术均将崩溃或根本无法支撑。那么面对5亿的活跃用户，Facebook的工程师们又将如何让网站平 稳运转呢？伯乐在线 – 职场博客的这篇文章将展示Facebook的工程师完成这个艰巨任务所用到的一系列软件。
Facebook级别规模的挑战
在我们深入细节之前，先了解一组Facebook不得不面对数据，你就可以想象这种规模。
1.Facebook每月的PV量：630，000，000，000 （6万3千亿）
2.Facebook上的图片数量超过其他图片网站的总和（包括诸如Flickr这样的图片网站）
3.每个月有超过30亿的图片上传到Facebook
4.Facebook系统每秒可以处理120万张图片。这还不包括Facebook的CDN处理的图片。
5.每月处理超过250亿的信息内容（包括用户状态更新，评论等）
6.Facebook的服务器数量超过3万台（此数据为2009年的数据）
Facebook所用的软件
从某些方面来说，Facebook还是属于LAMP类型网站，但是，为了配合其他大量的组件和服务，Facebook对已有的方法，已经做了必要的改变、拓展和修改。
比如：
1.Facebook依然使用PHP，但Facebook已重建新的编译器，以满足在其Web服务器上加载本地代码，从而提升性能；
2.Facebook使用Linux系统，但为了自身目的，也已做了必要的优化。（尤其是在网络吞吐量方面）；
3.Facebook使用MySQL，但也对其做优化。
还有定制的系统，比如， Haystack — 高度可扩展的对象存储，用来处理Facebook的庞大的图片；Scribe — Facebook的日志系统。
下面展现给大家的是，全球最大的社交网站Facebook所使用到的软件。
Read More »
Author:admin | Categories:系统架构| Tags:facebook、hadoop、Scribe
No Comments
mysql数据库集群架设、mysql数据库负载均衡配置、mysql数据库优化
2011-07-06负载均衡的配置、集群架设一、介绍网站效率优化一点总结
2011-06-18
当一个网站达到一定级别后很容易出现效率问题，各个环节都有可能：比如数据库，前台服务器负载过高，IO吃紧；数据增大缓存不够用或者用来同步数据的网络开销过大等。下面就自己项目遇到的问题和可采取的优化办法进行讨论，欢迎指教。（我们的项目目前日pv在2000w左右）
最开始的时候，我们的项目拥有两台前台服务器，采用dns分流的方法做负载均衡。随着流量增加，前台两台服务器变得异常得卡，访问页面延迟增加，服务器上明显表现就是cpu负载很高，idle几乎保持接近0.登录到服务器操作一些东西反应很慢。这个时候明显服务器不够用了，同时因为前台服务器响应缓慢，造成很多请求拥堵，因为前台和数据库之间是使用长连接，所以间接也影响到了数据库，导致数据库经常超出连接数（我们设置的连接数是800）。当然要增加机器，我们增加了2台服务器，同样做dns分流，这样就有2台电信，2台网通来服务。所以第一条就是增加硬件资源，简单高效。
接下来，随着流量继续攀升，发现数据库连接数一直维持在比较高的水平，很容易就爆了。而且数据库渐渐表现出来IO繁忙，读大概是6-10M/s，因为代码上暂时没有做分库考虑，所以我们准备将用来备份的从数据库用来服务前台读请求。好在代码读写是分离的（也就是每个cgi连到数据库都是2个连接，一个写，一个读），所以很容易就可以把前台的读请求切换到从数据库，这样主数据库一下就清闲了下来，主数据库主要负责写操作，解放了主数据库，主数据库从此悠闲，而从数据库从此肩负了前台大量的读请求。
后来，我们发现从数据库因为读的负担比较重，导致从数据同步主数据库数据出现延迟，这个时候我其实考虑过有没办法修改mysql源码，提高同步线程的优先级来解决。最终没有这么做，因为我们很快加入了新的一台从数据库，现在是两台从数据库来分担前台的大部分读请求，因此情况得到缓解。
再后来，流量继续爬高，导致两台从数据都出现同步延迟了。当然第一反映就是：再加从数据库？再加数据库也许是个解决办法，但是同时也要考虑其他问题，比如：如果都从主数据库同步，会不会增加主数据压力？我们尝试了以下几种办法：
1.静态化页面
我们的项目类似于新闻系统，但是又有区分。所以我们考虑静态化列表页面，每10分钟重新生成一次。结构大致是这样的：每隔10分钟，A机器就刷一次数据库，重新生成列表页面，然后把这些页面同步到B，C等前台机器上，然后前台机器同时设置http expire头来减少浏览器的请求，设置last modify头减少网络传输。这样做是有效果的，一方面减轻了前台压力，同时也减少了数据库请求。但是发现了另一个问题：A机器定期会对数据库造成一个洪峰式的冲击，而且这种主动生成方式非常盲目，另一方面要生成所有的列表页面，在不压缩页面的情况下大概好几G，要在几分钟内生成好几G的页面同时同步到前台各个机器，这对A机器和前台都是很大考验。实际当中我们也发现，只是生成了部分列表页面，A机器已经比较繁忙了。
2.mod_cache
和静态化类似，使用mod_cache可以改主动为被动，使得生成页面不再盲目。结构大致是这样：前台四台服务器都配置mod_cache，缓存5分钟，每当本地没有该页面或者已经过期的时候就去请求A机器拿新的页面并缓存到本地。这种做法代码改动很小，而且作为apache模块，不需要考虑fastcgi或者wsgi建立新进程来服务的开销（指前台机器上）。考虑到有4台服务器都从A机器上拿，实际上A机器上面还可以做一层mod_cache，即前台请求A，A请求自己生成静态页面，然后把静态页面返回给前台，剩下的前台请求A的时候就直接拿已经生成的静态页面就可以了。这种方法很遗憾没有很好地实际测试过，但我觉得是可行的，特别是如果能将生成的静态页面再做gzip压缩，减少A机器和前台的网络传输消耗效率会更高。
3.memcache
memcache和mod_cache其实很像，一个是使用内存，一个是使用磁盘。出乎我们意料的是，相比静态文件好几G的磁盘消耗，使用memcache缓存到内存只占了几百M，这都归功于memcache的压缩。
使用memcache，项目的结构和mod_cache也很像，前台收到请求后去内存拿数据，拿不到则从数据库拿然后再设置到内存。这台memcache机器就像第二点当中那台A机器，但是使用memcache本身有以下几个优势：第一，数据传输已经被压缩，占用内存小，网络传输消耗小；第二，从实际观察发现，memcache这台服务器非常高效，占用cpu极低，和使用mod_cache相比，相当于把A机器的压力分散到了前台机器上（使用memcache仍然都是前台在请求数据库，使用mod_cache则只有A服务器在请求数据库）。这样的话分散压力，提高效率。
实际测试发现，最终上面三种都没用在我们项目中，memcache也没有。原因是我们的项目有点特别，类似于新闻但又不完全相同，类似于游戏分区，每个分区里面有自己的列表，memcache命中率稳定在65%左右，因为尽管总访问量比较大，但是分散到每个区，再到每个区里面每个列表，缓存的命中率并不是很高。
最终我们又回归到了最开始的做法，我们增加了一台比较强悍一点的机器来做从数据库，事实也证明了这样可行。原因是我们发现从数据肩负了主要的读请求，但是之前的从数据库机器都比较烂，4G的机器，2核至强cpu，都是游戏淘汰下来的机器，平时负载在3-4，而且使用了比较多swap，这说明机器内存可能不足了。新机器换用8G内存，4核至强cpu，现在一台机器担当了4台前台服务器的读请求，负载稳定在0.3。
将来，我觉得我们的方向仍然是增加缓存，改变缓存的策略，考虑到memcache这么节约内存，可以把常用的请求对象全部丢到内存里面，相当于内存里保存了数据库部分数据的完整拷贝，这样列表的请求和详细页面的请求都只靠请求memcache就可以完成，不像之前提到的使用memcache，仍存在大量对数据库的请求，同时缓存的内容过期率比较高。这样做相当于mysql的query cache的一个延伸了。
总结下，我觉得一些可行的网站效率优化办法：
1.硬件是硬道理
2.使用从数据库分离读写请求
3.静态化页面
4.使用memcache或者mod_cache（即使用内存或者磁盘来做缓存）
转自：http://blog.moonforest.org/tag/memcache/
Author:admin | Categories:性能优化、系统架构| Tags:
No Comments
为什么我们钟情于LAMP平台——LAMP网站架构方案分析
2011-06-14
LAMP（Linux-Apache-MySQL-PHP）网站架构是目前国际流行的Web框架，该框架包括：Linux操作系统，Apache网 络服务器，MySQL数据库，Perl、PHP或者Python编程语言，所有组成产品均是开源软件，是国际上成熟的架构框架，很多流行的商业应用都是采 取这个架构，和Java/J2EE架构相比，LAMP具有Web资源丰富、轻量、快速开发等特点，微软的.NET架构相比，LAMP具有通用、跨平台、高 性能、低价格的优势，因此LAMP无论是性能、质量还是价格都是企业搭建网站的首选平台。
对于大流量、大并发量的网站系统架构来说，除了硬件上使用高性能的服务器、负载均衡、CDN等之外，在软件架构上需要重点关注下面几个环节：使用高 性能的操作系统（OS）、高性能的网页服务器（Web Server）、高性能的数据库（Databse）、高效率的编程语言等。下面我将从这几点对其一一讨论。
操作系统
Linux操作系统有很多个不同的发行版，如Red Hat Enterprise Linux、SUSE Linux Enterprice、Debian、Ubuntu、CentOS等，每一个发行版都有自己的特色，比如RHEL的稳定，Ubuntu的易用，基于稳定性 和性能的考虑，操作系统选择CentOS（Community ENTerprise Operating System）是一个理想的方案。
CentOS（Community ENTerprise Operating System）是Linux发行版之一，是RHEL/Red Hat Enterprise Linux的精简免费版，和RHEL为同样的源代码，不过，RHEL和SUSE LE等企业版，提供的升级服务均是收费升级，无法免费在线升级，因此要求免费的高度稳定性的服务器可以用CentOS替代Red Hat Enterprise Linux使用。
LAMP网站架构图
Web服务器、缓存和PHP加速
Apache是LAMP架构最核心的Web Server，开源、稳定、模块丰富是Apache的优势。但Apache的缺点是有些臃肿，内存和CPU开销大，性能上有损耗，不如一些轻量级的Web 服务器（例如nginx）高效，轻量级的Web服务器对于静态文件的响应能力来说远高于Apache服务器。
Apache做为Web Server是负载PHP的最佳选择，如果流量很大的话，可以采用nginx来负载非PHP的Web请求。nginx是一个高性能的HTTP和反向代理服 务器，Nginx以它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx不支持PHP和CGI等动态语言，但支持负载均衡和容 错，可和Apache配合使用，是轻量级的HTTP服务器的首选。
Web服务器的缓存也有多种方案，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高 Apache的访问响应能力。Squid Cache是一个Web缓存服务器，支持高效的缓存，可以作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，把Squid放在 Apache的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。如访问量巨大则可考虑使用memcache作 为分布式缓存。
PHP的加速使用eAccelerator加速器，eAccelerator是一个自由开放源码PHP加速器，优化和动态内容缓存，提高了性能 PHP脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。它还有对脚本起优化作用，以加快其执行效率。使PHP程序代码执效率 能提高1-10倍。
具体的解决方案有以下几种：
1、squid + Apache + PHP + eAccelerator
使用Apache负载PHP，使用squid进行缓存，html或图片的请求可以直接由squid返回给用户。很多大型网站都采用这种架构。
2、nginx/Apache + PHP（fastcgi） + eAccelerator
使用nginx或Apache负载PHP，PHP使用fastcgi方式运行，效率较高。
3、nginx + Apache + PHP + eAccelerator
此方案综合了nginx和Apache的优点，使用Apache负载PHP，nginx负责解析其他Web请求，使用nginx的rewrite模块，Apache端口不对外开放。
数据库
开源的数据库中，MySQL在性能、稳定性和功能上是首选，可以达到百万级别的数据存储，网站初期可以将MySQL和Web服务器放在一起，但是当 访问量达到一定规模后，应该将MySQL数据库从Web Server上独立出来，在单独的服务器上运行，同时保持Web Server和MySQL服务器的稳定连接。
当数据库访问量达到更大的级别，可以考虑使用MySQL Cluster等数据库集群或者库表散列等解决方案。
总的来说，LAMP架构的网站性能会远远优于Windows IIS + ASP + Access这样的网站，可以负载的访问量也非常大，国内的大量个人网站如果想要支撑大访问量，采用LAMP架构是一个不错的方案。
综上所述，基于LAMP架构设计具有成本低廉、部署灵活、快速开发、安全稳定等特点，是Web网络应用和环境的优秀组合。
评论暂时关闭