高并发架构设计思路

大活跃用户量，用户高聚集的业务场景,如：秒杀活动，定时领取红包等

一丶服务器架构

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

均衡负载，数据库需要主从集群，nosql缓存主从集群，静态文件cdn

1.服务器

    1.1均衡负载(如：nginx，阿里云SLB)

    1.2资源监控

    1.3分布式

2.数据库

    2.1主从分离，集群

    2.2DBA 表优化，索引优化等

    2.3分布式

3.nosql

    3.1redis、mongodb、memcache 主从分离，集群

4.cdn

    4.1html、css、js、image

二丶并发测试

高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。

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

2.1第三方服务:阿里云性能测试

2.2并发测试工具：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操作是一个事务)，缓存签到信息到redis，返回签到信息

注意：

1.这里会有并发情况下的逻辑问题，如：一天签到多次，发放多次积分给用户。

2.用户订单

这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据

用户访问订单列表，如果是第一页读缓存，如果不是读DB，计算出用户分布的key,redis hash中查找用户订单信息

如果查询到用户订单信息，返回订单信息

如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息

3.用户中心

计算出用户分布的key,redis hash中查找用户订单信息

如果查询到用户信息，返回用户信息

如果不存在进行用户DB查询，然后缓存redis，返回用户信息

4.其他业务

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

消息队列

秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求

场景：定时领取红包等

说明：

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

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

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

方案如：定时领取红包

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

一级缓存

高并发请求连接缓存服务器超出服务器能够接收的请求连接量，部分用户出现建立连接超时无法读取到数据的问题；

因此需要有个方案当高并发时候时候可以减少命中缓存服务器；

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

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

服务器架构图：

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

四丶静态化数据

高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。

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

1、流量优化  

防盗链处理(去除恶意请求)

2、前端优化

(1) 减少HTTP请求[将css,js等合并]

(2) 添加异步请求(先不将所有数据都展示给用户,用户触发某个事件,才会异步请求数据)

(3) 启用浏览器缓存和文件压缩

(4) CDN加速

(5) 建立独立的图片服务器(减少I/O)

3、服务端优化

(1) 页面静态化

(2) 并发处理

(3) 队列处理

4、数据库优化

(1) 数据库缓存

(2) 分库分表,分区

(3) 读写分离

(4) 负载均衡

5、web服务器优化

(1) nginx反向代理实现负载均衡

(2) lvs实现负载均衡

• 上一篇： Centos7上安装docker
• 下一篇： php选择排序算法