高并发的解决方案[转载]

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接和本声明。
本文连接：https://blog.csdn.net/sanyaoxu_2/article/details/78992113

1.应用和静态资源分离
刚开始的时候应用和静态资源是保存在一块儿的，当并发量达到必定程度的时候就须要将静态资源保存到专门的服务器中，静态资源主要包括图片、视频、js、css和一些资源文件等，这些文件由于没有状态因此分离比较简单，直接存放到响应的服务器就能够了，通常会使用专门的域名去访问。
经过不一样的域名可让浏览器直接访问资源服务器而不须要再访问应用服务器了。架构图以下：

 

2.页面缓存
页面缓存是将应用生成的页面缓存起来，这样就不须要每次都生成页面了，从而能够节省大量的CPU资源，若是将缓存的页面放到内存中速度就更快了。若是使用Nginx服务器就可使用它自带的缓存功能，固然也可使用专门的Squid 服务器。页面缓存的默认失效机制一班都是按缓存时间处理的，固然也能够在修改数据以后手动让相应的缓存失效。
页面缓存主要是使用在数据不多发生变化的页面，可是不少页面是大部分数据都不多发生变化，而其中不多一部分数据变化频率却很是高，好比说一个显示文章的页面，正常来讲彻底能够静态化，可是若是文章后面有“顶”和“踩”的功能并且显示的有响应的数量，这个数据的变化频率就比较高了，这就会影响静态化。这个问题能够用先生成静态页面而后使用Ajax来读取并修改响应的数据，这样就能够一箭双雕来，既可使用页面缓存也能够实时显示一些变化频率高的数据来。

其实你们都知道，效率最高、消耗最小的就是纯静态化的html页面，因此咱们尽量使咱们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。可是对于大量内容而且频繁更新的网站，咱们没法所有手动去挨个实现，因而出现了咱们常见的信息发布系统CMS，像咱们常访问的各个门户站点的新闻频道，甚至他们的其余频道，都是经过信息发布系统来管理和实现的，信息发布系统能够实现最简单的信息录入自动生成静态页面，还能具有频道管理、权限管理、自动抓取等功能，对于一个大型网站来讲，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来讲，尽量的静态化也是提升性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再从新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询可是内容更新很小的应用，能够考虑使用html静态化来实现，好比论坛中论坛的公用设置信息，这些信息目前的主流论坛均可以进行后台管理而且存储再数据库中，这些信息其实大量被前台程序调用，可是更新频率很小，能够考虑将这部份内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

3.集群与分布式
集群是每台服务器都具备相同的功能，处理请求时调用那台服务器均可以，主要起分流做用。

分布式是将不一样的业务放到不一样的服务器中，处理一个请求可能须要用到多台服务器，这样就能够提升一个请求的处理速度，并且集群和分布式也能够同时使用。

集群有两个方式：一种是在静态资源集群。另外一种是应用程序集群。静态资源集群比较简单。应用程序集群在处理过程当中最核心的问题就是Session 同步问题。

Session 同步有两种处理方式：一种是在Session 发生变化后自动同步到其余服务器，另外一种就是用个程序统一管理Session。全部集群的服务器都使用同一个Session，Tomcat 默认使用就是第一种方式，经过简单的配置就能够实现，第二种方式可使用专门的服务器安装Mencached等高效的缓存程序统一来管理session，而后再应用程序中经过重写Request并覆盖getSession 方法来获取制定服务器中的Session。

对于集群来讲还有一个核心的问题就是负载均衡，也就是接收到一个请求后具体分配到那个服务器去处理的问题，这个问题能够经过软件处理也可使用专门的硬件（如：F5）解决。

 

4. 反向代理
反向代理指的是客户端直接访问的服务器并不真正提供服务，它从别的服务器获取资源而后将结果返回给用户。

图：

 

4.1 反向代理服务器和代理服务器的区别
代理服务器的做用是代我门获取想要的资源而后将结果返回给咱们，所要获取的资源是我门主动告诉代理服务器的，好比，我门想访问Facebook，可是直接访问不了，这时就可让代理服务器访问，而后将结果返回给咱们。

反向代理服务器是我门正常访问一台服务器的时候，服务器本身去调用了别的服务器资源并将结果返回给咱们，我门本身并不知道。

代理服务器是咱们主动使用的，是为咱们服务的，他不须要有本身的域名；反向代理服务器是服务器本身试用的，我门并不知道，它有本身的域名，我门访问它和访问正常的网址没有任何区别。

反向代理服务器主要有三个做用：
1. 能够做为前端服务器跟实际处理请求的服务器集成；
2. 能够作负载均衡
3. 转发请求，好比说能够将不一样类型的资源请求转发到不一样的服务器去处理。

5. CDN
cdn实际上是一种特殊的集群页面缓存服务器，他和普通集群的多台页面缓存服务器相比，主要是它存放的位置和分配请求的方式有点特殊。CDN 服务器是分布在全国各地的，当接收到用户请求后会将请求分配到最合适的CDN服务器节点获取数据。好比联通的用户分配到联通的节点，上海的用户分配到上海的节点。

CDN的每一个节点其实就是一个页面缓存服务器，若是没有请求资源的缓存就会从主服务器获取，不然直接返回缓存的页面。

CDN分配请求（负载均衡）的方式是用专门的CDN域名解析服务器在解析域名的时候就分配好的。通常的作法是在ISP哪里试用CNAME将域名解析到一个特定的域名，而后再将解析到的那个域名用专门的CDN服务器解析道相应的CDN节点。如图。

 

第二步访问CDN的DNS服务器是应为CNAME记录的目标域名使用NS记录指向了CDN的DNS服务器。CDN的每一个节点可能也是集群了多台服务器。

6. 底层的优化
前面说的全部都是架构都是创建在最前面介绍的基础结构之上的。不少地方都须要经过网络传输数据，若是能够加快网络传输的速度，那将会让整个系统获得改善。

 

7.数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快没法知足应用，因而咱们须要使用数据库集群或者库表散列。

在数据库集群方面，不少数据库都有本身的解决方案，Oracle、Sybase等都有很好的方案，经常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什么样的DB，就参考相应的解决方案来实施便可。

上面提到的数据库集群因为在架构、成本、扩张性方面都会受到所采用DB类型的限制，因而咱们须要从应用程序的角度来考虑改善系统架构，库表散列是经常使用而且最有效的解决方案。咱们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不一样的模块对应不一样的数据库或者表，再按照必定的策略对某个页面或者功能进行更小的数据库散列，好比用户表，按照用户ID进行表散列，这样就可以低成本的提高系统的性能而且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，而后对帖子、用户按照板块和ID进行散列数据库和表，最终能够在配置文件中进行简单的配置便能让系统随时增长一台低成本的数据库进来补充系统性能。

8. 小结
网站架构的整个演变过程主要是围绕大数据和高并发这两个问题展开的，解决方案主要分为使用缓存和多资源两种类型。多资源主要指多存储（包括多内存）、多CPU和多网络，对于多资源来讲又能够分为单个资源处理一个完整的请求和多个资源合做处理一个请求两种类型，如多存储和多CPU中的集群和分布式，多网络中的CDN和静态资源分离。理解了整个思路以后就抓住了架构演变的本质，并且本身可能还能够设计出更好的架构。

 

其它简单总结：

首先，我认为解决问题以前首先要有清晰的思路，若是只是用来别人的解决方案那也只能是拿来主义，没有真正理解，没有作到触类旁通。

海量数据和高并发常常被连在一块说事儿，虽然他们彻底是两回事儿。海量数据纯指的是数据库的海量数据，而并发指的却包括数据库和服务器的高访问量。

那么问题来了，既然是数据库的数据量大，那怎么办呢？要想解决问题，首先要知道问题是什么！！！那么海量数据会给我带来什么样的问题呢？

海量数据带来的问题无非就是增删改查的问题，除了以外还能有啥问题呢？总不能是带来安全问题吧（打脸一，还真有多是安全问题）

1 数据库访问缓慢

2 插入更新缓慢，这个问题只能经过分库分表解决

要解决数据库访问缓慢的问题还有几种方法，既然访问数据库慢的话，在逻辑容许的状况下能够不访问数据库呢？

1 使用缓存

2 使用页面静态化

既然不访问数据库逃不过去了，那咱们就对数据库进行优化

3 优化数据库（包含的内容很是多，好比参数配置，索引优化，sql优化等等）

4 分离数据库中活跃的数据

5 读写分离

6 批量读取和延迟修改；

7 使用搜索引擎搜索数据库中的数据；

8 使用NoSQL和Hadoop等技术；

9 进行业务的拆分；

 

高并发的解决方案

其实这个问题必须结合上面的海量数据来讨论，什么状况下会出现高并发呢？必定是平时访问量就比较大的状况，那么平时访问量比较大相应的数据存储也就愈来愈多，这都是相辅相成的，固然也有个例，好比刚需，好比12306，这里的高并发相比于它的数据来讲已经不算海量了。那么平时访问量大如何解决呢？由于这里牵扯到服务器和数据库的问题，因此要从这两方面来进行优化

1 增长web服务器数量，也就是作集群，作负载均衡。既然一台服务器没法完成任务，那就多用几台，几台不够用机房

 在通向第二种解决方法以前，还有没有除了数据库服务器以外能作的一些优化手段呢？固然有

1.1 页面缓存

1.2 cdn

1.3 反向代理

1.4 应用程序和静态资源分离（好比专供下载的资源单独放在一块儿，给这台服务器提供很高的带宽资源）

2 增长数据库服务器数量，一样作集群，作负载均衡。

 

 

海量数据的解决方案

1 使用缓存

好多事情都是相辅相成的，相比来讲使用缓存更可能是用来解决高并发问题的，由于海量数据致使了访问的缓慢，容易形成高并发问题的严重性，又由于数据库通常是web访问的瓶颈，因此咱们在业务逻辑容许的状况下尽可能先避免操做数据库，因而，就有了缓存。将必要的数据存放在内存中，而没必要每次都去数据库中读取形成没必要要的性能浪费和加快访问速度---这就是缓存带来的好处。那使用缓存以及选用管理缓存软件时应该注意些什么东西呢？

2 页面静态化---不想解释，还有什么值得去解释呢？

3 数据库优化

3.1 数据库表结构涉及

3.2 数据类型的选用

3.3 sql优化

3.4 索引优化

3.5 配置优化

须要注意的地方实在太多，应该做为单独的一章拿出来说

4 分离数据库中的活跃数据

为何要分离呢？说一个我实际环境中遇到的问题吧！有一个表只有10几个字段，表有130万条数据，但大小已经到了5G的数据，这自己是不太合理的，这么少的数据占用了太多的数据，说明其中有些字段存储了大量的字符串（好比说文章内容等），每次检索这个表时大部分是用不到这些大字段内容的，但却须要耗时比较长，产生不少的慢日志。这时咱们能够考虑将表进行垂直切分，将活跃数据分离开来，这样能大大加快访问速度

5 读写分离

 

 

相关网址http://blog.csdn.net/u012373815/article/details/71435926

http://blog.csdn.net/u014723529/article/details/41892001

————————————————版权声明：本文为CSDN博主「_从头再来_」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。原文连接：https://blog.csdn.net/sanyaoxu_2/article/details/78992113