网站高并发及高并发架构详解

高并发是指在同一个时间点，有不少用户同时的访问URL地址，好比：淘宝的双11，双12，就会产生高并发,如贴吧的爆吧，就是恶意的高并发请求，也就是DDOS攻击，再屌丝点的说法就像玩撸啊撸被ADC暴击了同样,那伤害你懂得(若是你看懂了，这个说法说明是正在奔向人生巅峰的屌丝。

高并发会来带的后果

• 服务端：

致使站点服务器/DB服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不同的，好比：出现重复的数据记录，屡次添加了用户积分等。

• 用户角度：

尼玛，这么卡，老子来参加活动的，刷新了仍是这样，垃圾网站，不再来了。

• 个人经历：

在作公司产品网站的过程当中，常常会有这样的需求，好比什么搞个活动专题，抽奖，签到，搞个积分竞拍等等，若是没有考虑到高并发下的数据处理，那就Game Over了，很容易致使抽奖被多抽走，签到会发现一个用户有多条记录，签到一次得到了得到了多积分，等等，各类超出正常逻辑的现象，这就是作产品网站必须考虑的问题，由于这些都是面向大量用户的，而不是像作ERP管理系统，OA系统那样，只是面向员工。

下面我进行实例分析，简单粗暴，动态分析，纯属本人我的经验分享，若有说错，或者有更好的建议或者意见的请留言，你们一块儿成长。

并发下的数据处理：

经过表设计,如：记录表添加惟一约束，数据处理逻辑使用事物防止并发下的数据错乱问题

经过服务端锁进程防止包并发下的数据错乱问题

这里主要讲述的是在并发请求下的数据逻辑处理的接口,如何保证数据的一致性和完整性，这里的并发多是大量用户发起的，也可能攻击者经过并发工具发起的并发请求

如例子：经过表设计防止并发致使数据错乱

• 需求点

【签到功能】 一天一个用户只能签到一次，
签到成功后用户获取到一个积分

• 已知表

用户表，包含积分字段
高并发意淫分析(属于开发前的猜想)：
在高并发的状况下，会致使，一个用户签到记录会有多条，或者用户签到后不止加一积分。

• 个人设计

首先根据需求我会添加一张签到记录表，重点来了，这张表须要把用户惟一标识字段(ID,Token)和签到日期字段添加为惟一约束，或者惟一索引，这样就能够防止并发的时候插入重复用户的签到记录。而后再程序代码逻辑里，先执行签到数据的添加(这里能够防止并发，添加成功后再进行积分的添加，这样就能够防止重复的添加积分了。最后我仍是建议全部的数据操做都写在一个sql事务里面， 这样在添加失败，或者编辑用户积分失败的时候能够回滚数据。

如例子2（事务+经过更新锁 防止并发致使数据错乱 或者事物+Update的锁表机制）

• 需求点：

【抽奖功能】 抽奖一次消耗一个积分 抽奖中奖后编辑剩余奖品总数 剩余奖品总数为0，或者用户积分为0的时候没法进行抽奖

• 已知表:

用户表，包含积分字段 奖品表，包含奖品剩余数量字段

• 高并发意淫分析(属于开发前的猜想):

在高并发的状况下，会致使用户参与抽奖的时候积分被扣除，而奖品实际上已经被抽完了

• 个人设计:

在事物里，经过WITH (UPDLOCK) 锁住商品表，或者Update 表的奖品剩余数量和最后编辑时间字段，来把数据行锁住，而后进行用户积分的消耗，都完成后提交事物，失败就回滚。 这样就能够保证，只有可能存在一个操做在操做这件商品的数量，只有等到这个操做事物提交后，其余的操做这个商品行的事物才会继续执行。

如例子3（经过程序代码防止包并发下的数据错乱问题）

• 需求点：

【缓存数据到cache里】， 当缓存不存在的时候，从数据库中获取并保存在cache里，若是存在从cache里获取，天天10点必须更新一次，其余时间点缓存两个小时更新一次 到10点的时候，凡是打开页面的用户会自动刷新页面

• 问题点：

这里有个逻辑用户触发缓存的更新，用户刷新页面，当缓存存在的时候，会取到最后一次缓存更新时间，若是当前时间大于十点，而且最后缓存时间是10点前，则会从数据库中从新获取数据保存到cache中。 还有客户端页面会在10点时候用js发起页面的刷新，就是由于有这样的逻辑，致使10点的时候有不少并发请求同时过来，而后就会致使不少的sql查询操做，理想的逻辑是，只有一个请求会去数据库获取，其余都是从缓存中获取数据。(由于这个sql查询很耗服务器性能，因此致使在10点的时候，忽然间数据库服务器压力暴增)

• 解决问题：

C#经过 （锁）lock，在从数据读取到缓存的那段代码前面加上锁，这样在并发的状况下只会有一个请求是从数据库里获取数据，其余都是从缓存中获取。

访问量大的数据统计接口

• 需求： 用户行为数据统计接口，用来记录商品展现次数，用户经过点击图片，或者连接，或者其余方式进入到商品详情的行为次数
• 问题点：

这接口是给前端ajax使用，访问量会很大，一页面展现的时候就会有几十件商品的展现，滚动条滚到到页面显示商品的时候就会请求接口进行展现数据的统计，每次翻页又会加载几十件

• 意淫分析：

设想若是同时有1W个用户同时在线访问页面，一个次拉动滚动条屏幕页面展现10件商品，这样就会有10W个请求过来，服务端须要把请求数据入库。在实际线上环境可能还会超过这个请求量，若是不通过进行高并发设计处理，服务器分分钟给跪了。

• 解决问题：

咱们经过nodejs写了一个数据处理接口，把统计数据先存到redis的list里。(使用nodejs写接口的好处是，nodejs使用单线程异步事件机制，高并发处理能力强，不会由于数据逻辑处理问题致使服务器资源被占用而致使服务器宕机) 而后再使用nodejs写了一个脚本，脚本功能就是从redis里出列数据保存到mysql数据库中。这个脚本会一直运行，当redis没有数据须要同步到数据库中的时候，sleep，让在进行数据同步操做

高并发的下的服务器压力均衡，合理站点架设，DB部署

如下我所知道的：

1. 服务器代理nginx，作服务器的均衡负载，把压力均衡到多台服务器
2. 部署集群 mysql数据库， redis服务器，或者mongodb服务器，把一些经常使用的查询数据，而且不会常常的变化的数据保存到其余nosql DB服务器中，来减小数据库服务器的压力，加快数据的响应速度。
3. 数据缓存，Cache
4. 在高并发接口的设计中可使用具备高并发能力的编程语言去开发，如：nodejs 作web接口
5. 服务器部署，图片服务器分离，静态文件走CDN
6. DBA数据库的优化查询条件，索引优化
7. 消息存储机制，将数据添加到信息队列中(redis list)，而后再写工具去入库
8. 脚本合理控制请求，如，防止用户重复点击致使的ajax多余的请求，等等。

并发测试神器推荐

1. Apache JMeter
2. Microsoft Web Application Stress Tool
3. Visual Studio 性能负载

 

服务器架构

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。

一个能够支持高并发的服务少不了好的服务器架构，须要有均衡负载，数据库须要主从集群，nosql缓存须要主从集群，静态文件须要上传cdn，这些都是能让业务程序流畅运行的强大后盾。

服务器这块可能是须要运维人员来配合搭建，具体我就很少说了，点到为止。
大体须要用到的服务器架构以下：

• 服务器

1. 均衡负载(如：nginx，阿里云SLB)
2. 资源监控
3. 分布式

• 数据库

1. 主从分离，集群
2. DBA 表优化，索引优化，等
3. 分布式

• nosql

1. redis
   主从分离，集群
2. mongodb
   主从分离，集群
3. memcache
   主从分离，集群

• cdn

1. html
2. css
3. js
4. image

并发测试

高并发相关的业务，须要进行并发的测试，经过大量的数据分析评估出整个架构能够支撑的并发量。

测试高并发可使用第三方服务器或者本身测试服务器，利用测试工具进行并发请求测试，分析测试数据获得能够支撑并发数量的评估，这个能够做为一个预警参考，俗话说知己自彼百战不殆。

第三方服务:

• 阿里云性能测试

并发测试工具：

• Apache JMeter
• Visual Studio性能负载测试
• Microsoft Web Application Stress Tool

实战方案

通用方案

日用户流量大，可是比较分散，偶尔会有用户高聚的状况；

场景： 用户签到，用户中心，用户订单，等
服务器架构图：

说明：

场景中的这些业务基本是用户进入APP后会操做到的，除了活动日(618,双11，等)，这些业务的用户量都不会高汇集，同时这些业务相关的表都是大数据表，业务可能是查询操做，因此咱们须要减小用户直接命中DB的查询；优先查询缓存，若是缓存不存在，再进行DB查询，将查询结果缓存起来。

更新用户相关缓存须要分布式存储，好比使用用户ID进行hash分组，把用户分布到不一样的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。

方案如：

• 用户签到获取积分

1. 计算出用户分布的key,redis hash中查找用户今日签到信息
2. 若是查询到签到信息，返回签到信息
3. 若是没有查询到，DB查询今日是否签到过，若是有签到过，就把签到信息同步redis缓存。
4. 若是DB中也没有查询到今日的签到记录，就进行签到逻辑，操做DB添加今日签到记录，添加签到积分(这整个DB操做是一个事务)
5. 缓存签到信息到redis，返回签到信息
6. 注意这里会有并发状况下的逻辑问题，如：一天签到屡次，发放屡次积分给用户。

• 用户订单

1. 这里咱们只缓存用户第一页的订单信息，一页40条数据，用户通常也只会看第一页的订单数据
2. 用户访问订单列表，若是是第一页读缓存，若是不是读DB
3. 计算出用户分布的key,redis hash中查找用户订单信息
4. 若是查询到用户订单信息，返回订单信息
5. 若是不存在就进行DB查询第一页的订单数据，而后缓存redis，返回订单信息

• 用户中心

1. 计算出用户分布的key,redis hash中查找用户订单信息
2. 若是查询到用户信息，返回用户信息
3. 若是不存在进行用户DB查询，而后缓存redis，返回用户信息

• 其余业务

1. 上面例子可能是针对用户存储缓存，若是是公用的缓存数据须要注意一些问题，以下
2. 注意公用的缓存数据须要考虑并发下的可能会致使大量命中DB查询，可使用管理后台更新缓存，或者DB查询的锁住操做。
3. 个人博文[大话Redis进阶]对更新缓存问题和推荐方案的分享。

以上例子是一个相对简单的高并发架构，并发量不是很高的状况能够很好的支撑，可是随着业务的壮大，用户并发量增长，咱们的架构也会进行不断的优化和演变，好比对业务进行服务化，每一个服务有本身的并发架构，本身的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；

消息队列

秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求
场景：定时领取红包，等

服务器架构图：

说明：

场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，而后影响整个业务；

像这种不是只有查询的操做而且会有高并发的插入或者更新数据的业务，前面提到的通用方案就没法支撑，并发的时候都是直接命中DB；

设计这块业务的时候就会使用消息队列的，能够将参与用户的信息添加到消息队列中，而后再写个多线程程序去消耗队列，给队列中的用户发放红包；

方案如：

• 定时领取红包

1. 通常习惯使用 redis的 list
2. 当用户参与活动，将用户参与信息push到队列中
3. 而后写个多线程程序去pop数据，进行发放红包的业务
4. 这样能够支持高并发下的用户能够正常的参与活动，而且避免数据库服务器宕机的危险

附加：

经过消息队列能够作不少的服务。

如：定时短信发送服务，使用sset(sorted set)，发送时间戳做为排序依据，短信数据队列根据时间升序，而后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，若是超过就进行短信发送。

一级缓存

高并发请求链接缓存服务器超出服务器可以接收的请求链接量，部分用户出现创建链接超时没法读取到数据的问题；

所以须要有个方案当高并发时候时候能够减小命中缓存服务器；

这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，而且缓存的数据量要控制，不能过度的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存须要设置秒单位的过时时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可让数据的获取命中到一级缓存，而不用链接缓存nosql数据服务器，减小nosql数据服务器的压力

好比APP首屏商品数据接口，这些数据是公共的不会针对用户自定义，并且这些数据不会频繁的更新，像这种接口的请求量比较大就能够加入一级缓存；

服务器架构图：

合理的规范和使用nosql缓存数据库，根据业务拆分缓存数据库的集群，这样基本能够很好支持业务，一级缓存毕竟是使用站点服务器缓存因此仍是要善用。

静态化数据

高并发请求数据不变化的状况下若是能够不请求本身的服务器获取数据那就能够减小服务器的资源压力。

对于更新频繁度不高，而且数据容许短期内的延迟，能够经过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，若是没有获取到数据再从缓存，数据库中获取，当管理人员操做后台编辑数据再从新生成静态文件上传同步到CDN，这样在高并发的时候可使数据的获取命中在CDN服务器上。

CDN节点同步有必定的延迟性，因此找一个靠谱的CDN服务器商也很重要

其余方案

• 对于更新频繁度不高的数据，APP,PC浏览器，能够缓存数据到本地，而后每次请求接口的时候上传当前缓存数据的版本号，服务端接收到版本号判断版本号与最新数据版本号是否一致，若是不同就进行最新数据的查询并返回最新数据和最新版本号，若是同样就返回状态码告知数据已是最新。减小服务器压力：资源、带宽