前言
本章讲解高并发系统中常见概念及相关设计的方案，目的是让小伙伴都了解高并发系统中，每个环节所涉及到的相关概念。帮助大家更好地理解和掌握高并发系统中的场景及设计思想。
1. 常见高并发系统架构图（这里以秒杀系统为例）
上图中，架构比较简洁，下面将对这5层结构进行讲解
-
用户层：用户端的展现部分，主要涉及商品的相关信息及当前“秒杀”活动的信息
-
CDN层：缓存静态资源文件
-
负载均衡层：拦截请求及分发路由等
-
服务层：相关的逻辑处理
-
基础设施层：数据存储、大数据计算及消息推送相关操作
2. “秒杀”活动设计原则
业界总结出五大设计原则：
（1）数据应尽量少
在用户请求时，发送请求所传输的数据和服务端响应请求所传输的数据应尽可能少。因为，这些数据在网络中传输是需要时间的，消息体太大会影响传输效率。另外发起请求所传输的数据需要在服务端进行各种解析，例如Json的反序列化等。这些操作都会消耗CPU资源，所以减少传输的数据能有效提高CPU使用率。
减少数据的操作包括：
① 简化“秒杀”页面的大小，去掉一些不必要的页面装修；
② 能预热的数据尽量提前预热；
③ 在发送“秒杀”请求时，只带上最有用的信息；
④ 在服务端返回数据时，返回最简数据体；
另外，尽量少依赖外部服务，能“自己做”就“自己做”
（2）请求数应尽量少
在用户进入商品“秒杀”详情页时，浏览器会渲染各种额外的数据，如当前页面所关联的CSS、JavaScript文件、商品图片，以及页面Ajax发出请求所获取的数据等。这些额外的请求书应尽量少，因为浏览器每发送一次HTTP请求都会消耗一定的性能，特别是有些请求是串行的（如多个按顺序使用的Javascript文件）。
减少请求数的一个最常用的方案是：
① 将多个静态文件进行合并请求，即将多个CSS和JavaScript文件进行合并请求。在请求URL中，使用逗号做文件的分割。例如：https://xxx.com/active/1.js,2.js,3.js
② 这些静态文件在服务端还是独立存放的，只不过在服务端有一个解析此种URL的组件（如淘宝开发的nginx-http-concat），它会将解析出来的各个文件进行合并返回。
（3）请求路径应尽量短
请求路径可以被理解为“请求从用户端发出到响应数据回到用户端这中间的各个节点”，如浏览器、CDN、负载均衡器、Web容器等。请求每经过一个节点都需要建立一个TCP连接，所以节点离用户越近，则意味着路径越短，这样性能和体验就越好。
缩短请求路径的一般做法是：
① 将依赖性强的应用合并部署在一起，将RPC变成对应用内部方法的调用。
② 还可以使用多级缓存来缩短路径。
（4）尽量使用“异步化”
所谓“异步化”指的是：接收端接受用户的所有订单请求，并将这些请求直接丢进队列中；下单系统根据自身的实际处理情况，从队列中获取订单请求，并将其下发给订单中心生成真正的订单；同时，系统告知用户当前订单的处理进度，以及他们前面有多少人在等待。这样做可以解决“同步化处理不了峰值流量”的问题。
（5）避免单节点
单节点是所有系统设计中的大忌，因为单节点系统意味着系统的不稳定性较高，可能会出现不可用的情况，给企业带来直接的损失。在设计系统（特别是“秒杀”系统）时，必须保证系统的高可用。
章节拆分比较细，是为了让大家看的过程中，能够尽可能把内容接收进去，下章节讲解高并发系统的动静分离方案设计、热点数据处理、管控等介绍。
