❶ web应用高并发导致系统数据库崩溃一般怎么解决
1、程序和数据库部署在同一台服务器上 2.多学习一些相关的书籍比如：构建高性能Web站点，大规模Web服务开发技术 构建可扩展的Web站点 ， Web容量规划的技术，分布式数据库系统及其应用。 掌握其原理和结构 。
❷ java web高并发是什么意思
并发的意思就是有多人同时进行一个操作， 比如你家大门 有两个人同时进去
这就叫并发了 要是一个人一个人排队进就不是并发， 要是 几百上千上万人同时进大门 就可以称为高并发了
并发和高并发 其实意思是一样的 不同的只是并发数量上的区别
web的并发是指 多人同时向一个url发送请求
❸ 如何解决web大流量，高并发的问题
以下是一些总结的方法: 第一，确认服务器硬件是否足够支持当前的流量。 普通的P4服务器一般最多能支持每天10万独立IP，如果访问量比这个还要大，那么必须首先配置一台更高性能的专用服务器才能解决问题，否则怎么优化都不可能彻底解决性能问题。
第二，优化数据库访问。 服务器的负载过大，一个重要的原因是CPU负荷过大，降低服务器CPU的负荷，才能够有效打破瓶颈。而使用静态页面可以使得CPU的负荷最小化。前台实现完全的静态化 当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。 缓存技术 就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-Blog都大量使用这种缓存技术 。我自己也写过一个Z-Blog的计数器插件，也是基于这样的原理。 如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询sql.避免使用Select *from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大量SQL查询。
第三，禁止外部的盗链。 外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗 链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。
第四，控制大文件的下载。 大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大 文件下载，如果需要提供，建议将大文件放在另外一台服务器上。目前有不少免费的Web2.0网站提供图片分享和文件分享功能，因此可以尽量将图片和文件上 传到这些分享网站。
第五，使用不同主机分流主要流量 将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。
第六，使用流量分析统计软件。 在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析 才可以。我推荐使用的流量分析统计软件是GoogleAnalytics（Google分析）。我使用过程中感觉其效果非常不错，稍后我将详细介绍一下 GoogleAnalytics的一些使用常识和技巧。 1.分表 2.读写分离 3.前端优化。Nginx替换Apache(前端做负载均衡) 个人认为主要还是分布式架构是否到位，mysql和缓存的优化都是有限度的优化，而分布式架构做出来了，PV增长后，只需要堆机器就能扩容。
另附一些优化经验，首先学会用explain语句分析select语句，优化索引、表结构，其次，合理运用memcache等缓存，降低mysql的负载，最后，如果可能的话，尽量用facebook的hiphop-php把PHP编译了，提高程序效率。
❹ 如何控制web程序中的并发行为
1、提供HTML静态访问
web界面上最快的访问速度是什么？当然是最原始的HTML文件访问,对于其他语言 比如 jsp ,asp,php等等,他们首先要通过服务器解析成html之后在返回给访问者，如果我们能提供全部是htm来的页面，那么就能大大的降低服务器和数据库资源的利用和提高网站的并发，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。当然实现这种方式大家比较了解的就是信息发布系统CMS,信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
在后续的文章中我们会单独的使用jsp + servlet实现一个简单的信息发布系统.
2、使用独立的图片服务器
为什么要把图片单独设置一个服务器？对于Web服务器来说，图片消耗的服务器资源是最多的，如果能把所有的图片资源放到一个单独的图片服务器中进行处理的话，可以降低提供页面访问请求的服务器系统压力，从而能进一步的提高web程序的并发.所以在有条件的情况下最好能把图片放置到一个单独的服务器中.
3、配置多台数据库服务器，多个数据库集群
集群（Cluster）技术是使用特定的连接方式，将价格相对较低的硬件设备结合起来，同时也能提供高性能相当的任务处理能力。
越是大型高并发的应用，数据库的压力就会越大，如果数据库操作很频繁，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群。
数据库集群就是使用多个数据库服务器分担请求的压力，达到快速响应的目的.
4、使用缓存
所谓的缓存就是把数据咱是放置到内存中，前台在请求的时候直接从内存中读取数据，而不需要去查询数据库或者读取文件等，这样就能做到最快的响应。网站架构和网站开发中的缓存是非常重要的。
目前有很多开源的缓冲实现方案，APC，File，SQLite，Memcache等等各种类库实现着不同的缓存方式，只有通过了解他们的实现方式，根据具体应用具体选择，才会使缓存系统发挥出最大的性能。
对于java开发来说，大名顶顶的 分布式缓存系统Memcache 可能是最好的选择，他提供一个基于Socket的访问方式，使得该缓存系统支持远程读写访问。尽管这个缓存的内容可能是存在内存中，也可能是存在文件内。
❺ C#web开发中出现高并发具体处理方法有哪些
尽量使用缓存，包括用户缓存，信息缓存等，多花点内存来做缓存，可以大量减少与数据库的交互，提高性能。
用jprofiler等工具找出性能瓶颈，减少额外的开销。
优化数据库查询语句，减少直接使用hibernate等工具的直接生成语句（仅耗时较长的查询做优化）。
优化数据库结构，多做索引，提高查询效率。
统计的功能尽量做缓存，或按每天一统计或定时统计相关报表，避免需要时进行统计的功能。
能使用静态页面的地方尽量使用，减少容器的解析（尽量将动态内容生成静态html来显示）。
解决以上问题后，使用服务器集群来解决单台的瓶颈问题。
基本上以上述问题解决后，达到系统最优。
❻ webservice大并发数量 应该怎么处理
先学测试吧。不是那种业务功能的测试，是系统的测试。因为要解决大数据量、高并发的问题，我个人的知识与经验是:1、先用单机测试。用工具产生大并发量去轰击服务器，直至服务器缓慢，甚至接近崩溃;3、找到系统瓶颈后，优化，解决这个瓶颈，然后再循环测试。这时你又会发现新的瓶颈，再解决。循环1 - 3步，直到各方面基本平衡为止。4、当单机无法解决问题的时候，接着开始考虑负载均衡，考虑分布式方案，然后再用 1 - 3 的步骤分析与测试。
❼ 怎么评估web系统的并发量
你可以使用loadrunner进行测试，然后进行分析数据，测出最大并发数。
❽ 大并发web报表系统 用什么框架
python的web框架很多 django (大而全，模板，orm都自带) flask (pocoo出品，比属精品，自带jinja2模板，可以替换) web.py (这个我没用过，作者自杀，白瞎了一个高手) bottle (只有一个文件的框架，需要自己构建整个开发体系) uliweb (中国人开发的，也很不错) Tornado (异步框架，适合长连接，比如在线聊天之类的) Python框架虽然说是百花齐放，但仍然有那么一家是最大的，它就是Django。Django为人所称道的地方主要有： ①完美的文档，Django的成功，我觉得很大一部分原因要归功于Django近乎完美的官方文档（包括Django book）。 ②全套的解决方案，Django象Rails一样，提供全套的解决方案（full-stack framework + batteries included），基本要什么有什么（比如：cache、session、feed、orm、geo、auth），而且全部Django自己造，开发网 站应手的工具Django基本都给你做好了，因此开发效率是不用说的，出了问题也算好找，不在你的代码里就在Django的源码里。 ③强大的URL路由配置，Django让你可以设计出非常优雅的URL，在Django里你基本可以跟丑陋的GET参数说拜拜。 ④自助管理后台，admin interface是Django里比较吸引眼球的一项contrib，让你几乎不用写一行代码就拥有一个完整的后台管理界面。
❾ javaWeb如何提高并发数
对Collection、Map接口的类对象初始化时要先分配合理的空间大小，同时还要按照自已的实际需求选择合适的对象。
2.优化循环体
循环是比较重复运行的地方，如果循环次数很大，循环体内不好的代码对效率的影响就会被放大而变的突出。
3.少用new初始化一个实例
尽量少用new来初始化一个类的实例，当一个对象是用new进行初始化时，其构造函数链的所有构造函数都被调用到，所以new操作符是很消耗系统资源的，new一个对象耗时往往是局部变量赋值耗时的上千倍。同时，当生成对象后，系统还要花时间进行垃圾回收和处理。当new创建对象不可避免时，注意避免多次的使用new初始化一个对象。尽量在使用时再创建该对象，另外，应该尽量重复使用一个对象，而不是声明新的同类对象。一个重用对象的方法是改变对象的值，如可以通过setValue之类的方法改变对象的变量达到重用的目的。
4 .选择合适的方法调用：
在Java中，一切都是对象，如果有方法（Method）调用，处理器先要检查该方法是属于哪个对象，该对象是否有效，对象属于什么类型，然后选择合适的方法并调用。可以减少方法的调用，不影响可读性等情况下，可以把几个小的方法合成一个大的方法。另外，在方法前加上final，private关键字有利于编译器的优化。
5.异常处理技巧
异常是Java的一种错误处理机制，对程序来说是非常有用的，但是异常对性能不利。抛出异常首先要创建一个新的对象，并进行相关的处理，造成系统的开销，所以异常应该用在错误处理的情况，不应该用来控制程序流程，流程尽量用while，if等处理。在不是很影响代码健壮性的前提下，可以把几个try/catch块合成一个。
6 .尽量使用局部变量
尽量使用局部变量，调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack） 中，速度较快。其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢。
7.同步处理技巧
同步主要出现在多线程的情况，为多线程同时运行时提供对象数据安全的机制，多线程是比较复杂话题，应用多线程也是为了获得性能的提升，应该尽可能减少同步。
另外，如果需要同步的地方，可以减少同步的代码段，如只同步某个方法或函数，而不是整个代码。
8 .尽可能的使用Java自身提供的API
Java的API一般都做了性能的考虑，如果完成相同的功能，优先使用API而不是自己写的代码，如数组复制。
9 .尽量减少I/O操作
输入/输出（I/O）包括很多方面，我们知道，进行I/O操作是很消耗系统资源的。程序中应该尽量少用I/O操作。使用时可以注意： . 合理控制输出函数System.out.println()对于大多时候是有用的，特别是系统调试的时候，但也会产生大量的信息出现在控制台和日志上，同时输出时，有序列化和同步的过程，造成了开销。
特别是在发行版中，要合理的控制输出，可以在项目开发时，设计好一个Debug的工具类，在该类中可以实现输出开关，输出的级别，根据不同的情况进行不同的输出的控制。
10 .尽量使用缓存
读写内存要比读写硬盘上的文件要快很多，应尽可能使用缓冲，以便直接从内存中读取数据。尽可能使用带有Buffer的类代替没有Buffer的类，如可以用BufferedReader 代替Reader，用BufferedWriter代替Writer来进行处理I/O操作。
同样可以用BufferedInputStream代替InputStream都可以获得性能的提高
11 .尽量不使用同步：
Servlet是多线程的，以处理不同的请求，基于前面同步的分析，如果有太多的同步就失去了多线程的优势了。
12.不用保存太多的信息在HttpSession中
很多时候，存储一些对象在HttpSession中是有必要的，可以加快系统的开发，如网上商店系统会把购物车信息保存在该用户的Session中，但当存储大量的信息或是大的对象在会话中时，是有害的，特别是当系统中用户的访问量很大，对内存的需求就会很高。具体开发时，在这两者之间应作好权衡。
13.清除SESSION：
通常情况，当达到设定的超时时间时，同时有些Session没有了活动，服务器会释放这些没有活动的Session，.. 不过这种情况下，特别是多用户并访时，系统内存要维护多个的无效Session。当用户退出时，应该手动释放，回收资源，实现如下：..
HttpSession theSession = request.getSession();
// 获取当前Session
if(theSession != null){
theSession.invalidate(); // 使该Session失效
}
14 .缓存Home接口
EJB库使用Enterprise Bean 的客户端通过它的Home接口创建它的实例。客户端能通过JNDI访问它。服务器通过Lookup方法来获取。
JNDI是个远程对象，通过RMI方式调用，对它的访问往往是比较费时的。所以，在设计时可以设计一个类专门用来缓存Home接口，在系统初始化时就获得需要的Home接口并缓存，以后的引用只要引用缓存即可。
15 .使用快速度的Jdbc驱动
JDBC API包括两种实现接口形式，一种是纯Java实现的驱动，一种利用ODBC驱动和数据库客户端实现，具体有四种驱动模式：
第一类：JDBC-ODBC桥，再加上ODBC驱动程序。
JDBC驱动程序是JDBC-ODBC桥再加上一个ODBC驱动程序。建议第一类驱动程序只用于原型开发，而不要用于正式的运行环境。桥接驱动程序由Sun提供，它的目标是支持传统的数据库系统。Sun为该软件提供关键问题的补丁，但不为该软件的最终用户提供支持。一般地，桥接驱动程序用于已经在ODBC技术上投资的情形，例如已经投资了Windows应用服务器。
尽管Sun提供了JDBC-ODBC桥接驱动程序，但由于ODBC会在客户端装载二进制代码和数据库客户端代码，这种技术不适用于高事务性的环境。另外，第一类JDBC驱动程序不支持完整的Java命令集，而是局限于ODBC驱动程序的功能，这种驱动方式也叫胖客户，主要用于低并发请求，大数据量传输的应用。
第二类：本机API，部分是Java的驱动程序。
JDBC驱动程序是本机API的部分Java代码的驱动程序，用于把JDBC调用转换成主流数据库API的本机调用。这类驱动程序也存在与第一类驱动程序一样的性能问题，即客户端载入二进制代码的问题，而且它们被绑定了特定的平台。
第二类驱动程序要求编写面向特定平台的代码，主流的数据库厂商，例如Oracle和IBM，都为它们的企业数据库平台提供了第二类驱动程序，使用这些驱动程序的开发者必须及时跟进不同数据库厂商针对不同操作系统发行的各个驱动程序版本。
另外，由于第二类驱动程序没有使用纯Java的API，把Java应用连接到数据源时，往往必须执行一些额外的配置工作。很多时候，第二类驱动程序不能在体系结构上与大型主机的数据源兼容；即使做到了兼容，效果也是比较差。
第三类：面向数据库中间件的纯Java驱动程序。
JDBC驱动程序是面向数据库中间件的纯Java驱动程序，JDBC调用被转换成一种中间件厂商的协议，中间件再把这些调用转换到数据库API。第三类JDBC驱动程序的优点是它以服务器为基础，也就是不再需要客户端的本机代码，这使第三类驱动程序要比第一、二两类快。另外，开发者还可以利用单一的驱动程序连接到多种数据库。
第四类：直接面向数据库的纯Java驱动程序。
JDBC驱动程序是直接面向数据库的纯Java驱动程序，即所谓的“瘦”（thin）驱动程序，它把JDBC调用转换成某种直接可被DBMS使用的网络协议，这样，客户机和应用服务器可以直接调用DBMS服务器。对于第四类驱动程序，不同DBMS的驱动程序不同。因此，在一个异构计算环境中，驱动程序的数量可能会比较多。但是，由于第四类驱动程序具有较高的性能，能够直接访问DBMS，所以这一问题就不那么突出了， 这种驱动方式，主要用于高并发，低数据量请求的应用中。
16.使用Jdbc链接池
为了提高访问数据库的性能，我们还可以使用JDBC 2.0的一些规范和特性，JDBC是占用资源的，在使用数据库连接时可以使用连接池Connection Pooling，避免频繁打开、关闭Connection。而我们知道，获取Connection是比较消耗系统资源的。
Connection缓冲池：当一个应用程序关闭一个数据库连接时，这个连接并不真正释放而是被循环利用，建立连接是消耗较大的操作，循环利用连接可以显着的提高性能，因为可以减少新连接的建立。
一个通过DataSource获取缓冲池获得连接，并连接到一个CustomerDB数据源的代码演示如下：
Context ctx = new InitialContext();
DataSource dataSource = (DataSource) ctx.lookup(“jdbc/CustomerDB”);
Connection conn = dataSource.getConnection(“password”,”username”);
17.缓存DataSorce
一个DataSource对象代表一个实际的数据源。这个数据源可以是从关系数据库到表格形式的文件，完全依赖于它是怎样实现的，一个数据源对象注册到JNDI名字服务后，应用程序就可以从JNDI服务器上取得该对象，并使用之和数据源建立连接。
通过上面的例子，我们知道DataSource是从连接池获得连接的一种方式，通过JNDI方式获得，是占用资源的。
为了避免再次的JNDI调用，可以系统中缓存要使用的DataSource。
18.即时关闭使用过的资源
互联网应用系统一般是并发的系统，在每次申请和使用完资源后，应该释放供别人使用，使用完成后应该保证彻底的释放。
19 .架构选型
CoreMediaCMS将整个应用分成四成架构，每一层都可以独立于其他层而正常运行，每一层都可以分布式布署，极大的提高了应用系统的稳定性、可扩展性、支持高并发的要求，每一次之前通过中间件Corba进行稳定的传输数据。
20 .开发框架的选型
充分利用开源框架，可以大大提高开发效率。很多初级开发者，都采用DB JavaBean JSP这种初级的开发模式，而现在主要使用Struts、Spring等MVC开发框架。
常用开发框架构选型有：
Struts、Spring、Webwork等。
天极传媒选择的开发框架是：Struts Spring iBatis，在这个开发框架里，充分利用了Struts、Spring各自己的优点，可以选择StutsMVC，也可以选择Spring MVC。
21.分级存储
1）数据库数据分级存储：
将经常访问的数据和访问频度低的数据，分别存放到不同的分区，甚至存放到不同的数据库服务器，以便合进分配硬盘I/O及系统I/O。
2）网站内容发布之后，分级存储：
任何一个大型的网站，一般都有海量的内容，为了提高访问效率，应搭建分级存储体系，根据应用的重要性和访问并发要求，将这些内容分级存储，同时将静态内容中的静态页面文件、图片文件、下载文件分不同的Web服务器访问，降低I/O争用，提高访问效率，同时让数据存储、管理、备份更加清晰。
22 .页面静态化
一个大型网站，既有静态内容，也有动态内容。静态内容，直接通过Apache或者Squid访问，效率高，稳定可靠，更多的是受服务器等硬件设备的I/O吞吐量、网络环境及页面代码本身质量限制，不受应用系统及数据库性能限制，这些内容往往访问速度和效率不会有较大的问题。
而动态内容，除了受硬件设备I/O、操作系统I/O及内容、网络环境及页面代码的影响，还要受应用服务器和数据库性能影响，因此，这部份内容，要尽可能作静态化或者伪静态，并采用缓存技术，将其缓存，以减少对应用服务器和数据库服务器的操作次数，提高用户访问效率和稳定性。
23.缓存策略
对于构建的业务系统，如果有些数据要经常要从数据库中读取，同时，这些数据又不经常变化，这些数据就可以在系统中缓存起来，使用时直接读取缓存，而不用频繁的访问数据库读取数据。
缓存工作可以在系统初始化时一次性读取数据，特别是一些只读的数据，当数据更新时更新数据库内容，同时更新缓存的数据值。
例如：在CMS2005系统中，我们将很少发生变化的网站节点树数据，缓存在客户端，当用户登录时，一次性读入到客户端缓存起来，以后编辑在使用时，不用再从数据库中读取，大大提高了应用系统的访问速度。
当然，也可以将数据库中重复访问的数据缓存在应用服务器内存中，减少对数据库的访问次数，Java常用的缓存技术产品有：MemoryCache、OSCache等。
❿ php怎么处理高并发
以下内容转载自徐汉彬大牛的博客亿级Web系统搭建——单机到分布式集群
当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。
Web负载均衡
Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。
负载均衡的策略有很多，我们从简单的讲起哈。
1.HTTP重定向
当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302
这个重定向非常容易实现，并且可以自定义各种策略。但是，它在大规模访问量下，性能不佳。而且，给用户的体验也不好，实际请求发生重定向，增加了网络延时。
2. 反向代理负载均衡
反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。
Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。
解决方案主要有两种：
1.配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。
2.将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。
反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。
3. IP负载均衡
IP负载均衡服务是工作在网络层（修改IP）和传输层（修改端口，第四层），比起工作在应用层（第七层）性能要高出非常多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），通过IPVS（IP Virtual Server，IP虚拟服务）来实现。
在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，然后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。
上述的方式叫LVS-NAT，除此之外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，但是有一定的区别，篇幅问题，不赘叙。
IP负载均衡的性能要高出Nginx的反向代理很多，它只处理到传输层为止的数据包，并不做进一步的组包，然后直接转发给实际服务器。不过，它的配置和搭建比较复杂。
4. DNS负载均衡
DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。
这种负载均衡策略，配置简单，性能极佳。但是，不能自由定义规则，而且，变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。
5. DNS/GSLB负载均衡
我们常用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，通过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。一般情况下都是按照地理位置，将离用户近的IP返回给用户，减少网络传输中的路由节点之间的跳跃消耗。
“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），然后得到指定域名的授权DNS，然后再获得实际服务器IP。
CDN在Web系统中，一般情况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽可能离用户更近，提升用户体验。
例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的原因是防止http请求的时候，带上了多余的cookie信息），我获得的IP是183.60.217.90。
这种方式，和前面的DNS负载均衡一样，不仅性能极佳，而且支持配置多种策略。但是，搭建和维护成本非常高。互联网一线公司，会自建CDN服务，中小型公司一般使用第三方提供的CDN。
Web系统的缓存机制的建立和优化
刚刚我们讲完了Web系统的外部网络环境，现在我们开始关注我们Web系统自身的性能问题。我们的Web站点随着访问量的上升，会遇到很多的挑战，解决这些问题不仅仅是扩容机器这么简单，建立和使用合适的缓存机制才是根本。
最开始，我们的Web系统架构可能是这样的，每个环节，都可能只有1台机器。
我们从最根本的数据存储开始看哈。
一、 MySQL数据库内部缓存使用
MySQL的缓存机制，就从先从MySQL内部开始，下面的内容将以最常见的InnoDB存储引擎为主。
1. 建立恰当的索引
最简单的是建立索引，索引在表数据比较大的时候，起到快速检索数据的作用，但是成本也是有的。首先，占用了一定的磁盘空间，其中组合索引最突出，使用需要谨慎，它产生的索引甚至会比源数据更大。其次，建立索引之后的数据insert/update/delete等操作，因为需要更新原来的索引，耗时会增加。当然，实际上我们的系统从总体来说，是以select查询操作居多，因此，索引的使用仍然对系统性能有大幅提升的作用。
2. 数据库连接线程池缓存
如果，每一个数据库操作请求都需要创建和销毁连接的话，对数据库来说，无疑也是一种巨大的开销。为了减少这类型的开销，可以在MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候，再创建，空闲过多的时候，则销毁。
其实，还有更为激进一点的做法，使用pconnect（数据库长连接），线程一旦创建在很长时间内都保持着。但是，在访问量比较大，机器比较多的情况下，这种用法很可能会导致“数据库连接数耗尽”，因为建立连接并不回收，最终达到数据库的max_connections（最大连接数）。因此，长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务，控制CGI机器“盲目”创建连接数。
建立数据库连接池服务，有很多实现的方式，PHP的话，我推荐使用swoole（PHP的一个网络通讯拓展）来实现。
3. Innodb缓存设置（innodb_buffer_pool_size）
innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区，如果机器是MySQL独占的机器，一般推荐为机器物理内存的80%。在取表数据的场景中，它可以减少磁盘IO。一般来说，这个值设置越大，cache命中率会越高。
4. 分库/分表/分区。
MySQL数据库表一般承受数据量在百万级别，再往上增长，各项性能将会出现大幅度下降，因此，当我们预见数据量会超过这个量级的时候，建议进行分库/分表/分区等操作。最好的做法，是服务在搭建之初就设计为分库分表的存储模式，从根本上杜绝中后期的风险。不过，会牺牲一些便利性，例如列表式的查询，同时，也增加了维护的复杂度。不过，到了数据量千万级别或者以上的时候，我们会发现，它们都是值得的。
二、 MySQL数据库多台服务搭建
1台MySQL机器，实际上是高风险的单点，因为如果它挂了，我们Web服务就不可用了。而且，随着Web系统访问量继续增加，终于有一天，我们发现1台MySQL服务器无法支撑下去，我们开始需要使用更多的MySQL机器。当引入多台MySQL机器的时候，很多新的问题又将产生。
1. 建立MySQL主从，从库作为备份
这种做法纯粹为了解决“单点故障”的问题，在主库出故障的时候，切换到从库。不过，这种做法实际上有点浪费资源，因为从库实际上被闲着了。
2. MySQL读写分离，主库写，从库读。
两台数据库做读写分离，主库负责写入类的操作，从库负责读的操作。并且，如果主库发生故障，仍然不影响读的操作，同时也可以将全部读写都临时切换到从库中（需要注意流量，可能会因为流量过大，把从库也拖垮）。
3. 主主互备。
两台MySQL之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了“单点故障”问题。任何一台故障，都还有另外一套可供使用的服务。
不过，这种方案，只能用在两台机器的场景。如果业务拓展还是很快的话，可以选择将业务分离，建立多个主主互备。
三、 MySQL数据库机器之间的数据同步
每当我们解决一个问题，新的问题必然诞生在旧的解决方案上。当我们有多台MySQL，在业务高峰期，很可能出现两个库之间的数据有延迟的场景。并且，网络和机器负载等，也会影响数据同步的延迟。我们曾经遇到过，在日访问量接近1亿的特殊场景下，出现，从库数据需要很多天才能同步追上主库的数据。这种场景下，从库基本失去效用了。
于是，解决同步问题，就是我们下一步需要关注的点。
1. MySQL自带多线程同步
MySQL5.6开始支持主库和从库数据同步，走多线程。但是，限制也是比较明显的，只能以库为单位。MySQL数据同步是通过binlog日志，主库写入到binlog日志的操作，是具有顺序的，尤其当SQL操作中含有对于表结构的修改等操作，对于后续的SQL语句操作是有影响的。因此，从库同步数据，必须走单进程。
2. 自己实现解析binlog，多线程写入。
以数据库的表为单位，解析binlog多张表同时做数据同步。这样做的话，的确能够加快数据同步的效率，但是，如果表和表之间存在结构关系或者数据依赖的话，则同样存在写入顺序的问题。这种方式，可用于一些比较稳定并且相对独立的数据表。
国内一线互联网公司，大部分都是通过这种方式，来加快数据同步效率。还有更为激进的做法，是直接解析binlog，忽略以表为单位，直接写入。但是这种做法，实现复杂，使用范围就更受到限制，只能用于一些场景特殊的数据库中（没有表结构变更，表和表之间没有数据依赖等特殊表）。
四、 在Web服务器和数据库之间建立缓存
实际上，解决大访问量的问题，不能仅仅着眼于数据库层面。根据“二八定律”，80%的请求只关注在20%的热点数据上。因此，我们应该建立Web服务器和数据库之间的缓存机制。这种机制，可以用磁盘作为缓存，也可以用内存缓存的方式。通过它们，将大部分的热点数据查询，阻挡在数据库之前。
1. 页面静态化
用户访问网站的某个页面，页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次，是通过动态CGI查询数据库获取之外，之后都直接将本地磁盘文件返回给用户。
在Web系统规模比较小的时候，这种做法看似完美。但是，一旦Web系统规模变大，例如当我有100台的Web服务器的时候。那样这些磁盘文件，将会有100份，这个是资源浪费，也不好维护。这个时候有人会想，可以集中一台服务器存起来，呵呵，不如看看下面一种缓存方式吧，它就是这样做的。
2. 单台内存缓存
通过页面静态化的例子中，我们可以知道将“缓存”搭建在Web机器本机是不好维护的，会带来更多问题（实际上，通过PHP的apc拓展，可通过Key/value操作Web服务器的本机内存）。因此，我们选择搭建的内存缓存服务，也必须是一个独立的服务。
内存缓存的选择，主要有redis/memcache。从性能上说，两者差别不大，从功能丰富程度上说，Redis更胜一筹。
3. 内存缓存集群
当我们搭建单台内存缓存完毕，我们又会面临单点故障的问题，因此，我们必须将它变成一个集群。简单的做法，是给他增加一个slave作为备份机器。但是，如果请求量真的很多，我们发现cache命中率不高，需要更多的机器内存呢？因此，我们更建议将它配置成一个集群。例如，类似redis cluster。
Redis cluster集群内的Redis互为多组主从，同时每个节点都可以接受请求，在拓展集群的时候比较方便。客户端可以向任意一个节点发送请求，如果是它的“负责”的内容，则直接返回内容。否则，查找实际负责Redis节点，然后将地址告知客户端，客户端重新请求。
对于使用缓存服务的客户端来说，这一切是透明的。
内存缓存服务在切换的时候，是有一定风险的。从A集群切换到B集群的过程中，必须保证B集群提前做好“预热”（B集群的内存中的热点数据，应该尽量与A集群相同，否则，切换的一瞬间大量请求内容，在B集群的内存缓存中查找不到，流量直接冲击后端的数据库服务，很可能导致数据库宕机）。
4. 减少数据库“写”
上面的机制，都实现减少数据库的“读”的操作，但是，写的操作也是一个大的压力。写的操作，虽然无法减少，但是可以通过合并请求，来起到减轻压力的效果。这个时候，我们就需要在内存缓存集群和数据库集群之间，建立一个修改同步机制。
先将修改请求生效在cache中，让外界查询显示正常，然后将这些sql修改放入到一个队列中存储起来，队列满或者每隔一段时间，合并为一个请求到数据库中更新数据库。
除了上述通过改变系统架构的方式提升写的性能外，MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许，从硬件层面解决问题，可以选择老一点的RAID（Rendant Arrays of independent Disks，磁盘列阵）或者比较新的SSD（Solid State Drives，固态硬盘）。
5. NoSQL存储
不管数据库的读还是写，当流量再进一步上涨，终会达到“人力有穷时”的场景。继续加机器的成本比较高，并且不一定可以真正解决问题的时候。这个时候，部分核心数据，就可以考虑使用NoSQL的数据库。NoSQL存储，大部分都是采用key-value的方式，这里比较推荐使用上面介绍过Redis，Redis本身是一个内存cache，同时也可以当做一个存储来使用，让它直接将数据落地到磁盘。
这样的话，我们就将数据库中某些被频繁读写的数据，分离出来，放在我们新搭建的Redis存储集群中，又进一步减轻原来MySQL数据库的压力，同时因为Redis本身是个内存级别的Cache，读写的性能都会大幅度提升。
国内一线互联网公司，架构上采用的解决方案很多是类似于上述方案，不过，使用的cache服务却不一定是Redis，他们会有更丰富的其他选择，甚至根据自身业务特点开发出自己的NoSQL服务。
6. 空节点查询问题
当我们搭建完前面所说的全部服务，认为Web系统已经很强的时候。我们还是那句话，新的问题还是会来的。空节点查询，是指那些数据库中根本不存在的数据请求。例如，我请求查询一个不存在人员信息，系统会从各级缓存逐级查找，最后查到到数据库本身，然后才得出查找不到的结论，返回给前端。因为各级cache对它无效，这个请求是非常消耗系统资源的，而如果大量的空节点查询，是可以冲击到系统服务的。
在我曾经的工作经历中，曾深受其害。因此，为了维护Web系统的稳定性，设计适当的空节点过滤机制，非常有必要。
我们当时采用的方式，就是设计一张简单的记录映射表。将存在的记录存储起来，放入到一台内存cache中，这样的话，如果还有空节点查询，则在缓存这一层就被阻挡了。
异地部署（地理分布式）
完成了上述架构建设之后，我们的系统是否就已经足够强大了呢？答案当然是否定的哈，优化是无极限的。Web系统虽然表面上看，似乎比较强大了，但是给予用户的体验却不一定是最好的。因为东北的同学，访问深圳的一个网站服务，他还是会感到一些网络距离上的慢。这个时候，我们就需要做异地部署，让Web系统离用户更近。
一、 核心集中与节点分散
有玩过大型网游的同学都会知道，网游是有很多个区的，一般都是按照地域来分，例如广东专区，北京专区。如果一个在广东的玩家，去北京专区玩，那么他会感觉明显比在广东专区卡。实际上，这些大区的名称就已经说明了，它的服务器所在地，所以，广东的玩家去连接地处北京的服务器，网络当然会比较慢。
当一个系统和服务足够大的时候，就必须开始考虑异地部署的问题了。让你的服务，尽可能离用户更近。我们前面已经提到了Web的静态资源，可以存放在CDN上，然后通过DNS/GSLB的方式，让静态资源的分散“全国各地”。但是，CDN只解决的静态资源的问题，没有解决后端庞大的系统服务还只集中在某个固定城市的问题。
这个时候，异地部署就开始了。异地部署一般遵循：核心集中，节点分散。
·核心集中：实际部署过程中，总有一部分的数据和服务存在不可部署多套，或者部署多套成本巨大。而对于这些服务和数据，就仍然维持一套，而部署地点选择一个地域比较中心的地方，通过网络内部专线来和各个节点通讯。
·节点分散：将一些服务部署为多套，分布在各个城市节点，让用户请求尽可能选择近的节点访问服务。
例如，我们选择在上海部署为核心节点，北京，深圳，武汉，上海为分散节点（上海自己本身也是一个分散节点）。我们的服务架构如图：
需要补充一下的是，上图中上海节点和核心节点是同处于一个机房的，其他分散节点各自独立机房。
国内有很多大型网游，都是大致遵循上述架构。它们会把数据量不大的用户核心账号等放在核心节点，而大部分的网游数据，例如装备、任务等数据和服务放在地区节点里。当然，核心节点和地域节点之间，也有缓存机制。
二、 节点容灾和过载保护
节点容灾是指，某个节点如果发生故障时，我们需要建立一个机制去保证服务仍然可用。毫无疑问，这里比较常见的容灾方式，是切换到附近城市节点。假如系统的天津节点发生故障，那么我们就将网络流量切换到附近的北京节点上。考虑到负载均衡，可能需要同时将流量切换到附近的几个地域节点。另一方面，核心节点自身也是需要自己做好容灾和备份的，核心节点一旦故障，就会影响全国服务。
过载保护，指的是一个节点已经达到最大容量，无法继续接接受更多请求了，系统必须有一个保护的机制。一个服务已经满负载，还继续接受新的请求，结果很可能就是宕机，影响整个节点的服务，为了至少保障大部分用户的正常使用，过载保护是必要的。
解决过载保护，一般2个方向：
·拒绝服务，检测到满负载之后，就不再接受新的连接请求。例如网游登入中的排队。
·分流到其他节点。这种的话，系统实现更为复杂，又涉及到负载均衡的问题。
小结
Web系统会随着访问规模的增长，渐渐地从1台服务器可以满足需求，一直成长为“庞然大物”的大集群。而这个Web系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。
系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。