1.1 什么是高并发？
- 高并发（High Concurrency），通常是指通过设计保证系统能够同时处理很多请求。即在同一个时间点，有很多的请求同时访问同一个接口。
- 高并发意味着大流量，需要运用技术手段去抵抗这种大流量的冲击，以达到系统能平稳处理流量且系统自身依然运行良好的目的。
- 高并发是一种系统在运行过程中“短时间内遭遇大流量冲击”的情况。如果没有处理好，则很有可能造成系统吞吐率下降，响应变慢，从而影响用户体验，甚至可能造成系统彻底不可对外服务的情况发生。所以需要优化系统（包括硬件、网络、应用、数据库等）来达到高并发的要求。
1.2 高并发系统有哪些关键指标？
1. 响应时间（Response Time）：从第一次发出请求到收到系统完整响应数据数据所需时间。直接反映系统响应的快慢。
2. 吞吐量（Throughput）：单位时间内系统所处理的用户请求数。直接反映系统的负载能力。
- 采用“请求数/秒”方式的吞吐量，瓶颈主要来源于应用服务器和应用本身。
- 采用“字节数/秒”方式的吞吐量，瓶颈主要来源于网络基础设施、服务器架构和服务器约束等。
3. 每秒请求数（QPS）：服务器在一秒内共处理了多少个请求，主要用于表示“读”请求。
4. 每秒事务数（TPS）：即服务器每秒处理的事务数。（一个事务包括“客户机向服务器发送请求 + 服务器响应”的过程）
5. 访问量（PV）：用户每对网站中的1个网页访问1次被记录1次
6. 独立访客（UV）：访问某个站点或点击某个链接的不同IP地址数。（即在同一天内，UV只记录第一次进入网站的具有独立IP地址的访问者，在同一天内访问者再次访问该网站则不计数。）
1.3 对比单体系统、分布式系统和微服务系统
1.3.1 单体系统之痛：
单体系统即一个应用程序，所有的业务代码都在这一个应用程序中，所有的表也都在一个数据库中，所涉及的相关文件都在同一个服务器上。
单体系统面临的问题：
- 需要频繁地合并代码分支，影响项目的迭代进度
- 多人协作耦合度高，测试效率低下
- 开发节奏混乱，代码冲突频繁
- 代码模块层次越来越复杂，业务边界变得不清晰
- 项目越来越大，技术架构升级变得困难
单体系统一般采用三层架构：
（1）用户展示层：负责用户端的展现和体验
（2）业务层：负责业务的所有逻辑操作
（3）数据访问层：负责操作数据库，如读写数据库等
单体分层架构的弊端：
- 从水平方向来看，的确降低了业务的深度复杂性。
- 从垂直方向来看，单体的业务边界不够清晰，因为在各层之间会进行网状的调用，比如，用户展现层的某个模块会调用业务层的多个模块。（甚至所有模块）；业务层的模块同样会调用数据访问层的多个模块等。
1.3.2 高并发系统之分布式架构
分布式架构是指，将相同或者相关的应用放在多台计算机上运行，以达到分布式计算机的目的。（将一个系统拆分为多个独立的应用，然后它们相互协作，通过对方提供的API进行交互，组成一个整体，共同完成任务）
分布式架构局限性：
- 开发者在开发应用时，需要考虑当前应用的API模块。因为如果业务需要更改了相关底层逻辑，则这种修改会影响API模块，所以需要对API模块也进行对应逻辑的修改，否则已经在调用的服务会出现调用错误，影响线上产品。
- 外部的服务需要依据自己的业务向服务提供方提出相应的小需求。服务提供方可能只是改动了API模块，但是从整体来说则需要测试并重新部署一遍，影响服务的稳定性。
1.3.3 高并发系统之微服务架构
微服务是一种流行的架构设计风格：
- 微服务是由单一应用构成的小型服务，拥有自己的进程与轻量化处理。
- 微服务依据业务功能设计，以全自动的方式部署，与其他微服务使用HTTP API 进行通信。
- 微服务会使用最小规模的集中管理技术，例如Docker
- 微服务可以使用不同的编程语言和数据库。
微服务系统就是将复杂的单体系统中的模块按照某种规则进行拆分，这些被拆分出来的模块被独立部署在相对较小的服务器集群上。独立部署的模块彼此之间使用远程调用的方式来完成整个业务的处理。这些被独立部署的模块就是微服务，而这样的应用架构就是微服务架构。
微服务架构特征：
（1）通过服务实现组件化
（2）围绕业务能力来组织开发团队
（3）去中心化管理
（4）去中心化数据存储
（5）基础设施自动化
（6）充分考虑故障
微服务架构的问题：
（1）增加了复杂度
（2）服务间的通信会变得复杂
（3）在落地微服务时，微服务边界的划分增加了实现的复杂度
（4）保持数据一致性非常复杂
（5）对运维团队和开发团队都提出了更高的要求
（6）开发流程复杂