http://blog.s135.com/index.php zh-cn http://blog.s135.com/business_intelligence/ 张宴 <net@s135.com> Fri, 23 Jul 2010 10:12:10 +0000 http://blog.s135.com/business_intelligence/
　　文章以“KBI用户行为分析”的项目架构为原型，对Web商业智能平台的架构设计进行了概要介绍。实现海量数据的分析挖掘计算相对较易，如何以灵活的可扩展性框架，来便捷地应对项目开发周期中，来自众多项目干系人的需求变更，才是难点。

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

Tags - business , intelligence , bi , 商业智能 , 商务智能 , 数据仓库 , data , warehouse ]]> http://blog.s135.com/post/414/ 张宴 <net@s135.com> Thu, 28 May 2009 07:31:02 +0000 http://blog.s135.com/post/414/ http://blog.s135.com/post/414/]

　　“客户端访问”与“服务器端响应”，犹如一场战争。初期，访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的进攻。慢慢的，访问量大起来，这时候，就需要讲究排兵布阵、战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，我们开始了多线作战。慢慢地，我总结了以下一些思考：

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

　　两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”，如果已有的开源软件、框架、架构能够较好地用于自己的项目，并便于扩展，则优先使用开源软件；如果没有现成的东西，或者已有的开源软件性能不高、扩展性差、学习成本高，则可以取长补短，在项目中打造自己的“队伍”。


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

　　在多个项目同时进行时，不要认为自己能打赢每一场战斗，而每一场战斗都由自己亲自去打。确实，我相信很多人能够打赢一场场战斗，却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭，印证了这样一个事实：一群天才，却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲，自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统，最终自己被自己给拖垮了。

　　不要让战线拉得太广，适当利用“雇佣军”，项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务，时间、费用、维护成本可能要更低。最近，我工作中的两项服务使用了“雇佣军”：(1)、购买ChinaCache CDN的Flash Media Server点播加速服务，支撑金山游戏视频宣传站点，节省了部署多节点的成本和时间；(2)、购买快网的智能DNS解析服务，来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务，节省了收集、整理，将来更新维护IP信息等工作。


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

　　现代战争的特点都拥一个有共同的前提那就是：都不可能离开“高技术兵器”。同样，要想承担高并发访问，而又希望系统架构简单一点、程序开发快捷一点，那么，则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页，内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存，高并发访问下需要实时更新的列表页缓存，目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下，实时更新的列表页，成为最主要的瓶颈。我目前正在基于一些开源类库，开发的一款简单关系型数据库，将实现MySQL单表拥有的大部分复杂条件查询功能，并将达到单表千万级以上记录下，Memcached 60%左右的并发查询性能，预计6月6日开发完成进入测试阶段。

　　4、精简军队，提高战斗力：

　　军队越多，补给、后勤等开支也会越大，同样，服务器越多，维护成本、托管成本、复杂度也越高。所以，服务器不是越多越好，在能够保证容错性、避免单点故障的情况下，如果能用一台高配置服务器来解决的事，不要同两台低配置的服务器来干。

　　传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等，技术含量并不是特别高，只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降，单台服务器扩充到64G内存的事情不再罕见；Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高，我预测，将来的系统架构与服务器集群将不再从服务类型上划分，而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序，也逐渐向后者转移。

　　最近，Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文，提出了一个数据中心就是一台计算机（The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines ）

............
]]> http://blog.s135.com/post/410/ 张宴 <net@s135.com> Sun, 19 Apr 2009 15:56:59 +0000 http://blog.s135.com/post/410/ http://blog.s135.com/post/410/]

　　2009年4月14日（星期二）

　　下班后，和同事打的到首都国际机场，乘21:10起飞的中国南方航空CZ3734航班飞往珠海。这也是我第一次坐飞机。

　　波音737穿越着宁静的天空，云端望月的景象，罕见而优美。经过的三个小时的飞行，掠过了大半个中国，飞机降落在珠海三灶机场。

　　走出飞机，打的前往吉大区的如家快捷酒店，沿途海风扑面，湿气弥漫，与北京的干燥行成鲜明的对比。

---

　　2009年4月15日（星期三）

　　上午10点，我们去了珠海金山软件公司，在“万花谷”会议室跟西山居工作室开了个小会，随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情缘网络版3》研发团队，向他们请教了100多人协作开发的项目管理经验。

　　下午，跟金山网游公司CTO的会议，是我主要关心的议题，以下几项收获也不错：

　　1、我所设计的“广州电信机房、天津网通机房、北京电信通多线机房”三个核心IDC的系统架构得以通过，只是做了点小调整，将“广州电信机房”换成了“珠海电信机房”，因为金山享有珠海电信在带宽和线路上的特殊待遇。

　　


　　PS：百度网页搜索前端服务器也分布在三个机房：北京电信机房、北京网通机房、北京长城宽带多线机房。

　　全国所有电信用户访问 www.baidu.com 将被解析到以下两个VIP：
　　220.181.6.19 （北京市·电信）
　　220.181.6.18 （北京市·电信）

　　全国所有网通用户访问 www.baidu.com 将被解析到以下两个VIP：
　　202.108.22.5 （北京市·网通）
　　202.108.22.43 （北京市·网通）

　　全国铁通、教育网等其他访问 www.baidu.com 将被解析到以下两个VIP：
　　119.75.213.50 （北京市·长城宽带）
　　119.75.213.51 （北京市·长城宽带）

---

　　2、获批了20台服务器。搭建我三个IDC的架构平台，硬件资源得以满足，剩下要解决的就是这20台服务器尽快到位的问题了。

---

　　3、允许了将来购买 Adobe 即将推出的 Flash Media Server 4.0 授权，利用 Flash Player 10 和 RTMFP协议（支持P2P）提供 FLV/MP4(H264) 视频流媒体点播服务。

　　目前逍遥网《基于开源Flash Server：Red5构建RTMP流媒体播放平台》，采用的是 RTMP 协议，生产环境（剑网3相关视频：http://jx3.xoyo.com/xgxz/video/）平均每个视频播放所消耗的带宽是25KB/秒，100M独享带宽可以支撑500人同时在线观看。将来采用 RTMFP 协议进行 Flash P2P 视频点播服务，将大大地节省带宽。

　　RTMFP 是 Real‐Time Media Flow Protocol的缩写，是Adobe推出的一种新的通信协议，这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信，也就是常说的P2P的方式进行通信。

　　RTMFP 将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗，减轻服务器的负担。因为很多数据都是客户端之间直接传输了，无须再经过服务器中转了。RTMFP由于使用了UDP网络协议，所以相对之前的TCP协议在数据传输效率上也会大大提高，这种优势在音视频数据传输方面是非常明显的。

　　下面的示意图表现了RTMFP和RTMP的不同之处：

............
]]> http://blog.s135.com/post/407/ 张宴 <net@s135.com> Sat, 04 Apr 2009 16:07:09 +0000 http://blog.s135.com/post/407/ Jeff Dean 在 WSDM 2009 上的主题演讲：《Challenges in Building Large-Scale Information Retrieval Systems》。在这个主题演讲中，Jeff Dean 讲述了 Google 在10年中，Google 检索系统的演变和发展。

　　英文原文：http://research.google.com/people/jeff/WSDM09-keynote.pdf
　　演讲视频：http://videolectures.net/wsdm09_dean_cblirs/

　　中文译文（由银杏泰克有限公司郝培强翻译）：

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

Tags - google ]]> http://blog.s135.com/chinaunix_nginx/ 张宴 <net@s135.com> Sun, 21 Sep 2008 05:21:36 +0000 http://blog.s135.com/chinaunix_nginx/ http://blog.s135.com/post/369/]

　　9月20日下午，我应邀参加了 ChinaUnix 举办的以“如何搞定服务器负载均衡？”为主题的技术沙龙（http://linux.chinaunix.net/bbs/thread-1019366-1-1.html），很高兴能够跟诸多业界精英一起探讨交流，很荣幸能够与Unix资深系统工程师──田逸、HonestQiao，以及F5资深技术工程师──杨明非，同台演讲。

　　

---

　　《使用Nginx轻松实现开源负载均衡》是我的演讲PPT（PowerPiont），现提供下载。

　　PPT分为四个部分：
　　1、介绍Nginx的基本特征，以及使用Nginx做负载均衡器的理由。

　　2、用实例，来介绍Nginx负载均衡在大型网站的典型应用。

　　3、以实现网站动静分离为原型，对NetScaler硬件七层负载均衡和Nginx软件负载均衡做一个对比。

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

Tags - linux , nginx , cache , squid , apache , memcached , tcp , centos , 负载均衡 , epoll , memcache , citrix , netscaler , f5 , big-ip ]]> http://blog.s135.com/post/348/ 张宴 <net@s135.com> Thu, 29 May 2008 15:21:04 +0000 http://blog.s135.com/post/348/ http://blog.s135.com]

　　Citrix NetScaler是一款不错的4-7层硬件负载均衡交换机，市场占有率仅次于F5 BIG-IP，位居第二。NetScaler 8.0是美国思杰系统有限公司（Citrix Systems, Inc）正式推出的最新版本NetScaler产品系列。

　　从我的实际测试来看，NetScaler 8.0在七层负载均衡方面，性能和功能都要比F5 BIG-IP强。

　　NetScaler 8.0的负载均衡监控中，可以对MySQL数据库进行健康检查，而F5 BIG-IP目前只支持对Oracle和Microsoft SQL Server数据库的健康检查。

　　

　　但是，NetScaler 8.0自带的MySQL健康检查脚本（nsmysql.pl）并不完善，它只能检查一条SQL语句执行是否出错，并不能检查MySQL主从结构中的MySQL Slave数据库同步是否正常、表有无损坏、同步延迟是否过大、是否出现错误、非sleeping状态的连程数是否过高等情况。于是，我根据自己的需要，为NetScaler 8.0写了一个MySQL Slave数据库负载均衡健康检查脚本（nsmysql-slave.pl），实现了上述需求。

　　有了“nsmysql-slave.pl”做健康检查，利用NetScaler的VIP（虚拟IP），就可以完美实现多台MySQL Slave数据库的负载均衡了。当一台MySQL Slave数据库出现不同步、表损坏、同步延迟过大（本脚本中默认设置的落后MySQL主库600秒视为延迟，可根据具体应用修改）、活动连程数太高（本脚本中默认设置的是大于200视为连程数太高，可根据具体应用修改）等情况，“nsmysql-slave.pl”就会自动将其检查出来，并告知NetScaler，NetScaler会将该数据库标识为宕机，从而不将用户的查询请求传送到这台发生故障的数据库上。故障一旦修复，“nsmysql-slave.pl”会自动告知NetScaler，该数据库已经可以使用。

　　“nsmysql-slave.pl”源代码如下：
............

Tags - linux , mysql , citrix , netscaler , f5 , big-ip ]]> http://blog.s135.com/f5_big_ip/ 张宴 <net@s135.com> Thu, 22 May 2008 15:33:26 +0000 http://blog.s135.com/f5_big_ip/ 2008.05.22 转载请注明出自：http://blog.s135.com/f5_big_ip]

　　前言：最近一直在对比测试F5 BIG-IP和Citrix NetScaler负载均衡器的各项性能，于是写下此篇文章，记录F5 BIG-IP的常见应用配置方法。

　　目前，许多厂商推出了专用于平衡服务器负载的负载均衡器，如F5 Network公司的BIG-IP，Citrix公司的NetScaler。F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。

　　以下是F5 BIG-IP用作HTTP负载均衡器的主要功能：
　　①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
　　②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
　　③、F5 BIG-IP具有动态Session的会话保持功能。
　　④、F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。

---

　　下面，结合实例，配置F5 BIG-IP LTM v9.x：

　　

　　①、如图，假设域名blog.s135.com被解析到F5的外网/公网虚拟IP：61.1.1.3（vs_squid），该虚拟IP下有一个服务器池（pool_squid），该服务器池下包含两台真实的Squid服务器（192.168.1.11和192.168.1.12）。
　　②、如果Squid缓存未命中，则会请求F5的内网虚拟IP：192.168.1.3（vs_apache），该虚拟IP下有一个默认服务器池（pool_apache_default），该服务器池下包含两台真实的Apache服务器（192.168.1.21和192.168.1.22），当该虚拟IP匹配iRules规则时，则会访问另外一个服务器池（pool_apache_irules），该服务器池下同样包含两台真实的Apache服务器（192.168.1.23和192.168.1.24）。
　　③、另外，所有真实服务器的默认网关指向F5的自身内网IP，即192.168.1.2。
　　④、所有的真实服务器通过SNAT IP地址61.1.1.4访问互联网。

---

　　详细配置步骤：

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

Tags - f5 , big-ip , linux , squid , cache , apache , tcp ]]> http://blog.s135.com/post/318/ 张宴 <net@s135.com> Thu, 27 Dec 2007 10:08:03 +0000 http://blog.s135.com/post/318/ 　　演讲地点：西雅图扩展性的技术研讨会

此处包含一个多媒体文件，请用网页方式查看。

　　以下为 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 - youtube , linux , mysql , cache , google , memcached ]]>