会出现高并发架构，主要运用了哪些技术

　　高并发主要是由于网站PV访问量大，单台服务器涌承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个访问会被发送到哪台服务器，我们采取负载均衡策略，常见的技术有LVS，由于网站中有大量的静态页面，所以采用缓存服务器和反向代理技术，包括HAPROXY，REDIS,数据库可以采用数据库集群，进行读写分离，缓解数据库压力。等等。

1、程序和数据库部署在同一台服务器上2多学习一些相关的书籍比如：构建高性能Web站点，大规模Web服务开发技术构建可扩展的Web站点，Web容量规划的技术，分布式数据库系统及其应用。掌握其原理和结构。

优雅降级是指网站为了应付突然爆发的访问高峰，主动关闭部分功能，释放部分系统资源，保证网站核心功能正常访问的一个手段。淘宝每年一次的双十一促销活动就属于突然爆发的非常规访问高峰，淘宝的工程师每年都会关闭一部分非核心功能，如评价、确认收货等功能，保证交易功能的正常进行。

网站在流动计算基础之上实现自动优雅降级，是网站柔性架构的理想状态：监控系统实时监控所有服务器的运行状况，根据监控参数判断应用访问负载情况，如果发现部分应用负载过高，而部分应用负载过低，就会适当卸载低负载应用部分服务器，重新安装启动部分高负载应用，使应用负载总体均衡，如果所有应用负载都很高，而且负载压力还在继续增加，就会自动关闭部分非重要功能，保证核心功能正常运行。

提供几种供你思路：

1、网站页面静态化。静态化的页面为html(htm等)不需要web服务器重新加载项解析，只需要生成一次，以后每次都直接下载到客户端，效率高很多。

2、将网站的web服务器、数据库服务器、和文件服务器分开。通过将服务器专业化分工，以提高网站访问速度。因为和文件在下载的时候无论是IIS、Apache等服务器都会有很大压力。

3、设置专门的数据缓存服务器。将大量数据放到缓存数据区，在访问量少得时候存入数据，减少连接直接操作数据库的开销。

4、数据库集群、库表散列。大型网站在面对大量访问的时候，会显现数据库的瓶颈，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列来分散压力。

5、镜像。镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。

6、负载均衡。负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

7、最新：CDN加速技术。什么是CDN？CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。

一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。

1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、服务器分离大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃。在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群、库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表

京东活动系统 是一个可在线编辑、实时编辑更新和发布新活动，并对外提供页面访问服务的系统。其高时效性、灵活性等特征，极受青睐，已发展成京东几个重要流量入口之一。近几次大促，系统所承载的pv已经达到数亿级。随着京东业务的高速发展，京东活动系统的压力会越来越大。急需要一个更高效，稳定的系统架构，来支持业务的高速发展。本文主要对活动页面浏览方面的性能，进行探讨。

活动页面浏览性能提升的难点：

1 活动与活动之间差异很大，不像商品页有固定的模式。每个页面能抽取的公共部分有限，可复用性差。

2 活动页面内容多样，业务繁多。依赖大量外部业务接口，数据很难做到闭环。外部接口的性能，以及稳定性，严重制约了活动页的渲染速度、稳定性。

经过多年在该系统下的开发实践，提出“页面渲染、浏览异步化”的思想，并以此为指导，对该系统进行架构升级改造。通过近几个月的运行，各方面性能都有显著提升。在分享"新架构"之前，先看看我们现有web系统的架构现状。

以京东活动系统架构的演变为例，这里没有画出具体的业务逻辑，只是简单的描述下架构：

2第二步，一般是在消耗性能的地方加缓存，这里对部分查库操作加redis缓存

3对页面进行整页redis缓存：由于活动页面内容繁多，渲染一次页面的成本是很高。这里可以考虑把渲染好的活动内容整页缓存起来，下次请求到来时，如果缓存中有值，直接获取缓存返回。

以上是系统应用服务层面架构演进的，简单示意。为了减少应用服务器的压力，可以在应用服务器前面，加cdn和nginx的proxy_caxhe，降低回源率。

4整体架构（老）

除了前3步讲的“浏览服务”，老架构还做了其他两个大的优化：“接口服务”、静态服务

1访问请求，首先到达浏览服务，把整个页面框架返回给浏览器（有cdn、nginx、redis等各级缓存）。

2对于实时数据（如秒杀）、个性化数据（如登陆、个人坐标），采用前端实时接口调用，前端接口服务。

3静态服务：静态资源分离，所有静态js、css访问静态服务。

要点：浏览服务、接口服务分离。页面固定不变部分走浏览服务，实时变化、个性化采用前端接口服务实现。

接口服务：分两类，直接读redis缓存、调用外部接口。这里可以对直接读redis的接口采用nginx+lua进行优化（ openresty ），不做详细讲解。 本次分享主要对“浏览服务”架构

在讲新架构之前先看看新老架构下的新能对比

击穿cdn缓存、nginx缓存，回源到应用服务器的流量大约为20%-40%之间，这里的性能对比，只针对回源到应用服务器的部分。

2015双十一， 浏览方法tp99如下：（物理机）

Tp99  1000ms左右，且抖动幅度很大，内存使用近70%，cpu 45%左右。

1000ms内没有缓存，有阻塞甚至挂掉的风险。

2新架构浏览服务新能

本次2016 618采用新架构支持，浏览tp99如下（分app端活动和pc端活动）：

移动活动浏览tp99稳定在8ms, pc活动浏览tp99 稳定在15ms左右。全天几乎一条直线，没有性能抖动。

新架构支持，服务器（docker）cpu性能如下

cpu消耗一直平稳在1%，几乎没有抖动。

对比结果：新架构tp99从1000ms降低到 15ms，cpu消耗从45%降低到1%，新架构性能得到质的提升。

why!!!

下面我们就来揭开新架构的面纱。

1  页面浏览，页面渲染 异步化

再来看之前的浏览服务架构，20%-40%的页面请求会重新渲染页面，渲染需要重新计算、查询、创建对象等导致 cpu、内存消耗增加，tp99性能下降。

如果能保证每次请求都能获取到redis整页缓存，这些性能问题就都不存在了。

即：页面浏览，与页面渲染 异步。

理想情况下，如果页面数据变动可以通过 手动触发渲染（页面发布新内容）、外部数据变化通过监听mq 自动触发渲染。

但是有些外部接口不支持mq、或者无法使用mq，比如活动页面置入的某个商品，这个商品名称变化。

为了解决这个问题，view工程每隔指定时间，向engine发起重新渲染请求-最新内容放入redis。下一次请求到来时即可获取到新内容。由于活动很多，也不能确定哪些活动在被访问，所以不建议使用timer。通过加一个缓存key来实现，处理逻辑如下：

好处就是，只对有访问的活动定时重新发起渲染。

  整理架构（不包含业务）：

 view工程职责 ：

  a直接从缓存或者硬盘中获取静态html返回，如果没有返回错误页面。（文件系统的存取性能比较低，超过   100ms级别，这里没有使用）

  b根据缓存key2是否过期，判断是否向engine重新发起渲染。（如果，你的项目外面接口都支持mq，这个      功能就不需要了）

  engine工程职责 ：渲染活动页面，把结果放到 硬盘、redis。

  publish工程、mq 职责 ：页面发生变化，向engine重新发起渲染。 具体的页面逻辑，这里不做讲解

Engine工程的工作 就是当页面内容发生变化时，重新渲染页面，并将整页内容放到redis，或者推送到硬盘。

View工程的工作，就是根据链接从redis中获取页面内容返回。

3view 工程架构 ( 硬盘  版)

两个版本对比

aRedis版

优点：接入简单、 性能好，尤其是在大量页面情况下，没有性能抖动 。单个docker tps达到 700。

缺点：严重依赖京东redis服务，如果redis服务出现问题，所有页面都无法访问。

b硬盘版

优点：不依赖任何其他外部服务，只要应用服务不挂、网络正常 就可以对外稳定服务。

在页面数量不大的情况下，性能优越。单个docker tps达到 2000。

缺点：在页面数据量大的情况下（系统的所有活动页有xx个G左右），磁盘io消耗增加（这里采用的java io，如果采用nginx+lua，io消耗应该会控制在10%以内）。

解决方案：

a 对所有页面访问和存储 采用url hash方式，所有页面均匀分配到各个应用服务器上。

b 采用nginx+lua  利用nginx的异步io，代替java io。

现在通过nginx+lua做应用服务，所具有的高并发处理能力、高性能、高稳定性已经越来越受青睐。通过上述讲解，view工程没有任何业务逻辑。可以很轻易的就可以用lua实现，从redis或者硬盘获取页面，实现更高效的web服务。如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java进阶qun：694549689，里面有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

1具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。

2在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。

3如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加。

通过测试对比，view工程读本地硬盘的速度，比读redis还要快（同一个页面，读redis是15ms，硬盘是8ms）。所以终极版架构我选择用硬盘，redis做备份，硬盘读不到时在读redis。

这里前置机的url hash是自己实现的逻辑，engine工程采用同样的规则推送到view服务器硬盘即可，具体逻辑这里不细讲。后面有时间再单独做一次分享。 

优点：具备硬盘版的全部优点，同时去掉tomcat，直接利用nginx高并发能力，以及io处理能力。各项性能、以及稳定性达到最优。

缺点：1、硬盘坏掉，影响访问。2方法监控，以及日志打印，需使用lua脚本重写。

无论是redis版、硬盘版、openresty+硬盘版，基础都是页面浏览与页面渲染异步化。

优势：

1、所有业务逻辑都剥离到engine工程，新view工程理论上永远无需上线。

2、灾备多样化（redis、硬盘、文件系统），且更加简单，外部接口或者服务出现问题后，切断engine工程渲染，不再更新redis和硬盘即可。

3、新view工程，与业务逻辑完全隔离，不依赖外部接口和服务，大促期间，即便外部接口出现新能问题，或者有外部服务挂掉，丝毫不影响view工程正常访问。

4、性能提升上百倍，从1000ms提升到10ms左右。详见前面的性能截图。

5、稳定性：只要view服务器的网络还正常，可以做到理论上用不挂机。

6、大幅度节省服务器资源，按此架构，4+20+30=54个docker足以支持10亿级pv。（4个nginx proxy_cache、20个view，30个engine）

 从事开发已有近10载，一直就像寄生虫一样吸取着网络上的资源。前段时间受“张开涛”大神所托，对活动系统新架构做了一次简单整理分享给大家，希望能给大家带来一丝帮助。第一次在网上做分享，难免有些没有考虑周全的地方，以后会慢慢的多分享一些自己的心得，大家一起成长。最后再来点心灵鸡汤。。。

理论上经验这个东西是学不来的

说一下我的例子

刚入行的时候,基本就是写了一些增删改查甚至session都不太理解

随着入行后,你会遇到各种各样的问题在解决问题的过程中,经验来了

简单说一下所谓大规模高并发访问的web架构吧

其实,对于大规模高并发不外乎两点,第一点是及时相应(尽可能优化io)第二点是数据安全

这两点控制的好,就没问题的所以,我们的架构也就围绕在这两点应运而生

第一点,为了尽可能提高应用的io吞吐量则需要我们把所有耗时的io操作尽可能的优化,比如全局使用很少更改的一些配置,则可以采用nosql来全局共享(注意,这里的全局是指服务器集群如果涉及到了大规模,肯定是多服务器的)在其次可以增加服务器缓存比如2秒钟从上一条的服务器读取配置,存到服务器级别以提高效率还有线程缓存如果业务复杂可能对一个请求需要查询多次数据,不变的,老规矩,放到线程缓存基本也就差不多了

第二点,因为应用不同,要考虑容错率这个部分优化,可以考虑分离业务,把必须要数据安全的业务逻辑提取出来,队列执行或者特殊处理

剩下的就是服务器部署与如何分配,比如多少台web服务器,数据库配置,内存服务器配置等

这只能是在实际项目和工作过程中来区别对待了