什么是高井发系统

在每年的京东618及淘宝的双十一活动中，平台商家会有很多促销商品，而且商品价格对于用户来说吸引力巨大。面对这么巨大的流量，技术上如何保证这些商品不被“超卖”，同时还能给用户一个良好的购物体验?
12306网站在刚开始对外在线售票时，经常出现系统瘫痪的现象，后来经过系统优化，现在已经可以支持上千万人同时抢票且不损害系统本身。
这些技术的背后都离不开高并发技术,需要利用高并发技术的方法论及设计原则,再结合业务本身进行架构设计，以应对系统面临的流量冲击。

1.1 什么是高井发

高并发(High Concurrency),通常是指通过设计保证系统能够同时处理很多请求。即在同一个时间点，有很多的请求同时访问同一个接口。
高并发意味着大流量，需要运用技术手段去抵抗这种大流量的冲击，以达到系统能平稳处理流量且系统自身依然运行良好的目的。现如今，高并发场景无处不在，例如京东618、淘宝双十一、热门车次车票的开售，以及各种电商秒杀抢购活动等。
高并发是一种系统在运行过程中“短时间内遭遇大流量冲击”的情况。如果没有处理好，则很有可能造成系统吞吐量下降，响应变慢，从而影响用户体验，甚至可能造成系统彻底不可对外服务的情况发生。所以，需要优化系统(包括硬件、网络、应用、数据库等)来达到高并发的要求。

1.2 高井发系统有哪些关键指标

在设计一个系统或在对已有系统进行性能评估时，需要具备相应的参考指标，然后基于这些参考指标对系统进行针对性的优化，使得系统更健壮,以及具备更高的性能来看看高并发系统都需要关注哪些关键指标。

响应时间(Response Time)、吞吐量(Throughput)、每秒请求数(QPS)、每秒事务数(TPS)、访问量 (PV)、独立访客(UV) 、网络流量

1.2.1 响应时间

是指从第一次发出请求到收到系统完整响应数据所需的时间。响应时间是反映系统性能的重要指标，直接反映了系统响应的快慢。
从用户角度出发，响应时间决定着用户的体验感:应时间越长，用户体验感越差，就会造成用户的流失;呃应时间越短，用户体验感越好，有助于提高用户留存率。

从系统本身的角度出发,响应时间决定着系统的性能问题:响应时间越短，系统性能越高，即能更好地处理业务;响应时间越长，系统性能越差，甚至可能会丢失相关请求或者出现系统不可用，从而影响公司业务。

1.2.2 吞吐量

指单位时间内系统所处理的用户请求数。
从业务角度看，吞吐量可以用“请求数/秒”“人数天”或“处理业务数小时”等单位来衡量。
从网络角度看，吞吐量可以用“字节数/秒”来衡量对于互联网应用来说，吞吐量能够直接反映系统的负载能力。
采用不同方式表达的吞吐量，可以说明不同层次的问题，如:采用“请求数/秒”方式的吞吐量，则说明瓶颈主要来源于应用服务器和应用本身;采用“字节数/秒”方式的吞吐量,则可以说明瓶颈主要来源于网络基础设施、服务器架构和应用服务器约束等。
在没有遇到性能瓶颈时，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算吞吐量:

F=VXR/T
其中，F表示吞吐量，VU 表示虚拟用户个数，R表示个虚拟用户发出的请求数T表示性能测试所用的时间

1.2.3 每秒请求数(QPS)

OPS指服务器在一秒内共处理了多少个请求，主要用来表示“读”请求。
在系统上线前，一般怎么预估系统 OPS呢?绝大部分系统在白天的请求量都较大，所以，这里假设以白天来计算OPS。依据二八原则，80%的流量是在20%的时间段内产生的。
例如，现在每天有 5000000 个请求，预估 OPS=(5000000X0.8)/(12X60X60X0.2)=462。即当前系统每天平均 OPS 为 462。当然，为了保险起见，再预留个 20%左右也是可以的。一般还需要计算当天最高 OPS,这样对系统的掌控力度更强。
系统最高OPS可以通过系统平均 OPS的倍数计算出来。例如，分析业务得到最高 OPS 大概是平均 OPS的2倍，则当前系统峰值 OPS为924 左右。
在预估出OPS后，用“峰值 OPS/单台机器最高可承受的OPS”就能计算出需要部署多少台服务器。即:

机器数=峰值 QPS/单台机器最高可承受的QPS

单台最高可承受的QPS 可以通过压测来得出。假设单台机器压测得出最高可承受的OPS为100则所需要的机器数量为:924/10010台。

1.2.4 每秒事务数 (TPS)

TPS即服务器每秒处理的事务数。TPS包括以下3个过程:
(1)客户端请求服务端。
(2)在服务端内部进行业务逻辑处理
(3)服务端响应客户端。

一个事务包括“客户机向服务器发送请求+服务器响应的过程。在客户机发送请求时开始计时，在客户机收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

TPS与OPS区别是什么呢?OPS类似于TPS但也有不同之处。例如:当用户访问完整页面时，请求+响应的整个过程就是一个 TPS;但是，这一次完整的页面请求可能产生多次服务器的请求，这些请求应计入 OPS。

假设访问一个页面时会请求服务器 3次这样的一次访问会产生1个TPS、3个QPS

1.2.5 访问量 (PV)

PV(Page View)指页面浏览量。用户每对网站中的1个网页访问1次均被记录1次。用户对同一个页面的多次访问被累计记录。PV 是评价网站流量最常用的指标之。

1.2.6 独立访客 (UV)

UV(Unique Visitor)指访问某个站点或点击某个链接的不同IP地址数。

在同一天内，UV只记录第一次进入网站的具有独立P地址的访问者，在同一天内访问者再次访问该网站则不计数。独立IP 地址访问者相当于携带了“身份证”进入网站,它能反映在一定时间内有多少独立客户端进行了访问。
一个UV可以有很多个PV,一个PV也可以对应一个IP。例如，对网站访问一次，则网站的V就加 1;这一次访问了该网站的两个页面，则网站的 PV加2;对其中-个网页又刷新了一次，则PV再加 1

1.2.7 网络流量

因为受限于带宽，所以网络流量(也简称流量)是并发情况的一个重要指标，主要涉及以下两面。
流入流量:从外部访问服务器所消耗的流量。

流出流量:服务器对外响应的流量

1.3 为什么学习高并发系统

一般在企业中所搭建的系统并非天生就支持高并发而是随着业务的发展而逐渐地被优化和重慢慢地支持言并发的。

高并发系统设计有一个原则: 不能脱离业务。开发者平时需要多储备这方面的知识。

1.3.1 提升自身及企业核心竞争力
在谈及高并发场景的技术方案时，一般程序员会有两种想法:
一、觉得自己所在的公司规模并不大，业务也很清晰和单一，且没遇到过大流量的冲击，所以觉得没必要去学习高并发系统设计。
二、公司业务的确会遇到大流量的冲击，也会有很多高并发的场景，但总是依赖架构师或更高级的工程师，觉得这些由他们去解决就好，和自己关系不是太大，所以，学习高并发系统设计的兴趣也不高。
上面两种情况，归根究底是自身并没有意识到学习高并发系统设计的重要性，也是因为未接触过所以望而却步，最终无法掌握一套自己的高并发系统设计方法论。
对于大部分小型企业或初创型企业来说，其技术架构比较单一，程序员一般只需要关注业务逻辑本身即可。例如，在电商系统的下单流程中，一分钟只有几单或者十几单，这时的确只需要关注订单的业务本身即可:在下单时先查询数据库库存是否充足;如果充足,则直接创建订单成功后锁定库存，然后进入支付流程，如下所示。

但是，如果公司需要在节日进行“秒杀”活动，每利的下单请求数达到10000个，这10000个请求同时对数据库查询库存，库存系统能不能承受住? 如果能承受住则需要同时生成10000个订单，数据库能不能承受住?如果都不能承受那需要我们怎么做才能解决这些问题?所以，一旦业务稍微复杂起来，我们之前的设计可能会遇到很大问题，如果我们事先没有足够的技术沉淀，则可能会给公司带来巨大损失。

1.32在面试中脱颖而出

在面试中，常遇到面试官问这样的问题:你们的系统并发量多大?有没有设计高并发系统的经验?对于大流量的冲击，你是怎么优化系统的?
如今在各大企业招聘时，用人部门并不是简单地考虑应聘者能否胜任公司的业务,而是看应聘者能否给公司带来更大的价值。所以，如果我们只懂得CURD 操作是远远不够的，很容易被淘汰。
如果我们事先通过大量的学习及实践,掌握了高并发系统设计，不仅能在面试中脱颖而出，而且在入职后也能给公司带来很高的价值。
针对缓存的使用，不愿学习高并发知识的求职者的回答可能只是缓存的简单使用，只知道缓存是用来缓存数据的。当被问到高并发场景中的缓存“穿透”、缓存“雪崩”及缓存一致性时，就不知道如何回答了，更别提多级缓存了。但是，如果你学习了高并发系统设计，就能很轻松地回答了。
再比如，针对消息中间件的使用，普通应聘者只知道它是用来削峰填谷或解耦的，但不知道消息中间件的原理，也不知道高并发场景下消息中间件的消息一致性、消息顺序性，以及如何解决消息不可达。
诸如此类的问题,都需要通过不断学习高并发系统设计，才能从面试中脱颗而出。后面会以实战的方式一一为大家讲解这方面的知识。