<![CDATA[张宴的博客]]> http://www.lukangtou.cn/index.php zh-cn http://www.lukangtou.cn/cubieboard/ <![CDATA[iPhone大小的盒子服务器Cubieboard]]> 张宴 <net@s135.com> Mon, 25 Mar 2013 07:57:38 +0000 http://www.lukangtou.cn/cubieboard/
  1G ARM cortex-A8 processor, NEON, VFPv3, 256KB L2 cache
  Mali400, OpenGL ES GPU
  512M/1GB DDR3 @480MHz
  HDMI 1080p Output
  10/100M Ethernet
  4GB Nand Flash
  2 USB Host, 1 micro SD slot, 1 SATA, 1 ir
  96 extend pin including I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP..
  Running Android, Ubuntu and other Linux distributions

  点击在新H口中浏览此囄

  点击在新H口中浏览此囄

  找了台支持HDMI的显C器Q安装了Ubuntu LinaroQ然后很方便的安装了SSH Server、VNC Server、Nginx、PHP 5.3、MySQL 5.5Q?br/>
apt-get install openssh-server
apt-get install vnc-server
apt-get install mysql-server mysql-client
apt-get install nginx
apt-get install php5-fpm
apt-get install php5-mysql php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl


  C/C++的开发环境安装:
apt-get install gcc
apt-get install g++
apt-get install cmake
apt-get install make


............

Tags - , , , , ,
Q?br/>
  L人:冯大辉,CQ丁香?Q?a target="_blank">http://www.dxy.cnQ网站CTO。曾历Q支付宝架构师、数据库团队负责人等职?br/>
点击在新H口中浏览此囄  许式伟:作ؓpȝ架构师,您一般会从哪些方面来保证|站的高可用性(降低故障旉Q?

  张宴Q?/strong>很多因素都会D|站发生故障Q从而媄响网站的高可用性,比如服务器硬件故障、Y件系l故障、IDC机房故障、程序上U前试未发现的Bug、遭受分布式d、突发访问h数剧增等?br/>
  一套良好的|站pȝ架构Q应该尽可能地避免只有一台服务器、一个数据库、一套Y件节点等单点故障的存在。单Ҏ障一旦发生,直接导致网站服务不可用Q恢复正常服务所需的时间也比较长,甚至q可能无法恢复。负载均衡集、双节点热备、分布式处理{都可以用来解决单点故障Q比如提供相同业务的Web服务器、MySQL数据库从库,都可以构载均衡集。一旦集中的一台服务器、一个服务出现故障,自动实时摘除Q对用户来说是不可感知的Q不会媄响到整个|站的访问,可以l工E师留下_的时间去排查和解x障?br/>
  对于重要的MySQL数据库主库,我们习惯于从g层和软g层来实现热备Q避免单炏V越是复杂的讑֤Q发生故障的概率大。在盘没有损坏的情况下Q应用程序导致服务器宕机的概率,q高于简单的盘阵列宕机的概率。所以,从硬件层解决的话Q可以在两台服务器上安装相同的数据库版本、进行相同的配置Q用SAS或SCSIU连接一台磁盘阵列,数据库数据文g存放到盘阵上。正常情况下用服务器A挂蝲盘阵分区Q启动MySQLQ绑定虚拟IPQ如果服务器A宕机Q则用服务器B挂蝲盘阵分区Q启动MySQLQ接虚拟IP。从软g层解决的话,则可以借助DRBD{Y件做镜像?br/>
  IDC机房发生故障的概率较,但如果发生的话,影响面也是最大的。如果所有服务器都托在一个IDC机房Q一旦该机房遭遇长时间流量攻凅R断c断|、地Ҏ{性封|等Q通常只能联系IDCd理,除此之外束手无策Q解x间也比较ѝ如果成本允许,网站服务器分布在两个以上的IDC机房Q当某个IDC发生故障Ӟ可以临时切换DNS域名解析来优先恢复服务?br/>
  虽然E序代码上线前,l过了测试h员的严格试Q但试环境和生产环境毕竟有差异Q所以一些会急剧影响性能、正常服务的Bug往往在程序上U之后,才会被发玎ͼq就要求我们在发现Bug后,能够q速回滚到上一正常版本。我们在SVN的基上,开发了Web代码发布pȝQ会每个发布版本之间的文g变更记录下来Q一键实现程序代码在多台Web服务器上的发布和回滚?br/>
  遭遇DDOS分布式拒l服务攻击,使用防火墙来对付半连接、假IPQ还比较容易。而U专挑复杂动态应用程序URLq行的分布式CCdQ来源ؓ真实IP、真实HTTPhQ具有模拟正规浏览器User-Agent、单个IP的每U请求数不高、有成千上万个攻L{特征,很难与正常访问区分开Q比较难对付。但是,正常通过览器访问一个URLQ会加蝲该URL中引入的JavaScript脚本、CSS样式、图片等文g。遇到CCdQ需要及时分析日志,扑և讉K量异怸涨的URLQ然后用事先写好的shell脚本扑և哪些IP的请求只讉K了该URLQ而不加蝲该URL引入的文Ӟ对这些IPq行自动锁?br/>
  pȝ架构设计Ӟ需要事先考虑到高于目前访问量多少倍的H发讉K。对于网游站Ҏ_讉K量受q告集中旉D|放、线上活动的影响较大Q带宽峰值时间不固定Q对于静态内容,可以使用商业CDNQ按实际使用量计贏V对于动态内容,如果遇到H发讉K人数剧增Q超q现有服务器处理能力Q最单的临时处理办法是增加服务器。上架新服务器需要时_但是Q同一个IDC机房内,可以借助其他业务的服务器Q在不同端口开启一l新q程Q加入到原有负蝲均衡池中。另外,可以临时关闭一些Web中的ơ要功能Q来减少服务器消耗?br/>


  许式伟:您在d切分上,有什么经验分享?您通过哪些手段保证d的独立性?

  张宴Q?/strong>怿很多人都遇到q这U情况:在一个老项目上修改、增加一些新功能所p的时_不比重新来做一个包含所有功能的新项目时间用得少。一个需要长期维护的目Q不可避免地会面临老员工的职、新员工的接手,很多时候,目代码的可l护性将军_一个项目的生存周期。让一个新员工在规定开发时间的压力下,去面对一个文不够详l、陌生的、功能复杂的庞大目Q短旉弄明白所有功能逻辑不是一件容易的事。所以,d需要切分,一个大的Q务切分成一个个模块之后,各模块之间可以做C码独立,互不影响Q可l护性也大大增强?br/>
  关于d切分Q我以本Zq负责的两个重要目架构设计Z来介l一下。在W一个项目:金山游戏官网的《用戯为分析系l》中Q由于数据挖掘计需要消耗较高的内存、CPU资源Q一台服务器的处理能力不够,而商业的分布式数据仓库h格又太贵Q所以,只有从程序应用中下手Q进行Q务切分。我们先按需要挖掘的数据指标Q将整个数据挖掘d切分成多个数据挖掘插Ӟ每个插g可以在不同的服务器上q行Q多个插件可以同时在多台服务器上。多个数据挖掘插件之_如果用到相同的某Ҏ据,那么Q就该Ҏ据以冗余方式Q复制几份提供给需要的插gQ从而实现插件之间无交互、无兌Q保证了大数据量下插g的运速度?br/>
  在第二个目Q金山游戏新版运营管理系l中Q则整个Q务切分成了PHP Web理界面、PHP Web API功能接口、C/C++中间件引擎三部分。这是一U分层结构切分,最上层的“PHP Web理界面”调用“PHP Web API功能接口”,“PHP Web API功能接口”调用运行在游戏服务器端的“C/C++中间件引擎”,“C/C++中间件引擎”与“游戏服务器端进E”通过TCP、UDP二进制协议、信受命令行{多U方式通信。四者之间相对独立,代码无关联,通过一层层API接口实现交互。“PHP Web理界面”负责通用界面实现。“PHP Web API功能接口”内部,又按接入的游戏模块、子功能模块q行了更l的切分Q各功能模块之间通过内部API交互。“C/C++中间件引擎”大而全Q不处理具体指oQ但兼容TCP、UDP、HTTP、HTTPS/SSL、信受命令行{大多数通信方式Q负责和各种cd的游戏服务端交互。这是一套完全由API接口驱动的系l架构,一ƾ新游戏接入q营理pȝӞ只需在“PHP Web API功能接口”中增加一个模块;一个游戏新理功能的增加,只需要在“PHP Web API功能接口”中增加一个子模块。通过d切分Q将复杂功能单化Q也原来接入一ƾ新游戏所需要的几个月时_~短?~2周?br/>


  许式伟:您通过哪些手段Q来保障产品的质量?您們֐于多久更Cơ您的网站?

............

Tags - ”的目架构为原型,对Web商业q_的架构设计进行了概要介绍。实现v量数据的分析挖掘计算相对较易Q如何以灉|的可扩展性框Ӟ来便捷地应对目开发周期中Q来自众多项目干pMh的需求变_才是隄?br/>
............

Tags - , , , , , , , ]]> http://www.lukangtou.cn/post/414/ <![CDATA[从“军事战争”ȝ了一些服务器架构思考[原创]]]> 张宴 <net@s135.com> Thu, 28 May 2009 07:31:02 +0000 http://www.lukangtou.cn/post/414/ http://blog.www.lukangtou.cn/post/414/]

  “客L讉K”与“服务器端响应”,犹如一场战争。初期,讉K量较,弄几台服务器随便拉v一只队伍,p抉|住客L的进攅R慢慢的Q访问量大v来,q时候,需要讲I排兵布c战略战术、多늧协调作战。于是,开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器{多늧Q开始有了系l架构等战略战术。随着新项目和q营需求的来多Q我们开始了多线作战。慢慢地Q我ȝ了以下一些思考:

  1、“收~绿林队伍”与“自己招兵买马”:

  两者的关系q如“用开源Y件、框架”与“自己开发模块、写框架”,如果已有的开源Y件、框架、架构能够较好地用于自己的项目,q便于扩展,则优先用开源YӞ如果没有现成的东西,或者已有的开源Y件性能不高、扩展性差、学习成本高Q则可以取长补短Q在目中打造自q“队伍”?br/>

  2、适当利用“雇佣军”:

  在多个项目同时进行时Q不要认p打赢每一场战斗,而每一场战斗都p׃自去打。确实,我相信很多h能够打赢一场场战斗Q却只有数够打赢一场战争。前暴雪北方“四大{”创建的旗舰工作室的倒闭Q印证了q样一个事实:一天才,却没有让一个划时代意义的游戏诞生。旗舰工作室攄捷径不走却事必躬Ԍ自己做客L、自己做语聊pȝ、自己做囑փ引擎、自己做客服pȝQ最l自p自己l拖垮了?br/>
  不要让战U拉得太q,适当利用“雇佣军”,目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务,旉、费用、维护成本可能要更低。最q,我工作中的两Ҏ务用了“雇佣军”:(1)、购买ChinaCache CDN的Flash Media ServerҎ加速服务,支撑金山游戏视频宣传站点Q节省了部v多节点的成本和时_(2)、购买快|的DNS解析服务Q来做金山游戏官|动态内容“北京多Uѝ珠L信、天z网通”三个机房服务器的智能DNS解析服务Q节省了攉、整理,来更新l护IP信息{工作?br/>

  3、打造“高技术兵器”:

  C战争的特炚w拥一个有共同的前提那是Q都不可能离开“高技术兵器”。同P要想承担高ƈ发访问,而又希望pȝ架构单一炏V程序开发快捷一点,那么Q则需要一ƾ服务器端的“高技术兵器”。Web 2.0|站主要l成部分有内定w和列表页Q内定w可以采用key-value形式的Memcached、Squid{开源品来实现~存Q高q发讉K下需要实时更新的列表늼存,目前q没有合适的开源品来解决。MySQL{数据库在高q发q接、大数据记录情况下性能低下Q实时更新的列表,成ؓ最主要的瓶颈。我目前正在Z一些开源类库,开发的一Ƅ单关pd数据库,实现MySQL单表拥有的大部分复杂条g查询功能Qƈ达到单表千万以上记录下,Memcached 60%左右的ƈ发查询性能Q预??日开发完成进入测试阶Dc?br/>
  4、精军队Q提高战斗力Q?/strong>

  军队多Q补l、后勤等开支也会越大,同样Q服务器多Q维护成本、托成本、复杂度也越高。所以,服务器不是越多越好,在能够保证容错性、避免单Ҏ障的情况下,如果能用一台高配置服务器来解决的事Q不要同两台低配|的服务器来qӀ?br/>
  传统的系l架构只不过围绕负蝲均衡讑֤或服务器、Web服务器集、数据库服务器集、搜索引擎服务器集群、分布式存储服务器集、缓存系l服务器集群{等Q技术含量ƈ不是特别高,只不q很多h没有生环境的机会去实践而已。随着内存h的下降,单台服务器扩充到64G内存的事情不再罕见;Intel会在下周面向高端服务器领域发布代号为Nehalem-EX?核XEON处理器。随着g性能的不断提高,我预,来的系l架构与服务器集将不再从服务类型上划分Q而将按“CPU密集型服务器集群”、“内存密集型服务器集”、“存储密集型服务器集”划分。我现在所设计的架构与开发的服务器端E序Q也逐渐向后者{UR?br/>
  最q,Google的工E师Luiz André Barroso and Urs Hölzle发表了一长?20늚论文Q提Z一个数据中心就是一台计机QThe Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines Q?br/>
............
]]>
http://www.lukangtou.cn/post/410/ <![CDATA[珠v金山软g之行[原创]]]> 张宴 <net@s135.com> Sun, 19 Apr 2009 15:56:59 +0000 http://www.lukangtou.cn/post/410/ http://blog.www.lukangtou.cn/post/410/]

  2009q??4日(星期二)

  下班后,和同事打的到首都国际机场Q乘21:10起飞的中国南方航ICZ3734航班飞往珠v。这也是我第一ơ坐飞机?br/>
  波音737I越着宁静的天I,云端望月的景象,|见而优。经q的三个时的飞行,掠过了大半个中国Q飞机降落在珠v三灶机场?br/>
  走出飞机Q打的前往吉大区的如家快捷酒店Q沿途v风扑面,湿气弥OQ与北京的干燥行成鲜明的Ҏ?br/>


  2009q??5日(星期三)

  上午10点,我们M珠v金山软g公司Q在“万p”会议室跟西山居工作室开了个会Q随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情~网l版3》研发团队,向他们请教了100多h协作开发的目理l验?br/>
  下午Q跟金山|游公司CTO的会议,是我主要兛_的议题,以下几项收获也不错:

  1、我所设计的“广州电信机ѝ天z网通机ѝ北京电信通多U机戎쀝三个核心IDC的系l架构得以通过Q只是做了点调_“广州电信机戎쀝换成了“珠L信机戎쀝,因ؓ金山享有珠v电信在带宽和U\上的Ҏ待遇?br/>
  点击在新H口中浏览此囄


  PSQ百度网|索前端服务器也分布在三个机房Q北京电信机ѝ北京网通机ѝ北京长城宽带多U机ѝ?br/>
  全国所有电信用戯?www.baidu.com 被解析C下两个VIPQ?br/>  220.181.6.19 Q北京市·电信Q?br/>  220.181.6.18 Q北京市·电信Q?br/>
  全国所有网通用戯?www.baidu.com 被解析C下两个VIPQ?br/>  202.108.22.5 Q北京市·|通)
  202.108.22.43 Q北京市·|通)

  全国铁通、教育网{其他访?www.baidu.com 被解析C下两个VIPQ?br/>  119.75.213.50 Q北京市·长城宽带Q?br/>  119.75.213.51 Q北京市·长城宽带Q?br/>


  2、获批了20台服务器。搭建我三个IDC的架构^収ͼg资源得以满Q剩下要解决的就是这20台服务器快C的问题了?br/>


  3、允怺来购买 Adobe 卛_推出?Flash Media Server 4.0 授权Q利?Flash Player 10 ?RTMFP协议Q支持P2PQ提?FLV/MP4(H264) 视频媒体点播服务?br/>
  目前逍遥|?a href="post/409/" target="_blank">Z开源Flash ServerQRed5构徏RTMP媒体播攑^?/a>》,采用的是 RTMP 协议Q生产环境(剑网3相关视频Q?a target="_blank">http://jx3.xoyo.com/xgxz/video/Q^均每个视频播放所消耗的带宽?5KB/U,100M独n带宽可以支撑500人同时在U观看。将来采?RTMFP 协议q行 Flash P2P 视频Ҏ服务Q将大大地节省带宽?br/>
  RTMFP ?Real‐Time Media Flow Protocol的羃写,是Adobe推出的一U新的通信协议Q这U通信协议可以?Flash 客户端直接和另外一个Flash 客户端之间进行数据通信Q也是常说的P2P的方式进行通信?br/>
  RTMFP 会大大地减音视频直播、点播、多人在U游戏等应用的网l带宽的消耗,减轻服务器的负担。因为很多数据都是客L之间直接传输了,无须再经q服务器中{了。RTMFP׃使用了UDP|络协议Q所以相对之前的TCP协议在数据传输效率上也会大大提高Q这U优势在韌频数据传输方面是非常明显的?br/>
  下面的示意图表现了RTMFP和RTMP的不同之处:

............
]]>
http://www.lukangtou.cn/post/407/ <![CDATA[Google 构徏大规模信息检索系l中的挑战]]> 张宴 <net@s135.com> Sat, 04 Apr 2009 16:07:09 +0000 http://www.lukangtou.cn/post/407/ Jeff Dean ?WSDM 2009 上的主题演讲Q?a target="_blank">Challenges in Building Large-Scale Information Retrieval Systems》。在q个主题演讲中,Jeff Dean 讲述?Google ?0q中QGoogle 索系l的演变和发展?br/>
  英文原文Q?a target="_blank">http://research.google.com/people/jeff/WSDM09-keynote.pdf
  演讲视频Q?a target="_blank">http://videolectures.net/wsdm09_dean_cblirs/

  中文译文Q由银杏泰克有限公司郝培强翻译)Q?br/>
............

Tags - ]]>
http://www.lukangtou.cn/chinaunix_nginx/ <![CDATA[使用NginxL实现开源负载均衡──9?0日在ChinaUnix技术沙龙上的演讲PPT[原创]]]> 张宴 <net@s135.com> Sun, 21 Sep 2008 05:21:36 +0000 http://www.lukangtou.cn/chinaunix_nginx/ http://blog.www.lukangtou.cn/post/369/]

  9?0日下午,我应邀参加?ChinaUnix 丑֊的以“如何搞定服务器负蝲均衡Q”ؓ主题的技术沙龙(http://linux.chinaunix.net/bbs/thread-1019366-1-1.htmlQ,很高兴能够跟诸多业界_英一h讨交,很荣q能够与Unix资深pȝ工程师──田逸、HonestQiaoQ以及F5资深技术工E师──杨明非,同台演讲?br/>
  点击在新H口中浏览此囄



  《用NginxL实现开源负载均衡》是我的演讲PPTQPowerPiontQ,现提供下载?br/>
  PPT分ؓ四个部分Q?/strong>
  1、介lNginx的基本特征,以及使用Nginx做负载均衡器的理由?br/>
  2、用实例Q来介绍Nginx负蝲均衡在大型网站的典型应用?br/>
  3、以实现|站动静分离为原型,对NetScalerg七层负蝲均衡和Nginx软g负蝲均衡做一个对比?br/>
............

Tags - , , , , , , , , , , , , , , ]]>
http://www.lukangtou.cn/post/348/ <![CDATA[利用NetScaler和自行编写的健康查脚本,完美解决多台MySQL Slave数据库的负蝲均衡[原创]]]> 张宴 <net@s135.com> Thu, 29 May 2008 15:21:04 +0000 http://www.lukangtou.cn/post/348/ http://blog.www.lukangtou.cn]

  Citrix NetScaler是一ƾ不错的4-7层硬件负载均衡交换机Q市场占有率仅次于F5 BIG-IPQ位居第二。NetScaler 8.0?a target="_blank">国思杰pȝ有限公司QCitrix Systems, IncQ正式推出的最新版本NetScaler产品pd?br/>
  从我的实际测试来看,NetScaler 8.0在七层负载均衡方面,性能和功能都要比F5 BIG-IP强?br/>
  NetScaler 8.0的负载均衡监控中Q可以对MySQL数据库进行健h查,而F5 BIG-IP目前只支持对Oracle和Microsoft SQL Server数据库的健康查?br/>
  点击在新H口中浏览此囄

  但是QNetScaler 8.0自带的MySQL健康查脚本(nsmysql.plQƈ不完善,它只能检查一条SQL语句执行是否出错Qƈ不能查MySQLMl构中的MySQL Slave数据库同步是否正常、表有无损坏、同步gq是否过大、是否出现错误、非sleeping状态的q程数是否过高等情况。于是,我根据自q需要,为NetScaler 8.0写了一个MySQL Slave数据库负载均衡健h查脚本(nsmysql-slave.plQ,实现了上q需求?br/>
  有了“nsmysql-slave.pl”做健康查,利用NetScaler的VIPQ虚拟IPQ,可以完实现多台MySQL Slave数据库的负蝲均衡了。当一台MySQL Slave数据库出C同步、表损坏、同步gq过大(本脚本中默认讄的落后MySQLd600U视为gq,可根据具体应用修改)、活动连E数太高Q本脚本中默认设|的是大?00视ؓq程数太高,可根据具体应用修改){情况,“nsmysql-slave.pl”就会自动将其检查出来,q告知NetScalerQNetScaler会将该数据库标识为宕机,从而不用L查询h传送到q台发生故障的数据库上。故障一旦修复,“nsmysql-slave.pl”会自动告知NetScalerQ该数据库已l可以用?br/>
  “nsmysql-slave.pl”源代码如下Q?br/>............

Tags - , , , , , ]]>
http://www.lukangtou.cn/f5_big_ip/ <![CDATA[F5 BIG-IP负蝲均衡器配|实例与Web理界面体验[原创]]]> 张宴 <net@s135.com> Thu, 22 May 2008 15:33:26 +0000 http://www.lukangtou.cn/f5_big_ip/ 2008.05.22 转蝲h明出自:http://blog.www.lukangtou.cn/f5_big_ip]

  前言Q最q一直在Ҏ试F5 BIG-IP和Citrix NetScaler负蝲均衡器的各项性能Q于是写下此文章,记录F5 BIG-IP的常见应用配|方法?br/>
  目前Q许多厂商推Z专用于^衡服务器负蝲的负载均衡器Q如F5 Network公司的BIG-IPQCitrix公司的NetScaler。F5 BIG-IP LTM 的官方名U叫做本地流量管理器Q可以做4-7层负载均衡,h负蝲均衡、应用交换、会话交换、状态监控、智能网l地址转换、通用持箋性、响应错误处理、IPv6|关、高U\由、智能端口镜像、SSL加速、智能HTTP压羃、TCP优化、第7层速率整Ş、内容缓册Ӏ内容{换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒l服?DoS)d和SYN Flood保护、防火墙—包qo、包消毒{功能?br/>
  以下是F5 BIG-IP用作HTTP负蝲均衡器的主要功能Q?/strong>
  ①、F5 BIG-IP提供12U灵zȝ法所有流量均衡的分配到各个服务器Q而面对用P只是一台虚拟服务器?br/>  ②、F5 BIG-IP可以认应用E序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障QF5会检查出来ƈ该服务器标识ؓ宕机Q从而不用L讉Kh传送到该台发生故障的服务器上。这P只要其它的服务器正常Q用L讉K׃会受到媄响。宕Z旦修复,F5 BIG-IP׃自动查证应用已能对客戯求作出正响应ƈ恢复向该服务器传送?br/>  ③、F5 BIG-IPh动态Session的会话保持功能?br/>  ④、F5 BIG-IP的iRules功能可以做HTTP内容qoQ根据不同的域名、URLQ将讉Kh传送到不同的服务器?br/>


  下面Q结合实例,配置F5 BIG-IP LTM v9.xQ?br/>
  点击在新H口中浏览此囄

  ①、如图,假设域名blog.www.lukangtou.cn被解析到F5的外|?公网虚拟IPQ?1.1.1.3Qvs_squidQ,该虚拟IP下有一个服务器池(pool_squidQ,该服务器池下包含两台真实的Squid服务器(192.168.1.11?92.168.1.12Q?br/>  ②、如果Squid~存未命中,则会hF5的内|虚拟IPQ?92.168.1.3Qvs_apacheQ,该虚拟IP下有一个默认服务器池(pool_apache_defaultQ,该服务器池下包含两台真实的Apache服务器(192.168.1.21?92.168.1.22Q,当该虚拟IP匚wiRules规则Ӟ则会讉K另外一个服务器池(pool_apache_irulesQ,该服务器池下同样包含两台真实的Apache服务器(192.168.1.23?92.168.1.24Q?br/>  ③、另外,所有真实服务器的默认网x向F5的自w内|IPQ即192.168.1.2?br/>  ④、所有的真实服务器通过SNAT IP地址61.1.1.4讉K互联|?br/>


  详细配置步骤Q?br/>
............

Tags - , , , , , , ]]>
http://www.lukangtou.cn/post/318/ <![CDATA[YouTube pȝ架构]]> 张宴 <net@s135.com> Thu, 27 Dec 2007 10:08:03 +0000 http://www.lukangtou.cn/post/318/   演讲地点Q西雅图扩展性的技术研讨会

此处包含一个多媒体文gQ请用网|式查看?br/>
  以下?Kyle Cordes Ҏ上述视频写下的文章:

  YouTube Scalability Talk

  Cuong Do of YouTube / Google recently gave a Google Tech Talk on scalability.

  I found it interesting in light of my own comments on YouTube’s 45 TB a while back.

  Here are my notes from his talk, a mix of what he said and my commentary:

  In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)

  YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)

............

Tags - , , , , , ]]>
߾ƷƵ