电商系统处理
千万人同时访问的网站，一般是有很多个数据库同时工作，说明白一点就是数据库集群和并发控制，这样的网站实时性也是相对的。这些网站都有一些共同的特点：数据量大，在线人数多，并发请求多，pageview高，响应速度快。总结了一下各个大网站的架构，主要提高效率及稳定性的几个地方包括：
1、程序
程序开发是一方面，系统架构设计（硬件+网络+软件）是另一方面。
软件架构方面，做网站首先需要很多web服务器存储静态资源，比如图片、视频、静态页等，千万不要把静态资源和应用服务器放在一起。
一个好的程序员写出来的程序会非常简洁、性能很好，一个初级程序员可能会犯很多低级错误，这也是影响网站性能的原因之一。
网站要做到效率高，不光是程序员的事情，数据库优化、程序优化这是必须的，在性能优化上要数据库和程序齐头并进！缓存也是两方面同时入手。第一，数据库缓存和数据库优化，这个由dba完成（而且这个有非常大的潜力可挖，只是由于我们都是程序员而忽略了他而已）。第二，程序上的优化，这个非常的有讲究，比如说重要一点就是要规范ＳＱＬ语句，少用in 多用or，多用preparestatement，另外避免程序冗余如查找数据少用双重循环等。另外选用优秀的开源框架加以支持，我个人认为中后台的支持是最最重要的，可以选取spring＋ibatis。因为ibatis直接操作SQL并有缓存机制。spring的好处就不用我多说了，ＩＯＣ的机制可以避免new对象，这样也节省开销。据我分析，绝大部分的开销就是在NEW的时候和连接数据库时候产生的，请尽量避免。另外可以用一些内存测试工具来做一个demo说明hibernate和ibatis谁更快！前台你想用什么就用什么，struts,webwork都成，如果觉得自己挺牛X可以试试tapestry。
用数据库也未必不能解决访问量巨大所带来的问题，作成静态文件硬盘的寻址时间也未必少于数据库的搜索时间，当然对资料的索引要下一翻工夫。我自己觉得门户往往也就是当天、热门的资料点击率较高，将其做缓存最多也不过1~2G的数据量吧，举个例子：
拿网易新闻来看
格式化一下，方便理解：http://域名/年/月日/新闻所属分类/新闻ID.html
可以把当天发布的、热门的、流揽量大的作个缓寸，用hashtable（key：年-月-日-分类-ID，value：新闻对象），静态将其放到内存（速度绝对快过硬盘寻址静态页面）。
通常是采用oracle存储过程＋2个weblogic，更新机制也几乎一样每签发一条新闻，就会生成静态页面，然后发往前端的web服务器，前端的web都是做负载均衡的。另外还有定时的程序，每5-15分钟自动生成一次。在发布新闻的同时将数据缓存。当然缓存也不会越来越大，在个特定的时间段（如凌晨）剔除过期的数据。做一个大的网站远没有想象中那么简单，服务器基本就要百十个的。
这样可以大大增加一台计算机的处理速度，如果一台机器处理不了，可以用httpserver集群来解决问题了。
2、网络
中国的网络分南北电信和网通，访问的ip就要区分南北进入不同的网络。
3、集群
通常会使用CDN与GSBL与DNS负载均衡技术，每个地区一组前台服务器群，例如：网易，百度使用了DNS负载均衡技术，每个频道一组前台服务器，一搜使用了DNS负载技术，所有频道共用一组前台服务器集群。
网站使用基于Linux集群的负载均衡，失败恢复，包括应用服务器和数据库服务器，基于linux-ha的服务状态检测及高可用化。
应用服务器集群可以采用apache+tomcat集群和weblogic集群等；web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；Squid也可以，方法很多，可以根据情况选择。
4、数据库
因为是千万人同时访问的网站，所以一般是有很多个数据库同时工作的，说明白一点就是数据库集群和并发控制，数据分布到地理位置不同的数据中心，以免发生断电事故。另外还有一点的是，那些网站的静态化网页并不是真的，而是通过动态网页与静态网页网址交换做出现的假象，这可以用urlrewrite 这样的开源网址映射器实现。这样的网站实时性也是相对的，因为在数据库复制数据的时候有一个过程，一般在技术上可以用到hibernate和 ecache，但是如果要使网站工作地更好，可以使用EJB和websphere，weblogic这样大型的服务器来支持，并且要用oracle这样的大型数据库。
大型门户网站不建议使用Mysql数据库，除非你对Mysql数据的优化非常熟悉。Mysql数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力。
大型网站要用oracle，数据方面操作尽量多用存储过程，绝对提升性能；同时要让DBA对数据库进行优化，优化后的数据库与没优化的有天壤之别；同时还可以扩展分布式数据库，以后这方面的研究会越来越多；
5、页面
从开始就考虑使用虚拟存储/簇文件系统。它能让你大量并行IO访问，而且不需要任何重组就能够增加所需要的磁盘。
页面数据调用更要认真设计，一些数据查询可以不通过数据库的方式，实时性要求不高的可以使用lucene来实现，即使有实时性的要求也可以用lucene，lucene+compass还是非常优秀的。
新闻类的网站可以用静态页存储，采用定时更新机制减轻服务器负担；首页每个小模块可以使用oscache缓存，这样不用每次都拉数据。
前端的基于静态页面缓存的web加速器，主要应用有squid等。squid 将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载网站的静态化网页并不是真的，而是通过动态网页与静态网页网址交换做出现的假象，这可以用urlrewrite这样的开源网址映射器实现，后缀名为htm或者html并不能说明程序生成了静态页面，可能是通过 url重写来实现的，为的只不过是在搜索引擎中提升自己网站的覆盖面积罢了。
生成静态页面的服务器和www服务器是两组不同的服务器，页面生成后才会到www服务器，一部分数据库并不是关系数据库，这样更适合信息衍生，www、mail服务器、路由器多，主要用负载平衡解决访问瓶颈。
静态页面的缺点：
1) 增加了程序的复杂度
2) 不利于管理资料
3) 速度不是最快
4) 伤硬盘
6、缓存
从一开始就应该使用缓存，高速缓存是一个更好的地方存储临时数据，比如Web站点上跟踪一个特定用户的会话产生的临时文件，就不再需要记录到数据库里。
不能用lucene实现的可以用缓存，分布式缓存可以用memcached，如果有钱的话用10来台机器做缓存，> 10G的存储量相信存什么都够了；如果没钱的话可以在页面缓存和数据缓存上下功夫，多用OSCACHE和EHCACHE，SWARMCACHE也可以，不过据说同步性不是很好；
可以使用Memcache进行缓存，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，memcache是LJ开发的一款分布式缓存产品，很多大型网站在应用，我们可以把Cache Server与AppServer装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。
根据我现有的阅读和谈话，我所理解的今天Facebook的架构如下：
Web 前端是由 PHP 写的。Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译，这样就可以为模板和Web逻贺业务层提供高的性能。
业务逻辑以Service的形式存在，其使用Thrift [2]。这些Service根据需求的不同由PHP，C++或Java实现（也可以用到了其它的一些语言……）
用Java写的Services没有用到任何一个企业级的应用服务器，但用到了Facebook自己的定制的应用服务器。看上去好像是重新发明轮子，但是这些Services只被暴露给Thrift使用（绝大所数是这样），Tomcat太重量级了，即使是Jetty也可能太过了点，其附加值对Facebook所需要的没有意义。
持久化由MySQL, Memcached [3], Facebook 的 Cassandra [4], Hadoop 的 HBase [5] 完成。Memcached 使用了MySQL的内存Cache。Facebook 工程师承认他们的Cassandra 使用正在减少，因为他们更喜欢HBase，因为它的更简单的一致性模型，以到其MapReduce能力。
离线处理使用Hadoop 和 Hive。
日志，点击，feeds数据使用Scribe [6]，把其聚合并存在 HDFS，其使用Scribe-HDFS [7]，因而允许使用MapReduce进行扩展分析。
BigPipe [8] 是他们的定制技术，用来加速页面显示。
Varnish Cache [9]用作HTTP代理。他们用这个的原因是高速和有效率。 [10].
用来搞定用户上传的十亿张照片的存储，其由Haystack处理，Facebook自己开发了一个Ad-Hoc存储方案，其主要做了一些低层优化和“仅追加”写技术 [11].
Facebook Messages 使用了自己的架构，其明显地构建在了一个动态集群的基础架构上。业务逻辑和持久化被封装在一个所谓的’Cell’。每个‘Cell’都处理一部分用户，新的‘Cell’可以因为访问热度被添加[12]。持久化归档使用HBase [13]。
Facebook Messages 的搜索引擎由存储在HBase中的一个倒置索引的构建。 [14]
Facebook 搜索引擎实现细节据我所知目前是未知状态。
Typeahead 搜索使用了一个定制的存储和检索逻辑。 [15]
Chat 基于一个Epoll 服务器，这个服务器由Erlang 开发，由Thrift存取 [16]
关于那些供给给上述组件的资源，下面是一些信息和数量，但是有一些是未知的：
Facebook估计有超过60,000 台服务器[16]。他们最新的数据中心在俄勒冈州的Prineville，其基于完全自定设计的硬件[17] 那是最近才公开的 Open Compute 项目[18]。
300 TB 的数据存在 Memcached 中处理 [19]
他们的Hadoop 和 Hive 集群由3000 服务器组成，每台服务器有8个核，32GB的内存，12TB的硬盘，全部有2万4千个CPU的核，96TB内存和36PB的硬盘。 [20]
每天有1000亿的点击量，500亿张照片，100 billion hits per day， 50 billion photos, 3 万亿个对象被 Cache，每天130TB的日志（2010年7月的数据） [21]
北京时间4月8日消息，据国外媒体报道，北京时间今天凌晨在其总部举行发布会，公开了底层服务器和数据中心的具体方案。
Facebook此次公开了服务器电源供应、服务器机箱、服务器主板、服务器机柜、后备电源机柜规格。另外，它还公开了数据中心电力及机械系统规格的具体规格。通过公开这些情况，Facebook展示了它在为不同任务配置合适的计算工作量时，是如何尽可能降低能耗和成本的。
Facebook的方案有一些创新之处，比如风扇更大但数量较少。这些风扇占每台服务器能源消耗的2-4%，远远低于行业中10-20%的平均水平。以下是方案中的具体细节：
服务器方面：
1、服务器使用1.2mm镀锌、防腐蚀钢板，无前面板；
2、部分部件采用卡和连接：主板利用多个安装孔，卡入机箱；硬盘使用咬合导轨，安装在驱动器托架上。一个单元只有一个接地螺丝。这使得Facebook可以在3分钟内搭建整台服务器；
3、Facebook服务器高1.5U，比一般服务器高50%，空间更大，散热也更快；
4、具有局域网重启功能，可以让系统管理员发送特定网络指令，立即重启服务器；
5、主板扬声器被替换为LED指示灯，以节省电源，服务器还提健康状态指示灯；
6、同时支持交流和直流电源，使得服务器可以在停电时转为直流后备电池供电；
7、使用Xeon 5500系列和5600系列两种处理器，搭载英特尔主板，内置英特尔5500 I/O Hub芯片，内存最大可扩展至144GB。AMD的粉丝可以选择两个Magny-Cours 12核心或8核心处理器，搭配AMD SR5650芯片组，内存最高可扩展至192GB。
数据中心方面：
Facebook不仅公开了服务器方案，同时它还公开了数据中心的设计方案，以便能帮助其他初创公司建立自己的基础架构，并尽可能的减少功率消耗。
Facebook将这些方案都运用到了位于俄勒冈州的普林维尔（Prineville）数据中心上。用了两年的时间，从服务器到电池组再到后备服务器，Facebook致力于让设备变得更加绿色、环保。比如，Facebook利用集成设计，可以有效的降低能耗。房间内的风扇和服务器风扇成对连接在一起。动作感应LED照明也可用于内部照明。
整个数据中心的能耗按PUE（Power Usage Effectiveness，电能使用效率）衡量是1.07，大大低于美国环保署规定的最优方法比值1.5。
Facebook的设计方案可以让设备在更为潮湿的环境中运行。普林维尔数据中心的设备运行环境为30摄氏度、65%的相对湿度。这样可以使Facebook依赖蒸发冷却来降温，而不需使用空调。其他建设工程方面的创新还包括，普林维尔数据中心使用277伏特的配电系统，而一般数据中心使用的是208伏特的配电系统。Facebook的做法可以减少一个主变压器，减少转换时的能耗。在一般的数据中心中，电力转换要损失22-25%的能量。在普林维尔只损失7%。
当办公室太冷的时候，Facebook还利用来自服务器的热量加热空气。夏天，数据中心会向进入室内的暖空气喷水降温。同时Facebook数据中心的机箱和服务器设计也非常适合于集装箱装运，这样可以减少运输中的浪费。Facebook的方案尽可能挖掘这些服务器的潜能，使得它不需要在进行基础架构的建设。
虽然并不是每家初创公司都要打造这种规模的数据中心，但Facebook公布的方案肯定会在数据中心运营商和提供商中引起话题争论。
