高并发网站一些记录

没做过不代表不能了解，只是记录下。

高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”

能缓存在用户电脑本地的，就不要让他去访问CDN。 能缓存CDN服务器上的，就不要让CDN去访问源（静态服务器）了。能访问静态服务器的，就不要去访问动态服务器。以此类推：能不访问数据库和存储就一定不要去访问数据库和存储。

第三层：cdn,页面静态化

第五层：数据库cache层，比如：memcache,memcachedb,tc等等。

第六层：数据库层，一般的不是超大站点都会用mysql主从结构

摘自：http://my.oschina.net/wzwitblog/blog/132777

当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。

Web负载均衡 

Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。



 

负载均衡的策略有很多，我们从简单的讲起哈。

1. HTTP重定向

2. 反向代理负载均衡

反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。



 

Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。

解决方案主要有两种：

配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。
将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

面对高并发大压力，在进行不同项目的架构设计时，您认为需要考虑哪些关键的问题？难题在哪些方面？需要使用什么样的产品或者方法来进行架构设计？不同项目间的区别有哪些？

陈伟伟：互联网的特点是大流量、高并发、高响应、高实时，而零售业的系统特点是高安全、高可靠和高依赖，打通通路需要复杂的过程。这些正是我会在活动中分享的重点，电商架构有四代：单一应用、垂直应用、分布式架构、服务治理。
单一应用，当网站流量很小时，只需要一个应用，就能将所有功能部署在一起，以减少部署节点和成本。其关键点为框架（MVC、IOC、ORM），采用Strusts2（velocity）+Spring+iBatis2结构；
垂直应用，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆分为互不相关的几个应用，来提升效率。关键点是Web Url和Cache。
分布式架构，当垂直应用越来越多，应用之间交互不可避免，以API的形式对外提供，并依赖其他系统。关键点是RPC。
服务治理，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，需要增加调度中心基于访问压力实时管理集群容量，提高集群利用率。关键点是服务治理（SOA）和资源调度。



如果简单用一两句话来总结：复杂的业务简单化，简单的业务精细化。

对架构师而言，什么样的能力最重要？如何来构建这样的能力？

陈伟伟：对于架构师，我个人觉的除了有过硬的技术，更需要一种精神，执着的冲劲去面对遇到的问题，最好能有刨根究底的精神。很很多同学遇到一些奇怪的问题的时候，怎么解决的都不知道，只是觉的好了，就万事大吉了，那么多年以后，你可能还在原地徘徊。此外，多读书，最好能读一些开源的项目的代码，深入的去了解它的原理。

摘自：http://www.csdn.net/article/2013-01-18/2813825-interview-womai-Architect-Manager