主持人：张旭，新浪网网络系统部 运维开发经理
13：00-13：40
签到（领取调查表、礼品）
13：45-14：20
演讲主题：曹刚:门户网站系统运维架构规划设计实战
14：35-15：10
演讲主题：吴炳锡:LVS、Nginx负载分衡构建实战，以及应用性能对比
15：30-16：10
演讲主题：Radware梁世鹏：负载均衡解决方案：应对网络流量峰值瓶颈
16：20-16：55
演讲主题：SOHO叶金荣：My SQL与网络应用相关的数据库优化
17：10-17：45
演讲主题：田逸:网络多数据中心站点CDN网络构建实例精讲
17：55-18:20
根据调查表，抽奖
大家下午好，非常感谢各位参与今天的网络优化论坛。
我是唐川，这位是来自新浪运维中心的张旭，他是今天的会议主持人。
今天，有来自各大网站、以及传统企业的运维工程师，例如有的来自新浪、SOHU、TOM、BAIDU、YAHOO，有的来自搜房网、凤凰网，有的来自中国网通、中国移动、中国联通，有的来自东海证券、银河证券等等。不少企业甚至结队过来参与交流，在此深表感谢。
现在，我简要介绍一下今天的流程：
首先，我们安排了五次主题演讲，
而每次主题演讲之后，会有一定时间进行互动。在这个时段，大家可以提问，或者提出自己的观点/看法，或者实践的经验。进行互动者，我们有精彩礼品相送，礼品是Linux方面书籍等。
接下来，我们有请张旭先介绍一下今天的演讲主题。
…….
问1：我们在维护的时候不考虑利用系统的情况，怎样对服务器或者是其他的网络设备进行提前的报警监控这一类的。
曹刚：监控和监管是吧，监控和监管现在有很多工具，比如说（来构思）之类的，我们在需要监管的服务器上面做一个小的客户端，然后由机器来进行报警和监管就可以了。
问：那如果不是在一条线路上，比如说我们需要共同的网络线路跨过很多机房的话，他们有没有一种类似于分布式的管理能统一监管所有的机器？
曹刚：这个和分布没有关系，直接把数据采集上来，有一个统一中心的，只要是路由是通的能够访问到，你就可以监控得到。
问：好，谢谢。
问2：你好，我想问一下社区的缓存有什么技术，用哪一种比较好一点？
曹刚：我解释一下，我们可以看到这么一个图，这个图其实是整个社区的数据结构图，当用户来读的时候他必须知道这个图结点，然后往下把整个数据读出来，然后给用户。
问2：我前面如果加（死亏特）之类的呢？
曹刚：（死亏特）只是来做内容的缓存，比如说我一个帖子的内容放在它里面的，它只是负责列表，根据列表里面相应的IP号然后从里面读取内容，整个页面是拼接的。
问3：我想问一下您刚才提到系统架构当中有一步很重要的就是服务器选型，我现在主要想问的问题就是关于服务器选型的问题，就是说比如说我目标是一个1千万PV这么一个压力的（歪脖）页面，或者是根据有这么一个PV数据库，我如果选型的话怎么来选，因为之前工作中遇到过这种问题，但是没有通过数据来说明我选这款服务器是正好够的。
曹刚：这块我请叶金荣一起来跟我做解答，我先解答一下，这个和你业务相关，有些业务比如说我们看到的社区业务，它频繁排序，这是一个问题，然后这样的话我们在做设计的时候，我们应该把数据频繁变化这样一个东西弄出来，不要让它影响到静态的制版，这样的话我们在设计数据库的时候我们也好扩展，然后至于数据库的选型，当然是CPU频率越高，内存越大，然后磁盘越多，因为它有很多排序，它会涉及到外排序，然后它会大量的CIO，然后他来跟你说一下他的业务。
问3：我也知道肯定是CPU越高越好，但是毕竟有成本在这里头，所以说怎么样能够判断我能够采购一台成本不算太高，但是在我预想的时间段又够的服务器。
曹刚：这个问题一般我们不考虑。因为是这样的，我们最主要是考虑这个业务发展，在未来的一段时间之内会承受的压力，因为我们不可能说天天来做数据迁移，当这个访问量上来的时候，我再做数据迁移，对于我来说有人力的成本，机器的成本肯定没有人力成本这么高，你做一次人力迁移要花费工程师可能半个月的工作，对于机器来说我可能预知一年的工作量放进去，对于我的维护来说工作量也很大，当原来有一个工程师跟我说过，你们的数据库应该把它做两块系统盘，其他的做一块盘做（瑞德木）这样的话我们维护的话非常方便。
主持人：那行，由于时间关系，咱们下一个演讲，如果还有什么问题，可以下来的话找曹刚单独交流一下，谢谢曹刚，然后下面一个演讲主角是由吴炳西来给大家做一个RVS一个负载实现，然后吴炳西现在应该是在战斗，同时他现在还是（YCW）专家组里面的一个成员，现在咱们由吴炳西给大家做一个RVS负载均衡实现的主题演讲。
吴炳西：大家好，咱们接触负载均衡器很长时间了，不管是硬件软件的，大家见到很多，今天咱们来到华山论剑，比一比谁最强，然后咱们在工作中可以更好的选型，这也是咱们中国的习性，最要比比武，然后选择最好的，咱们去看一下。今天主要内容是RVS负载均衡结构、（看呢得）的负载均衡结构，RVS、（看呢得）的对比，以及负载均衡器选型，就是在我们工作中结合我们的业务去选一个负载均衡器，适合我们用的，现在在Veb2.0中在高并发的环境中，RVS（看呢得）的角色，咱们今天讲的主要内容主要是针对外部这一块，对数据库的负载均衡器或者别的游戏之类的负载均衡我们今天先不涉及，今天主要是外部这一部分。
关于构建方法今天不想去讲，那个东西很虚的，大家一看都会知道，然后我随后会放（买C口）mag.Com上面，大家可以去看一下相关的配置，包括RVS基本实现，对RVS的启动以及HV的实现，我们都可以在上面去讨论，然后大家可以随后在上面注册一下看看，我们讨论一下方法。
RVS的负载均衡结构其实它是比较简单的，也可以说是主要基于IP层的负载均衡，性能是比较高效的，在网络服务器当中它有一个大的缺点，需要局域网内的，大部分情况是包括DR模式、K模式都需要在一个局域网内，所以局限性很高，包括DR模式需要全部有公网模式，这样的话它才能工作，对于传统的负载均衡器都是不同的，RVS工作流程主要分为什么样呢，核心部分去分的一个客户端的访问，访问到RVS然后检测、然后负载均衡器的算法，然后根据IPOS进行包处理，转发到后端支持服务器，然后后端服务器响应了之后，要是net模式它会把包转给RVS调度点，调度点要进行包的再次处理，人民返还给客户，如果是DR这块，直接把包进行处理一下，然后发给客户，这样完成一次请求。这样的话可以进行一次比较，RVS、net、DR模式包处理的什么样的。
首先看一下net模式，服务器客户端是任意的，然后网络是私网，就一个公网IP，服务器数量有一个要求，在小于10到20，如果超过20服务器这个结点，net受到对包的处理就要进行伪装，比如负载会非常高，然后处理过程会丢包这种现象，所以我们抱怨丢包不知道怎么处理了，这是我们自己服务器架构模式出现了问题，所以在结点负载在5以上或者3以上的时候，你就需要考虑一下你的并发连接处是多少，我采用了什么调度模式，然后包的交换次数进行了4次，就是说当客户端访问我的时间，我要把包首先转发给客户端的服务器，要进行处理之后要转发给net结点，然后net结点进行再次伪装，然后发给客户，是4次的过程，然后网关是负载均衡器，真正的（塞我）需要走网关这块出去。
tn模式也是服务要求支持协议的，（死赖斯）也可以，然后网络是（兰德、V兰德）都可以，主要是IP是一样的，服务器数目是100台左右都可以，再大的话我们就建议把网络进行分组，不可能说一个负载均衡器我带了一两百台，这样的话你的业务会很麻烦，建议最大的业务分到八九十台、五六十台，我觉得很庞大了，然后包的交换次数是1次，包直接转发给客户端，客户端直接转发给前端了，然后是网关，网段出去之后都是公网IP，都是一个网关就可以。
DR模式要进行ARP伪装的，没要求IP是一个网段的，有段时间好多朋友说我的LVS架不起来工作，就是因为你的RVS结点和实际的（塞我）结点IP不是一网段的，服务器数量也在100左右都可以，再大的话可以进行分组，然后再用一个虚拟IP带动一个就可以了。网关也就是我们真实使用的网关就可以了。
在生产环境中我们看一下它的一些基础架构，在net模式我们看到第一个图，前面是一个交换机，然后LS的（吗四德），然后LS的（四类U），中间再一个交换机接后面的Veb，再后面就是我们所谓的数据库了，或者是存储之类的，这都是我们后端的再去划分。
然后接下来DR模式，就是我们经常看到的大家都在一个交换机上，在一个层上，然后分类为一个（吗四德）结点和（四类U）做了一个HV的高可用性，然后后面接（塞我），再后面怎么分就是我们一会由叶金荣给大家讲的数据库那部分。
RVS各种结构和性能分析，我本来想拿一个数据给大家演示一下性能多么强，但是我做实验的过程中我发现，随便一做100照带宽或者1000照带宽很容易冲满，但是结点根本没问题，后面我用程序测的是（塞深），它支持500万，500万以上我们没法测了，在市场中我们要买一个支持30万左右的交换机的话，价格在15万左右，你可以想象一下RVS在支持500万，这个级别是什么样的，你后面可以带多少分组都可以的，RVS本身是基于IP层的负载均衡器，可以说是最高效的这种方式，因为包处理是最小的，但基于net这种模式，为什么说它会触到性能瓶颈呢，一是需要处理包的次数过多，二是一个公网IP，不管哪个包出去都要从一个网卡出去，一个网卡能处理包的流量，大家可以想像在一个1000照的网卡，能处理的流量大概是300多照，已经达到顶峰了，再高的话可能会出现网络现象，所以说这个东西受到一个瓶颈，当你采用DR或者tn这种模式，我们处理的流量是能够翻倍的，如果在千照的环境，你处理一个七八G或者十几G的流量这是没问题的。
目前来说对我们经常用的都是推荐大家用DR的模式，但是网上经常见到的配置教程好多说是DR的，但是你看一下配置网页其实是net的，包括KP、LV的DR模式这种配置都是很少的，大家可以随后到我们的网站看一下，这样我发一个怎么实现DR模式。
接下来咱们讲一下（嫩定），（嫩定）可以说是一个后起之秀，大家也去关注它也就是08年，它为什么所谓高效让大家认识它，首先它简单，配置文件相当的简单，另一方面它的性能确实很高效，而且我们利用它的负载均衡主要是（阿姆丝锥木）这个模块，这个模块有兴趣的话可以去看看它的算法，对你的提高都是非常不错的，因为（嫩定）这块中文方面的资料很少，这方面最强的应该是张燕张大师的，大家可以参考一下，也是对（嫩定）非常推崇的一个人，另外（嫩定）为什么还受到人们的欢迎，它属于一个七层交换，对于应用层的协议我们可以指定一些VRL去到固定的服务器上。（嫩定）本身又是一个HDDB的服务，的性能比（阿帕奇）高一点，在处理一些AP会强很多倍，你可以回去体验体验，如果有这方面的管理论坛，你可以去感受一下。
我们接下来看一下（嫩定）的负载均衡结构，（嫩定）首先是一个公网的交换机，然后另外是一个负载均衡，也就是说做一个HA的模式，这个主要是IP接管，你可以想个办法这么做，然后我们可以回忆上面，它的作用和RVS的net很相似，那么它的传统性能出现的什么问题呢，它和net同样面临一个问题，对包的处理次数多一点，另外流量单机限制的比较多，性能方面是单网卡处理，那么这种情况我们适合做什么呢，如果我说我们的流量只有100照，或者是千照以内，那么我们一台机器可以处理完了，这种情况不用选择使用（嫩定）这种负载均衡模式，因为确实简单，你不再需要后端健康检查了，它本身带有健康检测，另外我的流量很大，超过千照，然后用（嫩定）做负载均衡行不行，已经不行了，大家经常会看到，我的流量有空闲，但是我负载均衡的流量已经很高，但是有的用户该反映我的网速很慢，这样你应该考虑一下我的负载均衡结点对流量是否全部接受，对流量的控制这块去考虑一下，这块我们经常也会谈，很多朋友问我，你的负载均衡结构能不能扛住10万IP呢，或者怎么样的，我觉得这个问题没有意义，因为有没有那么大的带宽，你访问什么东西，如果你访问很大的图片，你算一下网关的流量你能不能经得起呢，所以对于负载均衡我采用什么样的架构，根据你的业务算一下，但是（嫩定）确实是很好的东西，在测试后我发现RVS和（嫩定）都是比较优秀的软件。
（嫩定）的性能分析也就是刚才我们说过的比较简单，对后端有健康检查能力，在机器少的情况下，负载均衡表现能力很好，如果多的话表现就不太好，主要原因是流量堵住了，就一个出口容易引起流量拥挤，有带宽但是还是访问失败这种现象会出现。
RVS和（嫩定）的对比，这个本来想拿数据给大家演示一下，可以负责任的说可以放心的去用，任何一个都是有惊人的效果，对于RVS主要是基于IP层的负载均衡，特别是DR和tn的模式，对后端直接进行转接后直接对外服务，性能提升的非常明显，负载均衡占用的资源很少，它主要是耗费CPU去进行包的转发，（嫩定）主要是基于应用方面的负载均衡器，本身带有健康检查，它性能和RVS和net模式差不多，但是功能比它们多多了。
负载均衡的选型，我们公司让我们去选一个，或者我们的业务发展一台机器已经适应不了了，让我们去扩展一下多台机器怎么工作，这种情况下用什么负载均衡器不重要，重要的是谁在维护负载均衡器，你负载均衡器了解多少，如果我比较懒的话，那么我就支持我的单位买一台硬件服务器，那么我就可以睡觉了，有什么事可以找硬件厂商，打个电话进行服务器的支持，如果对RVS和（嫩定）都非常了解，那么你选任何一个都可以，因为任何一个都可以达到你的要求，但是如果你的流量都上G的话，你都要考虑一下怎么组合，就是把服务分再分，不要把一堆一块服务，那么你的管理会受到影响，如果把服务分到很细的话，那么你的服务控制在1G以下的流量怎么都没事，而且在特别大的情况下，如果包都堆到一块，对日志和磁盘都是很大的影响。
所以说我给大家推荐一个流量特别大的负载均衡结构什么样的，就是RVS然后到（嫩定）然后再到KD，这样有一个什么好处呢，RVS实现一个四层转发，然后把包转为（嫩定），（嫩定）进行后端进行负载，这个过程已经出现了一个没有单点，就是前端只用对（嫩定）进行健康检测，后端随便加也可以，因为不用进行设置了。
然后我们对比一下Veb1.0和Veb2.0解决方案中碰到的困难，这个是我们做Veb2.0SNS已经很长时间，然后跟别的网站进行了交流，我们共同遇到了一些问题，跟大家分享一下，Veb1.0主要是数据量小，单台的（死亏的）可以卡到很高的命中率，Veb1.0交付性很小，大部分是展现给客户看的，我们的用户以（C貌似）为主，这种情况对后端要求不是太高，然后请求量大，主要是RVS加（死亏的）和DNS进行轮巡，这种模式进行解决方案，然后（死亏的）压力很大，用超大内存做（开区），一般在特别高的要求情况下，我们会用内存磁盘做，这种情况你可以和（W内饰）比一下，还是超过（W内饰）的，如果懒的话可以直接用（W内饰）做（开区），要想费点工夫提高点性能还是建议用磁盘去代替硬盘做。
Veb2.0有什么变化呢，主要是数据变化频繁，数据总量大，数据量很大之后我们的（死亏特）要进行数据文件记载，然后命中率会下降，然后（哈需）会在内存中更新，如果量很大的话会慢下来，第二点请求量大，种类繁多，在Veb2.0上，一天一两百G的数据很正常，所以这么大的数据怎么办呢，包括备份这方面都需要动脑筋，不像传统的每天做一个增量备份，增量备份特别麻烦，所以这个东西大家都可以去想一想，（死亏特）更新现象比较严重，然后后面文件的更新变化比较大，前面的请求不断的刷，然后更新量比较严重，（开区）LO更新严重，导致效率下降，然后发现有的时间（死亏特）请求明显下降，然后再看机器负载明显LO更新比较严重了。
然后基于（哈需）的这种（开区）解决方案什么样的，比方说我是1981年这样的一个用户，我可以把你的生日月份加起来给你做（哈需），然后给你做到不同的机器上去访问，但是在机器死掉之后，这个年份的人访问都不行了，然后压力过大导致（开区）命中率很低，这个问题怎么解决呢，然后我们可以考虑一下能不能基于应用层的，一个用户过来之后，我让他到指定的服务器，然后更新，比方说我现在有200G的内容，随后用户来访问的过程中，我分了10个（死亏特），一个（死亏特）我发20G的内容，那20G的话基本上差不多能把内容全部缓存下来，这样的话如果这10个（死亏特）平均的话，那么我们用户20G的空间要进行不断的交换，这样的话引起了（开区）非常严重，如果第一个（死亏特）我放VID为多少多少的，我去放这部分内容，第二个（死亏特）我放一部分内容，然后第一部分内容就是针对这部分用户进行服务，这样的话我的（死亏特）更新会减少了，所以很好的解决方案是这样的，但是这个东西出现了什么情况，就是一台机器死掉之后，会造成用户无法访问。那这种情况我们可以把（嫩定）拿出来，（嫩定）可以进行VRL定位到不同的服务器上。
然后我们看一下这个图，这个图是51.com上的图，大家能看清这个图吗，如果看不清的话，我可以下载TBT让大家理解一下，对于负载均衡器这块是不错的，首先看一下（科林的）到LVS做了一个HA，HA之后把包转发给（嫩定），（嫩定）转发给（死亏特），然后转发给（塞我），然后实现了这样一个服务过程，这样一个服务过程有什么好处呢，首先RVS这层大家平时在做的过程中，有一个误区，一个RVS只能做一个虚拟IP，就是说我要分组的话，我又要浪费两台机器，这样的话对概念没理解好，一个RVS可以支持500万，你根本用不完，如果我再做一个VIP都是可以的，每个VIP针对不同的（塞我）都可以，然后后面（嫩定）做了一个中间层，所谓我们的七层交换，把这个层实现出来。这样还有一个好处，如果全用RVS我们需要都有公网IP才能实现DR和tn的模式，这样的话对资源的浪费很严重，如果我们换成（嫩定）模式，对（死亏特）完全可以使用内网IP。
另外是在RVS的情况下，我们在后端的机器需要绑定一个VIP然后做一个加工，这样的话我们在上机的过程中工作量会非常大，如果说我们在前端用RVS，中间加了（嫩定），（嫩定）如果就14G到20G之间的流量的话，20台就可以了，然后后面可以用不同的（死亏特），这样工作量减少了，维护也简单了，这样维护的过程中需要有一个VP能够连进来，看一下（塞我）是否正常，推荐大家别对应用层的检测，就是说我在应用是否正常的情况下，你要做一个报警预知，给大家讲讲怎么做。
（嫩定）实现负载均衡的代码可以看一下主要是分组的概念，每个组（嫩定）往后面转，一个组最好不要用一个结点，用两个到两个以上控制在十个以内，这样慢慢去定义，针对我们刚才URL这种情况我们看一下，假设说我们一个组是两个成员，然后（嫩定）还有一个情况，就是说在基于端口的负载均衡，如果用RVS是基于端口的负载均衡，只能对后面服务，你必须跑到80，不是80的话没办法，但是用（嫩定）不管是81或者是82都没问题。首先看一下（嫩定）的分组，格式很简单，在生产中你要根据实际生产的业务起一个名字，便于你后来的归纳和总结，然后我们看一下基于UD怎么去负载的，看到一个（OK深），这个在里面我们可以进行正在表达，然后匹配0到F，如果大家学过都能看出来是怎么回事，存储之外0到1，0到F这种模式去存的，就是说存储外分了两位组成，0或者1，0或F，包括这两个字符的，我让它通过（铺绕死怕死）到（阴霾的1）上去找这些内容，当UD中包含2到3，后面0到F，然后去哪找内容呢，我们到（阴霾的2）中去找内容，这样不管多少个（每定）配置文件是一样的，确实很长，慢慢的去想，不要着急。
这种结构的优点是什么呢，实现了高可用性，最大程度的防止了单点，后端的单点健康检查是由（嫩定）完成的，当（嫩定）发现（塞我）不工作的时候，直接会把包发送给（塞我），但是这个过程是很慢的，因为（嫩定）也需要去检查后端，所以当一个机器死掉，最好有一个完善的报警机制把这个报警发给你，尽快的完善修复。
对（嫩定）的健康检查可以用前端的KPLVD，很多软件都可以去进行健康检查，但是最好去弄懂这个健康检查包括HA的切换原理，在没有弄懂原理的情况下建议你不要上，免得一旦出现的问题，你措手不及，所以说你要先弄懂再上，不要因为功能实现了就上。这样还可以保证VRL的（哈需）算法，避免找开发改程序，这样的话在我们系统应用层做完了，这样的话加快了我们的服务，也提高了我们的服务质量，扩展性也比较好，然后层次明确性也比较好。
今天我主要是讲了一个思想的部分，也算是结束了，重要的配置过程如果大家需要了解的话，可以去我们的网站看一下，我们可以交流一下这些东西，对于思想交流这么多，然后大家有什么问题交流一下。
主持人：感谢吴炳西的演讲，现在大家有什么问题可以跟他互动一下。
问1：你好，我想问一下（嫩定）负载均衡器的话对后台的（塞我）健康检查有几种模式？
吴炳西：没有固定的模式，是它本身的功能。
问1：它本身有几种功能？
吴炳西：它本身带有健康检查，不用管，而且不支持接口配置。
问2：你好，我想问两个问题，第一个针对交换机Veb2.0的应用，我们怎么去做保持的，再一个Veb2.0如果数据放弃的话，我们如何备份？
吴炳西：第一个问题保持的话，一般可以有两种模式，一种是（脉搏快吃）分组，但是为了高可用性，可以进行分组，另一方面是对文件的备份，我们一般会在写的过程中一个备份，有的时候会一次写两份，在低层实现也可以，在程序写的过程中也可以。
问2：您的意思就是同时写两份？
吴炳西：对，而且更常见的是Veb2.0这种网站上传是单走一个（塞我）应用的，不会和主体对外走一块的。
问3：你好，我想请问一下目前还有一种均衡负载模式是就是（阿帕奇）的模式，这种模式的好处就是能够很好的处理静态页面，如果用这种模式的话有什么需要特别注意的吗？
吴炳西：你说的是（阿帕奇）本身的（铺绕C）模式，这个其实相当于和（嫩定）的负载均衡是一样的，只能在全单去加一个LVS就可以了，不用考虑那么多。
问4：你好我想问一下什么情况下能够用到负载均衡，有没有什么样的流量的标准？
吴炳西：这个东西你什么时间采用什么，当然是一台机器扛不住的时候，另外我的业务需要保证，就是说我一台机器无法保证我的业务24小时在线，分两种情况。
主持人：大家在提问一下先报一下自己的单位。
问5：我的问题比较多，两个，我是来自首席世家的，第一个是（铺绕C），我觉得它的功能和（嫩定）差不多的，那它们两个对比什么样的？
吴炳西：我更偏向（嫩定），因为（铺绕C）对虚拟主机的支持不好，因为你需要去打官方支持才能支持主机。
问5：如何计算个集成之间各种的利用关系，有没有相应的软件可以监控？假如我从RVS到后面的VDI再到后面的Veb，各自之间的利用率。
吴炳西：这个东西很流量相关，也要考虑你机器的负载，你要对机器的运行状况做一个系统监控，不能说我丢了之后运行什么样，去看一眼，你要做一个数据的采集做一个对比。另外你问的在三层之后会不会慢，你可以用IBTDB做一个头进行抓包，然后看一下你访问的时间，和你单机的访问间做一个对比就知道了。
问5：我看到原来有一个图，有各层利用关系的，不知道怎么出来的。
吴炳西：哪一个关系，随后咱们再交流。
主持人：给前面的朋友点提问的机会。
问6：你好，我是湖南卫视的，我有一个问题，（44：35）。
吴炳西：你说是多个结点，这个东西可以分为不同的VIP，就是说每个VIP相对一个域，不要把一个VIP对应不同的域。
问6：是不是前面基于多地点做的呢。
吴炳西：这个实现不了，因为要说到个地点的话，那样的话你的带宽包括你对于用户体验都不是很好的，你可以把不同的结点多做RVS，然后在利用层看怎么做一个DNS的负载均衡。
问6：谢谢。
吴炳西：不客气。
问7：我来自新浪，我推荐个东西然后再请教一个问题，推荐的东西是通过（哈需）来分配（开区）访问这种情况，增加一台或者减少一台，有一份资料能够解决这个问题，能够最大最有效的利用（哈需），我请教的问题就是删除（开始）的时候用（剖之）这个命令，那么在Veb2.0的应用里面，如果（开亏的）应用比较高的情况下，（剖之）往往比较空，不知道有没有特别好的办法让我把它一删就删掉。
吴炳西：分小一点，不要把（死亏特）分的太大。我不知道你的（死亏特）一个目录是多少G？
问7：400G。
吴炳西：分了几个目录？
问7：这个不太好说。
吴炳西：你回去把应用尽量分两个单元，不要一台（死亏特）去扛，然后一下分了很大，一个（死亏特）目录分了20G100G情况我都见过，然后造成（死亏特）很慢，最后我也感谢新浪在咱们中国互联网这块做了很多开源的项目，也特别感谢你。
主持人：还有吗？
问8：你好，我是来自北邮的，我想问一下在GR的模式下考虑RVS的的话，做健康检查可以是吧？
吴炳西：RVS本身没有健康检查功能，我们需要借助一些软件。
问8：我看您刚才给出的数据是大概500万没问题，如果做了健康检查会不会下降很多呢？
吴炳西：不会。
问8：那么IDS有没有比较好的方法和（48：43）。
吴炳西：这个目前我们在生产中没有应用，因为它确实对大型应用做一些架构很适合，（嫩定）注重的是性能，还建议用（阿帕奇）。
问8：我再问一下您的ID是怎么进行（49：11）
吴炳西：你可以找一些现成的软件去测一些定8，或者去创建一些连接不让它断开都可以。
主持人：注意一下提问的时候就两个问题，因为可能提问的人比较多一些。之前有杨春雨可能在网站上提过一个问题在哪。
问9：我是搜房网的，我在这里简单讲一下我们是怎么用RVS和（阿帕奇）的，我们用RVS的方式做负载均衡，但是我们机房有两个网卡，有一个内网有一个外网，这样解决了RVS必须用外网IP的这个东西，就是说我有两个网在机房里头，再一个是我们NDS和RVS设计的时候要求程序分开，但是有可能分开很麻烦，但是我根据它的目录，如果是动态的走（阿帕奇）静态的用（死亏特），这样的话可能效果会好一点。
问10：你好我想问一下我刚才看了您的RVS加（死亏特），但是我好象没看您讲针对（阿帕奇）这块是怎么实现健康检查的？
吴炳西：这块是（嫩定）这块去实现的。
问10：（嫩定）这块是实现（死亏特）的。
吴炳西：如果（阿帕奇）停掉之后用（嫩定）去访问（死亏特）就访问不了了，因为这个服务不可用了。
问10：我觉得这样的话您刚才说的，我们可能不能及时发现这个问题。
吴炳西：这个就是我刚才跟您说的一个对每台机器进行健康检查，我推荐一个软件（那构思）对每台机器进行健康检查，当我的（阿帕奇）死掉之后我们发现能够尽快解决掉。
问10：没有别的更好的方法了，只能通过这种额外的监控软件，我们不能实现不用去管，不会出现单点的故障？
吴炳西：这种情况太理想了，其实（阿帕奇）经常死掉或者不服务了，直接重启一下这种服务，如果说很冗余了，确实想法很好，但是我觉得实现的成本包括工作量都不太容易实现。
问10：我可能有点不同的态度，因为这个我已经实现了，我觉得您现在没有讲。（死亏特）本身的模式可以针对这种进行服务器的定点指向，这个是可以实现80后的健康检查的，如果（阿帕奇）死掉以后它自动不会在网上转发数据。
吴炳西：你的意思是在（死亏特）多定义两个结点对吧？
问10：对，然后是（死亏特）这块进行转发、判断，因为我在实际中已经这样应用了。
吴炳西：那么随后你可以把你的方法发到CU或者我们的网站上面，跟大家交流一下。
问10：因为我看到有这方面的介绍，但是没有跟您这结合起来。
吴炳西：我们不可能考虑的那么完善，我们只能说在我们的业务逻辑能走得通，而且走的非常顺利，我们都会这样采用，包括你说的（死亏的）这块的功能，我们也基于域名的拓展，但了我们没有基于两个点，我们基于一个点。
问10：我效果比较好。
吴炳西：那我们可以随后关注一下。
主持人：您是来自于哪个东西？
问10：华宝汇通公司。
吴炳西：欢迎你发个帖标注一下你，谢谢你。
问11：对于刚才他的问题我其实已经在几个月之前就解决了，（死亏特）在2.6和3.0版本已经完全可以做到负载均衡和（UC的哈需）了，应用的话我应该是在奥运完了之后做出来的。
吴炳西：欢迎你把你的方法进行分享一下。
问11：应该已经写过了。
主持人：您的网名是什么？
问11：刘三刀。
主持人：最后一个问题。
问12：我问两个比较实用的问题，最后（塞我）怎么得到客户端的IP，是一定要签JS，还是说可以在第一层中，直接打一个http，然后把用户的IP写进去，最后用DHP，我想知道这点通常是怎么实现的？
吴炳西：我们通常用BS，因为我们在应用中日志写的量非常大，全部用JS采集到专用的服务器上。
问12：还有一个比较实用的问题，大家在用（安得斯）的时候，有没有出现过不太稳定的情况，我碰到以前有一台产生接近20G的（爱肉）这样一个文件。
吴炳西：怎么产生的？
问12：具体怎么产生的我不太清楚，但是有时候发现磁盘就满了。
吴炳西：这个情况我也不敢断定怎么产生的，所以你下次可以用GDB调试一下，估计是缓冲区不稳定造成的，可以调试一下看看。另外大家分享一下对于（开区）软件用什么方法找到错误的原因，因为我们都可以拿到代码，然后用GDB包括小的错误文件直接用VAM去打开看，然后找到相应的错误，然后去找相应的代码，因为错误已经产生，代码会有提示，不过你需要耐心的查，因为我们有的时候遇到的错误有的时候是一个月遇到一次，如果花一个月去解决是很值的，好的，谢谢大家。
主持人：大家看来对负载均衡的实现还是非常感兴趣的，话题也会比较多一些，刚才的演讲是吴炳西对负载均衡的实现，接下来可能会有readword的一个企业级的解决方案，然后我们有请梁世鹏先生对大家做一个企业级的分享。好，欢迎！
梁世鹏：首先我做个自我介绍，我是做硬件负载均衡已经6年了，没准在硬件网络方面比较熟悉，但是对于应用方面都不如各位，我今天给大家介绍的题目是梳理业务的脉络圣经，我说个题外话，我前端时间发现我做技术做傻了，老是在想我怎么通过技术实现事情，而不考虑技术以外的事情，那我们其实也一样，比如说我们做应用，我们应该考虑到应用网络怎么配合，两个部门怎么配合起来能够使我们的应用更优化，再一个我们做应用是否考虑到我们业务的发展，我们做一软件做一套应用，应用给用户提供在线的服务，那到底用户感受和体验怎么样，质量怎么样，给你公司和老板带来的价值怎么样，所以当你的思路开阔以后不再局限于技术，而高于技术的话，那你就成长了，希望大家也这样。
今天我介绍的题目是梳理业务的脉络圣经，所以我今天不说应用，也不说网络，我只关心业务，所以我今天所有说的事情无论是服务器、交换机、数据库、各种软件最终目的是为我们的业务服务，只有业务才能给我们老板和公司带来价值，那么在介绍我的题目以前，我临时组织了几页的对比，刚才大家已经介绍了很多通过软件的方式如何实现负载均衡，那么我做了一个简单的对比，我们看软件和硬件根本的区别有两个地方，第一个地方是性能，第二个是功能，那么性能其实刚才已经介绍过了，说软件的方式已经实现了上百万级别的并发的处理能力，我觉得很惊讶，我从来没有想到会实现这么好的效果，但是衡量负载均衡的有几个关键性能指标，第一吞吐力怎么样，就是你能实现500万，你是保持了，但是如果有10个G或者8个G流量过来，你这台机器能不能扛住，第二个问题虽然你能保持住500万，那么我一秒新进10万个你能不能扛住，这是我提的第二个问题，所以说我觉得和硬件根本区别就在于如果你三个指标都能满足软件的方式，吞吐力达到1个G2个G甚至10个G，并发达到上百万，新进的用户能达到10万以上，那我硬件市场基本上就没有了，我今天也不用讲了。
那么从利用的层次来讲，除了这三个指标来讲，硬件的好处在于可以给多种业务同时提供负载均衡，它对业务是透明的，那可能我们对应用服务器、对外部服务器的脚本可以单独定制，但是我负载均衡设备是不需要单独定制的，我已经把要考虑的事情都已经考虑到了，相当于很多工具有各种各样的解决方案，但是硬件负载均衡就是给你一个工具箱，你没有想到的我都想到了，但是这个工具箱价值不菲，这是第一个层次。
第二个层次就在于负载均衡其实包括两个层次的概念，第一个层次就在于用户的并发，就是一个业务量很大，比方说今天服务器处理性能是1000个并发，1000个能承受，超过就不行了，但是现在有1500个怎么办，再加一台，这样的话我把1500个均分给两台服务器，这是最基本的用户并发的概念。
还有一个层次在于业务级别的同步，举个例子，我在A服务器上做了登录，如果过段时间再访问进来，负载均衡B服务器，你这个没有通过B服务器这个业务是没法做的，我在A服务器上登录在B服务器上查询是不行的，这个是硬件负载均衡的一个问题，就是做不到业务级别的同步。
另一个层次上来讲，比方我们常用的Veb软件，像数据库它也有（科瑞C）软件，那么这个软件实现了两个功能，第一个用户并发，第二个内容的同步，所以说我从这两个点给大家区分一下硬件负载均衡和软件负载均衡区分在哪里。
那么看一下我的工具箱，这个工具箱都有什么工具呢，首先看健康检查，健康检查方式很多，从三层给你一个地址，四层看你的端口是否开放，甚至看页面的有无，甚至可以模拟一个用户的登录，把整个业务全走一遍，这样的话就验证一个业务。并且硬件负载均衡还有一个好处可以动态的判断服务器资源的占用情况去做智能的健康检查汇报。
前段时间我们做了两个案子，一个是我们在人寿，他们用了一个Veb2.0，但是差异很大，因为有的时候做业务的时候，虽然一个汇报我认为是重要的，但是每个汇报里面做的业务内容不一样，做的业务强度和访问量不一样，这样就导致了CPU压力不一样，这样怎么办呢，我就可以根据Veb对占的值可以设定，比如说对占100最多，那么我就设到70，达到70以上我不再给你这台服务器，而给其他人，你可能需要监控我的服务器，CPU情况，内存情况等等，然后再返回一个东西给负载均衡的部分，这个做起来很难，并且稳定性和可靠性都受到影响，但是我们经过硬件实现了，经过我们很多商业用户的使用，没有任何问题。
第二部分是容错部分，容错部分当负载均衡设备可以对多台服务器做负载均衡，当一台服务器出现问题可以快速发现，一个是不是真死了，第二个是不是处于亚健康状态，这是软件很难做到的，第二种是逻辑服务器出错，因为有的时候服务器可能是物理的服务器，有可能是利用CPU开多个进程共同进行一个服务，比如说80、81、82、83、84共同提供同一个业务，做健康检查也是一个问题，我们可以硬件去解决，再一个负载均衡设备的容错，既然我可以保证服务器级别的容错，那么我们还可以设备出现故障，也使整个业务的中断呢，那我们设备可以通过两台做设备的冗余，当一台主设备出现故障的时候，我把在线给第二台设备，接管过来的时候绘画不会出现任何中断，这是我们一个好的地方。
第三是绘画保持，这对我们网站来讲很重要，比方说我访问一个在线交易网站和一个登录页面，登录完了有一个查询页面，查询页面有一个交易的页面，有四层的链接，如果负载均衡方式的话，我可能我登录到A服务器转到B服务器、C服务器，这个业务是不行的，那我必须把具备同一个业务流的数据包连接给同一个服务器，这个我们用很多方式都可以实现，比方说只要是同一个IP的都可以丢给同一个服务器，那么另一种方式可以基于（哈希）这个方式很巧妙了，比方说有一个BBS的网站，你要保持登录信息一年还是一周，以前你可能是放到服务器上去，但是如果做负载均衡，我们基于原来的（哈希）的话，我们就可以把原地两台服务器或者三台服务器，我除以你的服务器数量，我把原地址除以3，如果余1我认为你应该到第一台服务器上去，那么经过一年之后你还可以到这台服务器，这个就很巧妙了。
当然了还可以基于（库克）的方式，如果单台服务器做这种方式很简单，没有问题都能做业务，但是如果有两台服务器，两台服务器（库克）不一样，那访问是不成功的，必须通过硬件负载均衡设备帮你记住每个（库克）是谁发的，硬件过来还给谁，当然了这里可以设定（库克）的时间，一天或者一周或者一年，这就意味着只要带着同一个（库克）过来，我这里有一个（库克）的记录，我一定会还给当时发（库克）这台服务器上去，但是如果你觉得很麻烦，你还要设（库克）的设置，那怎么办呢，我负载均衡设备可以帮你去插入一个（库克）就解决了。
当然另一个层次还可以进行（3深AD）的保持，比方说Veb有一个标志，（库克）里面有一个什么字符，你赶上结束的一个值，那我就可以动态的打开你的数据包，我会记住这个是谁发的，当这个用户带着这个信息过来的时候，我仍然会丢给同一个服务器，这样特别简单，你打一个勾就完了，不需要做很多的操作。
计算功能就更丰富了，负载均衡真正是应用的好帮手，比如说七层的访问控制，我们做银行的案子的时候就有很多这种需求，我一个普通的帐号用户不能够访问VIP路径下的所有内容，不能用我就拆包，看你的帐号和路径是否匹配，如果发现你是普通用户帐号，而是访问了VIP路径，我直接把这个网切掉，只要在设备上统一配置就可以了，不需要做任何调整。
基于内容的负载均衡，刚才有人问个问题，虚拟主机怎么办，比方说我们现在架外部服务器，但是后期我要架个虚拟主机，要供同一个虚拟地址，那么有了硬件负载均衡设备就不需要改任何应用，你的业务名称是什么，你的域名是什么，www.sina.com，ok就完了，就这么简单，8081是新浪，8082是搜狐，我来帮你区分，对外可能是80，对内可能是一个域名一个业务，这个我可以帮你实现。
像（X2）的插入都可以做，甚至可以做HDB同定向，比方说你的业务没有电子商务，你不需要作加密，但是过了一年之后你有了这种需求，但是你改正习惯比较难，你可能需要在应用上做一个改变，如果有了负载均衡设备就不需要了，只要访问VIP地址就可以实现了，这样硬件实现起来就特别简单，就好象你打开笔记本各种需要都有了，不需要改动了。
叶金荣：这个例子只要是一个确定的条件，只有一行记录一行就没有记录，第二个是两个表，两个表的结构数据是一样的，第三个其实是类似的，我们展示一下（X铺瑞），我们每次查询的时候尽量用这个来解析一下，是否会产生额外的排序是吗？
其他来定位瓶颈的工具，第一个是慢查询，我们现在有一个比较好的补丁，就是微妙级别的慢查询，很多人应该会关注这些，也就是国外自己成立的公司叫（P叩门），他们开发了这个补丁，我们一直在用，非常好用，建议大家多用一下。其他的我就不再具体说太多了。
调试的几种途径，最关键的一点就是硬件，如果你有钱可能人做的事情就比较少，只要花钱买硬件，还有是参数的设置，大家可能是以默认的参数设置，有些参数像8照的内存肯定是非常差的，肯定不适合。
还有是应用程序架构，这个刚才曹刚已经讲过了，最后是查询的办法，很多情况下我们收尾的时候，可能一开始尤其是新手就不注意是否需要创建相关的索引，一个查询条件如果是固定的，你去可以创建相应的索引，但是如果同样设三个字段，但你却每次都把这个字段收起来，那么是没办法的设定顺序的，但是新手很可能会忽略这个问题。这个地方我需要特别讲的就是，文件系统这是我自己实际测试的一个例子，那么我们现在所有的数据库的文件系统，新的都采用XFS，相比我们EFT3相比可能快个1.3到1.5倍的空间，如果没有特别的需求的，我们建议用XFS，这个确实相对比较快一点，还有改变买设备的新版本，虽然提供了新功能，但是性能方面反而差一点，但是如果利用买的新版本提供的新功能得到一些功能提高的话，那么性能差一点可能从功能上弥补回来一点，比如说新版本支持子查询，但是旧版本不支持子查询，可能一个查询会非常麻烦的折腾。
接下来说一些重要的参数配置，如果用主要的存储引擎是（买按三木）的话，那么K800相信是非常重要的一个参数，那么现在有一个局限性，最大的K800只能是4个G，但是我们可以通过变向的扩展，也就是说我们可以设置多个K800，但是很多人可能不太了解，我们可以设置多个K800，让它总和来突破4个G的限制，如果我们在查询的时候可以利用这个800来对索引进行排序，尽量不使用磁盘空间来排序。
下面（腾波开报）这个需要注意的是，现在的版本（腾波开报）如果配置的话，必须后面的参数和这个一样，否则这个参数是不会生效的，如果我们用的是（引得地位）这个引擎，最重要的参数就是800，如果我们做应用的我们建议配置大概是内存的80%，比如说现在我用的机器是8个G或者是16个G的内存，如果是8个G我用6个G，因为它还需要留一点给其他的，但是内存给配置越多越好，因为很多东西都放在内存里面，内存的利用率不是那么高的情况下，完全依赖内存未必是件好事，因为并不是越高速度越快，这个有些人可能会有经验。
接下来讲的是应用和程序方面的优化，如果我们单表数据非常大的情况下，我们通常采用分表，让（铺绕死）帮你实现，还有就是（买色够）实现读写的分离，在这个基础上，我们实现负载均衡，用第三方工具也好，用自己程序实现也好，在多个之间来实现读的负载均衡，还有就是采用（买色够6.0）以上才能支持的（买色够class），虽然现在可能效益不太好，但是能实现高可用方面还是值得试一试的，因此将来这是他们发展的一个主流，如果我们有机会尽量多用一点好。
还有统计信息，我们通常情况下，有可能是需要对一个表进行统计的时候，有可能是时时的，在线的运行数据表上进行统计，那么我们推荐用新建统计表，定期的来更新它，不是说时时的对线上表进行统计。还有就是存储过程代替大量的程序交互，如果固定的应用模式的情况下，我们完全可以利用一个写好的存储过程接受参数方式，来帮我们完成以前可能需要程序相互交互在于实现的方式，这样减少我们的工作量，另外我们性能也能得到提升。
接下来是查询的优化和索引的优化，我们很多查询其实都是可以利用联合索引来完成，如果我们经常对多个字段进行查询的话，我们完全可以建立一个联合索引，如果我们如果使用索引的情况下，我们可以用已有的索引而不需要创建单独相对独立的索引，这是一种浪费，还有就是查询缓存，（买色够）查询缓存效率不是很高，命中率不是那么高的情况下，我们可以采用（脉搏开始）来实现。
刚才说查询缓存，如果每条首位句比如说有个函数，如果有个条件，如果在（买色够）查询条件里面有一个不确定条件因素的话，那么有可能导致我们没办法使用查询缓存，每次都需要重新解析一遍，其实完全可以把这个条件写成固定的值，这样我们就可以利用查询缓存，而我们应该尽量缩短每个事物，如果事物写的太长，会导致大量的并发的锁的发生，还有数据字段，字段尽量在当前情况下需要用多少，我们就给它分配多少，而不是一口气直接分配很长的字段，一个人的名字最长也就几个字，其实没有必要分配100多个，完全浪费空间、浪费索引和内存，完全没有必要。
字符型的字段采用前缀索引，比如说像名字这么一个字段的话，那么完全可以采用前缀索引，因为前面一部分我们可以取一个平均值，就不需要对整个字段全部进行索引，这样索引能短一点，所以说搜索的速度会更快一点，现在性能还是不太好，如果我们需要高可用的环境下，可以用一下，常规的模式下我们可能用不着。
接下来是其他一些小的需要注意的地方，emileDV表尽量不要靠着性，因为它没有及时性，DV是一个事物表，没有办法利用统计器来保证时时更新统计信息，因为它是一个事物表，可能当前的事物看到的可能是一行，下一个事物可能是两行，结果下一个事物又变成一行，没办法实现这个统计，操作尽量一起提交，但是尽量不要让事物显得非常大，因为这样会导致锁，每个事物尽可能的短，否则可能会引起严重并发的锁，还有emileDB的日志，这时候你需要看一下你有一个叫（老歌）相关的运行状态值，来计算一下，比如说每分钟能产生多少份资料，我们尽量不要让日志文件太大，否则在机器关掉的情况下，重启自动修复的时间非常长。
还有是左连接的时候尽量把数据量分在前面，因为读取的数据是第一个表先读取，如果数据量比较小，产生的结果会尽可能小，后面对其他表进行扫描的情况下也会更快一些，还有就是EmileDB（老歌）刷新的一个参数，如果可靠性不是非常高的情况下，如果设置成零的话，如果机器死掉的话可能会丢失Emile甚至更多的数据，所以我们推荐设置成2，如果不太注重这么一个可靠性，那么可以设成零，这样性能是最高的、最快的。
还有是定期的小表可以这么做，大表尽量不要这么多，定期对表进行一个重新整理，如果大表是不能这么做的，因为大表每次都需要重建，会非常慢。还有在引擎中如果需要用到字符型的，因为（马来散花）的索引和Emile索引是不太一样的，优先的是定长的索引，但Emile正好相反，它优先考虑的是动态长的字段，它的性能会比前者高一些。
接下来讲一下我之前工作中碰到的案例，因为我们是做网络游戏的，大家可能有点了解，我们当时设计过一个表，一个表里面有几十个字段，这个表里面也有十几个（太仆）字段，这个表仅仅只有50万数据量，但是单个表空间文件都能达到几十个G，这是一个非常吓人的结果，因为每次都需要对几十G的文件进行操作是非常慢的，后来我们进行一个测试，把这十几个G的字段分开成三个表，根据平均长度放在三个表里面，那么分开表之后，三个表空间总和不到10个G，大家知道对比是差多少了，然后还有对它进行简单备份的时候，相比之下可能快个1.5倍到2倍的差别，刚才说这个目的就是说尽量不要在EmileDB表中使用非常长的（太仆）类似，另外如果有需要的话要跟原表分开，否则会严重影响性能的。
接下来我推荐几本书，第一本是（买塞欧）官方的手册，尽量读英文原版的手册，因为中国也有人翻译过，不过效果不太好，第二本是Peter写的《高性能（买色够）》，接下来是互动的环节，大家有什么问题可以提问一下。
问1：您好，我想了解一下（01：31：35）
叶金荣：如果你写收尾句的时候，你需要进行比如说超过三四个表规模连接的情况下，而且三四个表数据量相对比较大的情况，我推荐你分开写，如果三四个表都是小表就无所谓，也就是说我们一次查询需要扫描的原始记录超过一百万的情况下我们推荐分开，如果小于一百万无所谓，这个东西跟你的机器性能有关系，完全是根据个人的经验。
问1：我觉得分开以后都会起到一个循环，小表查询会很多次，我觉得那样也不是很好。
叶金荣：你可以自己比较一下，一次查询1百万的记录和你把把一百万条分成100次，一次1万条所用的时间，你会发现是否值得这么做，如果发现总时间变小可以这么做，如果发现不行，我推荐你检查一下你是否用到索引或者有没有存在其他的一些问题。
问1：我怎么才能得到你的奖励？
叶金荣：这个我想我们事后可以在我自己的网站上都能下载得到，这个你放心，没有问题。
问2：你好，我有一个问题，是这样的，（买色够）上面如何做数据库的审计，我说的审计是什么时候有插入的语句，或者是（得类特）之类的，（买色够）上面是否提供了这种功能？
叶金荣：这个我想在（买色够）5.0版本以上可以实现，但下于5.0的情况下暂时没有的，我们还需要对它进行很多的完善，我们可以做一些简单的审计。
问2：我想问一下这里面的一个触发器是系统的一个进程还是一个应用程序？
叶金荣：触发器是系统（买色够）提供的一个功能，既不是进程也不是应用程序，相当于一个索引，内置就支持的。
问2：我想问一下触发器等于是集成在数据库里面的一个功能。
问3：我有两个问题，一个是（DB）被（欧肉铺）收购之后，然后（买色够）被（死昂）收购之后，你对它以后的发展怎么看，我个人感觉从4.0到5.0有很大的突破，但目前来说（死昂）的创始人自己说新的5.2让我们不要用。
叶金荣：5.1才刚发布的。
问3：您对这个怎么看？
叶金荣：大家不要因为这个事情对（买色够）产生失望的状态，完全没有必要，因为第一peter现在新创建了两个分支，第一点他们自己在维护新的引擎，然后还新增了很多的补丁，我们一直都在用，第二点（买色够）官方也在自己组织存储引擎，也是将来意在取代（乙醚DB）的，这点是不用担心的。
问3：那我的第二个问题，因为刚才您说到了，您的游戏方面用到了（买色够），因为我们这块有同样的问题，在网络游戏里面正好跟普通的应用有点相反，读写可能是返过来的，那你们当时有没有考察过他们两者的引擎在写的时候的差异性？
叶金荣：我们一开始用的时候已经是（买色够）了，没有办法考察。
问3：好的，谢谢。
叶金荣：我们之前发现我们的数据量也才四五十个G，所以我们采用EmileDB没有任何问题，我们都利用到现有的索引，因为网络游戏本身的应用模式相对比较简单，没有必要用非常复杂的，只要我们把内存加到足够了，还有磁盘也可以了，问题不大。
主持人：现在请大家问一个问题就行了。
问4：你好，我是来自高校的老师，叫（买色够）的，我想问一下（买色够）专家组都做些什么，第二个就是怎么加入这个组？
叶金荣：第一我们的目的是推广（买色够）在中国的应用，很高兴我们第一次听说在高校有人在教（买色够），这个是我们以前不敢想象的，我们专家组希望有能力的同学可以跟我们一起加入，因为这次是公益活动，有需要的可以访问我的个人网站。（买色够）.cn。
问5：对于咱们这么大型的（买色够）的环境，它的数据的备份和恢复的策略一般都是怎么做的？
叶金荣：想要实现一个可靠性比较高的备份一般都采用（买色够）（斯莱）备份。因为你想要在很少的时间进行备份，然后再加上（宾老）增量备份，如果（宾老）产生比较多的话，你再还原是非常慢的过程，所以最好在（斯莱）进行备份。在线这个功能实现的还不是太好，现在我们能做的就是利用（买色够）（斯莱）进行备份。
问6：你好我想问一下对于大表的水平分割和垂直分割的依据是什么，根据什么来判断需要做水平或者是垂直分割？
叶金荣：水平分割就是达到一定级别的话访问比较慢了就需要做水平分割，垂直分割比如说很简单，现在SNS网站，很多人一开始设计的时候，都会把所有用户的信息放在一个表里面，但是实际上我完全可以分开，一些扩展的用户信息，我们可以放在一个大表里面，然后一个用户最简单的，比如说用户ID、用户名、用户密码，我们可以放在一个小表里面，这就是垂直分割。
问7：你好，您刚才提到（买色够）复制，我想问一下实际生产中遇到的问题，我现在部署了一台（吗四德）、几台（死来我），但是在复制的时候会丢数据，我不知道是我配置的问题还是说不可靠的问题。
叶金荣：丢数据是不可避免的，我们只能定期的检查，定期的进行重建，因为你用多个（死来我），如果你发现其中一个不行了，你可以丢弃掉，重建就行了。
问7：也就是说它是不可靠的。
叶金荣：也不是说不可靠的，不是百分之百的可靠的，任何一个软件都不可能保证完全可靠，但是我们可以利用第三方的工具来定时的检查我的数据的可靠性，如果发现有问题就及时进行重建。
主持人：还有有问题的吗？
问8：你说读写分离以后，这个有没有好的办法解决？
叶金荣：这个确实是一个问题，我们可以采用双帮式的方式实现，就是两个（吗斯特）之间互相同步、互相写，我们可以实现两个（吗斯特）底下挂多个（死来我），或者说两个（吗斯特）一个做备份，另一个（吗斯特）用来挂下面的（死来我）。
问8：两个（吗斯特）是（买色够）自己的机制还是用？
叶金荣：两个（吗斯特）和（买色够）是一回事，只是说另一点也是（吗斯特），平时情况下可能只需要写一台，如果发现挂了，可以用HA或者HB来自动发现自动切换，然后利用虚拟IP类似这种原理的方式来实现自动切换。这个是在很多地方有很多用过了，是没有问题的。
问9：你好，我问一下，统计数量你们用哪一个解决这类的问题？
叶金荣：我们一般不会关心有多少数量，我们只关心大致的数量，TVDB是事物的表，你可能现在看到一条，一会看到两条，结果回过头来又看到一条。
问9：比如说我目前是操作一个列表，但是我们这个表要知道这个数据有多少条，那么我是用哪一条策略解决？
叶金荣：如果需要确切的数据是没办法的。我们只是建议不要这么做，因为它是个事物的东西。
问9：我现在需要解决一个问题，比如说（买色够）有一个应用，比如说博客，这个所有数据画一个表里头可能达到几个G，我们肯定需要一个方式来解决，比如说类似的你们是怎么解决这样的问题的？
叶金荣：这个我想应该根据你架构的具体需求来做，因为比如说你可能你的访问用户更多的是比较分散的访问，你需要对不同的比如说像博客，博客通常都是针对用户的ID来进行访问的。你可以实现多个散面同时应用，你这个问题其实更应该让刚才的曹刚来给你回答。
问10：我想问一个问题，可不可以在（买色够）做负载均衡，因为这个问题我四年前就想了，我当时还给（买色够）的CEO专门谈过这个问题，他那个时候就说他们做（买色够）的Class，但是我觉得到现在这个也没有完全做出来，如果做一个负载均衡比方说可以做一些前面加上（哈希），也可以做一些分布式的各种功能，我觉得是非常有意义的事情，我不知道这么多专家在这，有没有在这方面做一些思考？
叶金荣：（买色够）的负载均衡一般还是采用（买色够）的复制，这个复制是可以实现多个（吗斯特），因为我可以实现（买色够）的环形复制，比如说我有ABC三个（吗斯特），那我实现一个环形的，那么在这个环形里面三个点，都可以做负载均衡的，我们可以在这三点之间同时写入数据，但是更好的方法还是采用（买色够）class，因为这毕竟是（买色够）发展的主流方向，环形的（吗斯特）可靠性还是需要靠第三方的软件来实现，（买色够）复制本身会丢数据的。
主持人：相信大家应该还有很多问题，但是现场时间关系，咱们就先问到这，如果有问题可以跟叶金荣私下交流和探讨，谢谢叶金荣。接下来还有一个演讲，演讲的主题是CDN网络架构建立的实地演讲，然后由田意田先生来给大家演讲。
田意：实际上让我来讲这个题目，本来我搞的比较多的是负载均衡之类的，但是让我讲CDN我经验不是很多，可以把思路和一些基本的东西跟大家交流一下，如果要提问的话，我的原则是能答的就答，不能答的就不答了。
耽误了点时间对不起，CDN我们可能有不少的架点用到CDN技术，刚才有人在跟我谈他们要撤掉CDN要找哪一家的，CDN的主要用途就是解决高并发访问的一种途径，就是说解决高并发不见得CDN一种途径，这是其中的一种方法，为什么大家会产生这个需求，周围的国家的情况特殊搞的电信和网通很苦恼，现在我看分三个数据提供商了，电信和连通，移动也干上了，三足鼎立了，我估计以后会更加麻烦，所以CDN还有市场的，原来两家在做解决办法，现在要做三家了，CDN过一段时间会过的很滋润的，现在互联网发展很快，虽然我们遇到了经济危机不好的事情，但是互联网的访问量并没有因为经济危机的原因导致流量下降，反而是上升了，因为大家在网上购物不愿意出去，主要原因还是由于电信访问网通很慢，网通访问电信也是很慢的，第二个互联网虽然跨域了地域，但是从遥远的地方访问还是会中间有很多路由跳出来，导致速度上不来，这就产生了这样的需求，所以现在中国有很多CDN服务商，我想大部分都是做网络系统的，曾经都收到CDN给你打的电话，在中国好象在北京都有几十家了，北邮有一家叫“奥特曼”的，大家不知道听说过没有，它就是因为克林顿跟来林斯基这个事情，传输事情好起来的，坏事变好事，每个事件背后都会产生一个商业机会。
CDN不是功能较多的，当然前面专家们也说了，不要把一个东西统一到一个下面，没有一个功能较多的什么都能解决的，你不要前面负载均衡器，不要后面把所有的都放在上面，同样是有局限性的，只能用于某些方面，我们讲讲最常见的就是页面加速，第二个就是下载服务，下载服务很恐怖的，像杀毒软件这一类的很好的下载非常大，我现在有一个下载服务器，我们服务器光是文件很小才5个照，我开放更新服务的话，100照两下就被干死了，所以不适合直接做，所以适合把它分布到不同的地方去，用别的资源做，在2006年和2007年最好的东西是什么呢，是视频，视频这个东西一个是文件比较大，虽然说后来采用了FVIV的方式，对它压缩，码流变小了，但是不能把服务分在某个中心机房然后大家都去访问它，这是做不到的，所以土豆网的视频是分给不同的CDN去运营的，还有像凤凰网各个频道都给他们CDN运营商去搞一遍，看哪家好选哪家。
我们讲CDN的一个用途，我现在找到一份工作，我们有一个网站，我们做一下推广，好多人来访问我们了，很多用户来访问，老总说怎么我们访问不了呢，我们服务器很好，带宽100照，但是多个还是扛不住，我讲了一个众矢之的，这个不一定恰，但是是这样的，CDN的访问就变了，原来的服务器没有变，然后AD用户会访问CDN提供的边缘服务器，实际上把这个内容抓下来，放在它靠近的地方，原来是很多用户，现在是500万用户去访问一个源，然后打死了，然后现在500万用户分布到全国各地，比如说我在重庆，重庆的用户只有几万，那么访问重庆的那几个机器很容易就解决这个问题了，一个是快，第二个不会对源站产生太大的压力，经过测试比较繁忙的源站，像好一源站我看了一下，每个中心结点对它产生的连接数是几十个，如果500万的话，一个服务器最多能撑1万2千个，所以这个方式就改变了访问方式，所以得到一些性能上的改变。
CDN有很多定义，我在一个网站上抄来的，有没有版权不知道，叫光芒什么的网站，它写的内容，大家看一下就知道了，我们用自己的方式来理解它的原理，原理改变内容缓存到不同地区的缓存服务器，原来访问一个地区的，现在我把这个东西拿到靠近我的地方来，现在我有一个连锁机构，比如说麦当劳，我现在麦当劳有一款新菜，那么麦当劳只要把这款新菜告诉当地的麦当劳了，不是说从麦当劳总部给你空运过来的菜，就是就近访问，就是说我是重庆的用户，我就会想办法让他访问重庆的服务器，而不是从重庆去访问阿拉斯加的，所以就是就近访问原则，这样才能达到快的效果，第三个对应的原理，就是重庆的去访问重庆的，用DNS视图来区分访问的来源，人家一查这个DNS是重庆的，那么咱们把它引到重庆去，别到北京来捣乱。
然后我们讲怎么实现，讲了这么多，好多人忽悠我，说我们是一流的，什么都能干，不管是动态的图片的全搞了，所以我现在给大家讲讲，它到底有哪些，但是这个技术是有替代技术，我只不过讲的比较常用的，你可以替换掉的，关键是这么几个，一个是DNS视图，常用的我们就讲开源，我们搞开源搞技术，我想大家都想自己动手搞一下，搞产品很烦，看说明书，我们自己做的DNS视图我们做的不够详细，分三个视图，分电信、网通，一般就三个视图，真正的DNS运营商可以做到很多视图，做到很多省区，比如说山西省它把山西省固定的DNS做成一个视图，一看这个DNS是山西的，有山西的区域文件里一查是山西的。另外缓存，没有缓存直接访问是无法办到的，这是两个最关键的技术，一个是缓存一个是视图，然后我们有辅助技术，你说CDN运营了，前面几位专家已经说过了，负载均衡和监控这一类的，实际上我更多的是做后面两个东西，所以让我讲CDN有点赶鸭子上架，讲的不好大家批评都可以。
设计要点，这个我们使参照运营商的角色了，我们做实验没有办法做，就是大家了解一下，设计要点要选定核心缓存拟点，就是咱们用的电信、网通，又要考虑冗余性、口号性，所以各选两个，有钱了运营商会选更多的，选在哪里，谁想知道，有没有想知道的，我可以透露一下，不会选在北京，也不会选在上海，因为太贵了，所以会选在像沈阳、济南、广东的某些地方武汉，再多不说了，商业机密，别人要骂我，我们看到第一副图就是中心结点，然后再有DNA结点，中心结点是保证不出问题的，最重要的东西，然后下面边缘结点再到中心结点去，最后就不会把远站打死了，我顺便插一句，上次有一个人做声音测试，说把远站给打死了，我说你看一下，这个设计不好，全平面的，所有边缘服务器都是抓他的把它抓死了，你如果做全国的经销处，那么你就覆盖到每个省，其实根据你DNS，建议大家查询开通以后，你可以把DNS日志抓出来，然后排下去去搜一下IP在哪里，你就知道大致你的用户哪里多哪里少，IP地址。
比如说网通电信的，独立第三方的，这个东西可以自己去搜集，我自己搜集到两个，谁要我就给它，网通有1700多条，就是说1700多网络，电信我选了大概有1100多条，但肯定包不完，所以DNS解析就靠这个搜集来的ID段，我们定义了区域文件，什么.com什么的，它每个视图对应的区域文件解析的不一样，那么转到哪里去了，归IP，然后容错和负载均衡，你说CDN发到全国去了甚至全球去了，比如说重庆都往重庆那里解析，重庆死了我不知道，说访问不了了，我老说，我说我们干监控的就是在用户和老板发现问题之前我先发现了，老板给你打电话说出问题了，很严重，客户打电话很烦，所以你最后知道你就麻烦了，如果我们提前知道，老板打来了说我正在处理，我在维护，我要调整一下，所以你自己控制的，所以次序你要搞明白，控制权一定要在自己手里。所以说需要容错和负载均衡这个东西，实际上我在（内阁死）这方面我用的时间特别多，我以前讲过一次演示，我们IBS后面有好多一堆机器而且不同的应用，我们后面一大堆。
我们前面讲了都是运营商都是很牛的，全国网络到处买带宽，一搞就1G的，我们访问量不是特别大，但是有点增加了，又不想花太多的钱，那么我们可以考虑电信、网通多放几个服务器，比如说一边放6个，前面加两个很差的机器，LVS就8个，一边放8个，一个服务器大概5000块钱，那么我12个服务器很便宜的，然后我们放在东北或者河南之类的很便宜，只需要电信、网通两个结点，不分边缘和核心了，就这么多用户访问那6个机器，那么我算一下每个机器支撑1万的话，那么我12个有12万了，基本上能应付百万级的，所以在这一点我也没有这么多东西了。
