高并发架构到底是怎样的
2021-09-17 11:05:14 
阿炯
本文为CSDN博主「Java大将军」的原创文章，作者从系统设计的各个角度来思考，提出问题和一些可行的解决办法，这是本文的精髓所在；也为架构提供一个纲领性的参考。
前言
我们知道，高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳得被系统中的服务和组件处理。
来做个简单的比喻吧：从古至今，长江和黄河流域水患不断，远古时期，大禹曾拓宽河道，清除淤沙让流水更加顺畅；都江堰作为史上最成功的的治水案例之一，用引流将岷江之水分流到多个支流中，以分担水流压力；水坝通过建造水库将水引入水库先存储起来，然后再想办法把水库中的水缓缓地排出去，以此提高下游的抗洪能力。
"秒杀活动"、"抢红包"、"微博热搜"、"12306抢票"、"共享单车拉新"等都是高并发的典型业务场景，那么如何解决这些业务场景背后的难点问题呢?
秒杀系统中QPS达到10万/s时如何定位并解决业务瓶颈?
明星婚恋话题不断引爆微博热搜如何确保系统不宕机?
共享单车充值活动，如何保证不超卖?
......
同一时间、海量用户的高频访问对任何平台都是难题，但可喜的是，虽然业务场景不同，设计和优化的思想却是万变不离其宗。如果你掌握了高并发系统设计的核心技术点(缓存、池化、异步化、负载均衡、队列、降级熔断等)，深化成自己的知识体系，解决这些业务问题将不在话下，应对自如。
高并发系统设计脑图
那么，我们怎么去学习、提高我们的高并发系统设计的能力呢？
说明：文章限于篇幅，故只做部分展示，完整的《高并发系统设计》文档小编已经整理好了，正在学习高并发或者想把这份文档当做练习题复习一下的朋友，需要获取这份《高并发系统设计》学习笔记的小伙伴请到源站去领取。
Step ①：基础
首先，我们需要了解一下知识点：
高并发系统：它的通用设计方法是什么
架构分层：我们为什么一定要这么做？
系统设计目标(一)：如何提升系统性能？
系统设计目标(二)：系统怎样做到高可用？
系统设计目标(三)：如何让系统易于扩展？
Step ②：数据库
在第一步中，我已经从宏观的角度带你了解了高并发系统设计的基础知识，你已经知晓了，我们系统设计的目的是为了获得更好的性能、更高的可用性，以及更强的系统扩展能力。
那么在这一步，我们正式进入演进篇，我会再从局部出发，带你逐一了解完成这些目标会使用到的一些方法，这些方法会针对性地解决高并发系统设计中出现的问题。
池化技术：如何减少频繁创建数据库连接的性能损耗？
数据库优化方案(一)：查询请求增加时，如何做主从分离？
数据库优化方案(二)：写入数据量增加时，如何实现分库分表？
发号器：如何保证分库分表后ID的全局唯一性？
NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？
Step ③：缓存
通过前面数据库篇的学习，你已经了解了在高并发大流量下，数据库层的演进过程以及库表设计上的考虑点。
那么我将从缓存定义、缓存分类和缓存优势劣势三个方面全方位带你掌握缓存的设计思想和理念，带你针对性地掌握使用缓存的正确方式，以便在实际工作中能够更好地使用缓存提升整体系统的性能。
缓存：数据库成为瓶颈后，动态数据的查询要如何加速？
缓存的使用姿势(一)：如何选择缓存的读写策略？
缓存的使用姿势(二)：缓存如何做到高可用？
缓存的使用姿势(三)：缓存穿透了怎么办？
CDN：静态资源如何加速？
Stpe ④：消息队列
1秒钟之内，有1万个数据库连接同时达到，系统的数据库濒临崩溃，寻找能够应对如此高并发的写请求方案迫在眉睫。这时你想到了消息队列。这里我会从以下几个问题去带大家学习如何使用消息队列解决秒杀场景下的问题：
消息队列：秒杀时如何处理每秒上万次的下单请求？
消息投递：如何保证消息仅仅被消费一次？
消息队列：如何降低消息队列系统中消息的延迟？
Step ⑤：分布式服务
通过前面几个篇章的内容，你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。但是有一个问题一直萦绕在你的心里：究竟是什么促使我们将一体化架构拆分成微服务化架构？是不是说系统的整体 QPS 到了 1 万，或者到了 2 万，就一定要做微服务化拆分呢？
下面将从以下几个点去讲解，为什么我们要用分布式服务？它好在哪里、如何实现？
系统架构：每秒1万次请求的系统要做服务化拆分吗？
微服务架构：微服务化后，系统架构要如何改造？
RPC框架：10万QPS下如何实现毫秒级的服务调用？
注册中心：分布式系统如何寻址？
分布式Trace：横跨几十个分布式组件的慢请求要如何排查？
负载均衡：怎样提升系统的横向扩展能力？
API网关：系统的门面要如何做呢？
多机房部署：跨地域的分布式系统如何做？
Service Mesh：如何屏蔽服务化系统的服务治理细节？
Step ⑥：维护
要想快速地发现和定位业务系统中出现的问题，必须搭建一套完善的服务端监控体系。正所谓“道路千万条，监控第一条，监控不到位，领导两行泪”。不过，在搭建的过程中，你的团队又陷入了困境：
首先，监控的指标要如何选择呢？
采集这些指标可以有哪些方法和途径呢？
指标采集到之后又要如何处理和展示呢？
这些问题，一环扣一环，关乎着系统的稳定性和可用性，通过完成一下这些，我就带你解决这些问题，搭建一套服务端监控体系。
给系统加上眼睛：服务端监控要怎么做？
应用性能管理：用户的使用体验应该如何监控？
压力测试：怎样设计全链路压力测试平台？
配置管理：成千上万的配置项要如何管理？
降级熔断：如何屏蔽非核心系统故障的影响？
流量控制：高并发系统中我们如何操纵流量？
Step ⑦：实战
在前面，我分别从数据库、缓存、消息队列和分布式服务化的角度，带你了解了面对高并发的时候要如何保证系统的高性能、高可用和高可扩展。其中虽然有大量的例子辅助你理解理论知识，但是没有一个完整的实例帮你把知识串起来。所以，为了将我们提及的知识落地，在实战篇中会以微博为背景，用两个完整的案例带你从实践的角度应对高并发大流量的冲击，期望给你一个更加具体的感性认识，为你在实现类似系统的时候提供一些思路：
计数系统设计(一)：面对海量数据的计数器要如何做？
计数系统设计(二)：50万QPS下如何设计未读数系统？
信息流设计(一)：通用信息流系统的推模式要如何做？
信息流设计(二)：通用信息流系统的拉模式要如何做？
总结
通过以上七个步骤，我想你应该能够从中获益良多，掌握高并发系统设计的精髓！
从基础出发，由浅入深，从七个方面(基础+数据库+缓存+消息队列+分布式服务+维护+实战)去带领大家去学习高并发系统设计！
先带你建立对高并发系统设计的直观理解，再以最简单架构逐步演进到支撑百万、千万并发的分布式架构为案例，带你解决这个过程中遇到的痛点问题，提升业务处理能力，真正完成一次系统演进，最后结合实战优化整体设计思路。
5 个高并发场景优化的衡量指标
分享自《【高并发】性能优化有哪些衡量指标需要注意什么？》，作者：冰河。
本节讲述在做性能优化相关工作的经验、以及对于性能优化工作的一些理论的理解，比如：性能优化的衡量指标，期间需要注意的问题等。
衡量指标
对于性能优化来说，衡量的指标有很多，大体上可以分为：性能指标、响应时间、并发量、秒开率和正确性等。我们可以使用下图来表示这些衡量指标。
接下来就分别说明下这些衡量指标。
性能指标
性能指标又可以包含：吞吐量和响应速度。我们平时所说的 QPS、TPS 和 HPS 等，就可以归结为吞吐量。有很多人可能对于 QPS、TPS 和 HPS 等不太了解，先来说下这几个字母的含义：
QPS 代表的是每秒的查询数量。
TPS 代表的是每秒事务的数量。
HPS 代表的是每秒的 HTTP 请求数量。
这些都是与吞吐量相关的衡量指标。
平时我们在做优化工作的时候，首先要明确需要优化的事项。比如：我们做的优化工作是要提高系统的吞吐量？还是要提升系统的响应速度呢？举一个具体点的例子：比如我们的程序中存在一些数据库或者缓存的批量操作，虽然在数据的读取上，响应速度下降了，但是我们优化的目标就是吞吐量，只要我们优化后系统的整体吞吐量明显上升了，那这也是提升了程序的性能。
所以说，优化性能不只是提升系统的响应速度。也并不是一味的优化吞吐量和优化响应速度，而是在吞吐量和响应速度之间找到一个平衡点，使用有限的服务器资源来更好的提升用户体验。
响应时间
对于响应时间来说，有两个非常重要的衡量指标。那就是：平均响应时间和百分位数。
（1）平均响应时间
通常，平均响应时间体现的是服务接口的平均处理能力。计算方式就是把所有的请求所耗费的时间加起来，然后除以请求的次数。举个简单的例子：比如：我们向一个网站发送了 5 次请求，每次请求所耗费的时间分别为：1ms，2ms，1ms，3ms，2ms，那么，平均响应时间就是（1+2+1+3+2）/ 5 = 1.8ms，所以，平均响应时间就是 1.8ms。
平均响应时间这个指标存在一个问题：如果在短时间内请求变得很慢，但很快过去了，此时使用平均响应时间就无法很好的体现出性能的波动问题。
（2）百分位数
百分位数就是我们在优化的时候，圈定一个时间范围，把每次请求的耗时加入一个列表中，然后按照从小到大的顺序将这些时间进行排序。这样，我们取出特定百分位的耗时，这个数字就是 TP 值。
TP 值表示的含义就是：超过 N% 的请求都在 X 时间内返回。比如 TP90 = 50ms，意思是超过 90th 的请求，都在 50ms 内返回。
百分位数这个指标也是很重要的，它反映的是应用接口的整体响应情况。一般会将百分位数分为 TP50、TP90、TP95、TP99、TP99.9 等多个段，对高百分位的值要求越高，对系统响应能力的稳定性要求越高。
并发量
指的是系统能够同时处理的请求数量，反映的是系统的负载能力。在对高并发系统进行优化的时候，往往也会在并发量上进行调优，调优方式也是多种多样的，目的就是提高系统同时处理请求的能力。总体来说，并发量这个指标理解起来还是比较简单的，就不做过多的描述了。
秒开率
主要针对的是前端网页或者移动端 APP 来说的，如果一个前端网页或者 APP 能够在 1 秒内很平滑的打开，尤其是首页的加载。此时，用户就会感到前端网页或者 APP 使用起来很顺畅，如果超过 3 秒甚至更长的时间，用户就有可能会直接退出前端网页或者 APP 不再使用。所以在高并发场景下优化程序，不只要对后端程序进行优化，对于前端和 APP 也是要进行优化的。
正确性
说的是无论我们以何种方式，何种手段对应用进行优化，优化后的交互数据结果必须是正确的。不能出现优化前性能比较低，数据正确，而优化后性能比较高，反而数据不正确的现象。
优化需要注意的问题
若非必要，一开始不要优化 (尤其是开发阶段)
有些优化准则已经过时，需要考虑当下的软硬件环境 (不要墨守成规)
不要过分强调某些系统级指标，如 cache 命中率，而应该聚焦性能瓶颈点
不盲从，测试、找到系统的性能瓶颈，再确定优化手段
注意权衡优化的成本和收益（有些优化可能需要现有架构做出调整、增加开发/运维成本）
优化的目标是用户体验、降低硬件成本（降低集群规模、不依赖单机高性能）
测试环境的优化手段未必对生产环境有效（优化需要针对真实情况）
前言
我们知道，高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳得被系统中的服务和组件处理。
来做个简单的比喻吧：从古至今，长江和黄河流域水患不断，远古时期，大禹曾拓宽河道，清除淤沙让流水更加顺畅；都江堰作为史上最成功的的治水案例之一，用引流将岷江之水分流到多个支流中，以分担水流压力；水坝通过建造水库将水引入水库先存储起来，然后再想办法把水库中的水缓缓地排出去，以此提高下游的抗洪能力。
"秒杀活动"、"抢红包"、"微博热搜"、"12306抢票"、"共享单车拉新"等都是高并发的典型业务场景，那么如何解决这些业务场景背后的难点问题呢?
秒杀系统中QPS达到10万/s时如何定位并解决业务瓶颈?
明星婚恋话题不断引爆微博热搜如何确保系统不宕机?
共享单车充值活动，如何保证不超卖?
......
同一时间、海量用户的高频访问对任何平台都是难题，但可喜的是，虽然业务场景不同，设计和优化的思想却是万变不离其宗。如果你掌握了高并发系统设计的核心技术点(缓存、池化、异步化、负载均衡、队列、降级熔断等)，深化成自己的知识体系，解决这些业务问题将不在话下，应对自如。
高并发系统设计脑图
那么，我们怎么去学习、提高我们的高并发系统设计的能力呢？
说明：文章限于篇幅，故只做部分展示，完整的《高并发系统设计》文档小编已经整理好了，正在学习高并发或者想把这份文档当做练习题复习一下的朋友，需要获取这份《高并发系统设计》学习笔记的小伙伴请到源站去领取。
Step ①：基础
首先，我们需要了解一下知识点：
高并发系统：它的通用设计方法是什么
架构分层：我们为什么一定要这么做？
系统设计目标(一)：如何提升系统性能？
系统设计目标(二)：系统怎样做到高可用？
系统设计目标(三)：如何让系统易于扩展？
Step ②：数据库
在第一步中，我已经从宏观的角度带你了解了高并发系统设计的基础知识，你已经知晓了，我们系统设计的目的是为了获得更好的性能、更高的可用性，以及更强的系统扩展能力。
那么在这一步，我们正式进入演进篇，我会再从局部出发，带你逐一了解完成这些目标会使用到的一些方法，这些方法会针对性地解决高并发系统设计中出现的问题。
池化技术：如何减少频繁创建数据库连接的性能损耗？
数据库优化方案(一)：查询请求增加时，如何做主从分离？
数据库优化方案(二)：写入数据量增加时，如何实现分库分表？
发号器：如何保证分库分表后ID的全局唯一性？
NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？
Step ③：缓存
通过前面数据库篇的学习，你已经了解了在高并发大流量下，数据库层的演进过程以及库表设计上的考虑点。
那么我将从缓存定义、缓存分类和缓存优势劣势三个方面全方位带你掌握缓存的设计思想和理念，带你针对性地掌握使用缓存的正确方式，以便在实际工作中能够更好地使用缓存提升整体系统的性能。
缓存：数据库成为瓶颈后，动态数据的查询要如何加速？
缓存的使用姿势(一)：如何选择缓存的读写策略？
缓存的使用姿势(二)：缓存如何做到高可用？
缓存的使用姿势(三)：缓存穿透了怎么办？
CDN：静态资源如何加速？
Stpe ④：消息队列
1秒钟之内，有1万个数据库连接同时达到，系统的数据库濒临崩溃，寻找能够应对如此高并发的写请求方案迫在眉睫。这时你想到了消息队列。这里我会从以下几个问题去带大家学习如何使用消息队列解决秒杀场景下的问题：
消息队列：秒杀时如何处理每秒上万次的下单请求？
消息投递：如何保证消息仅仅被消费一次？
消息队列：如何降低消息队列系统中消息的延迟？
Step ⑤：分布式服务
通过前面几个篇章的内容，你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。但是有一个问题一直萦绕在你的心里：究竟是什么促使我们将一体化架构拆分成微服务化架构？是不是说系统的整体 QPS 到了 1 万，或者到了 2 万，就一定要做微服务化拆分呢？
下面将从以下几个点去讲解，为什么我们要用分布式服务？它好在哪里、如何实现？
系统架构：每秒1万次请求的系统要做服务化拆分吗？
微服务架构：微服务化后，系统架构要如何改造？
RPC框架：10万QPS下如何实现毫秒级的服务调用？
注册中心：分布式系统如何寻址？
分布式Trace：横跨几十个分布式组件的慢请求要如何排查？
负载均衡：怎样提升系统的横向扩展能力？
API网关：系统的门面要如何做呢？
多机房部署：跨地域的分布式系统如何做？
Service Mesh：如何屏蔽服务化系统的服务治理细节？
Step ⑥：维护
要想快速地发现和定位业务系统中出现的问题，必须搭建一套完善的服务端监控体系。正所谓“道路千万条，监控第一条，监控不到位，领导两行泪”。不过，在搭建的过程中，你的团队又陷入了困境：
首先，监控的指标要如何选择呢？
采集这些指标可以有哪些方法和途径呢？
指标采集到之后又要如何处理和展示呢？
这些问题，一环扣一环，关乎着系统的稳定性和可用性，通过完成一下这些，我就带你解决这些问题，搭建一套服务端监控体系。
给系统加上眼睛：服务端监控要怎么做？
应用性能管理：用户的使用体验应该如何监控？
压力测试：怎样设计全链路压力测试平台？
配置管理：成千上万的配置项要如何管理？
降级熔断：如何屏蔽非核心系统故障的影响？
流量控制：高并发系统中我们如何操纵流量？
Step ⑦：实战
在前面，我分别从数据库、缓存、消息队列和分布式服务化的角度，带你了解了面对高并发的时候要如何保证系统的高性能、高可用和高可扩展。其中虽然有大量的例子辅助你理解理论知识，但是没有一个完整的实例帮你把知识串起来。所以，为了将我们提及的知识落地，在实战篇中会以微博为背景，用两个完整的案例带你从实践的角度应对高并发大流量的冲击，期望给你一个更加具体的感性认识，为你在实现类似系统的时候提供一些思路：
计数系统设计(一)：面对海量数据的计数器要如何做？
计数系统设计(二)：50万QPS下如何设计未读数系统？
信息流设计(一)：通用信息流系统的推模式要如何做？
信息流设计(二)：通用信息流系统的拉模式要如何做？
总结
通过以上七个步骤，我想你应该能够从中获益良多，掌握高并发系统设计的精髓！
从基础出发，由浅入深，从七个方面(基础+数据库+缓存+消息队列+分布式服务+维护+实战)去带领大家去学习高并发系统设计！
先带你建立对高并发系统设计的直观理解，再以最简单架构逐步演进到支撑百万、千万并发的分布式架构为案例，带你解决这个过程中遇到的痛点问题，提升业务处理能力，真正完成一次系统演进，最后结合实战优化整体设计思路。
5 个高并发场景优化的衡量指标
分享自《【高并发】性能优化有哪些衡量指标需要注意什么？》，作者：冰河。
本节讲述在做性能优化相关工作的经验、以及对于性能优化工作的一些理论的理解，比如：性能优化的衡量指标，期间需要注意的问题等。
衡量指标
对于性能优化来说，衡量的指标有很多，大体上可以分为：性能指标、响应时间、并发量、秒开率和正确性等。我们可以使用下图来表示这些衡量指标。
接下来就分别说明下这些衡量指标。
性能指标
性能指标又可以包含：吞吐量和响应速度。我们平时所说的 QPS、TPS 和 HPS 等，就可以归结为吞吐量。有很多人可能对于 QPS、TPS 和 HPS 等不太了解，先来说下这几个字母的含义：
QPS 代表的是每秒的查询数量。
TPS 代表的是每秒事务的数量。
HPS 代表的是每秒的 HTTP 请求数量。
这些都是与吞吐量相关的衡量指标。
平时我们在做优化工作的时候，首先要明确需要优化的事项。比如：我们做的优化工作是要提高系统的吞吐量？还是要提升系统的响应速度呢？举一个具体点的例子：比如我们的程序中存在一些数据库或者缓存的批量操作，虽然在数据的读取上，响应速度下降了，但是我们优化的目标就是吞吐量，只要我们优化后系统的整体吞吐量明显上升了，那这也是提升了程序的性能。
所以说，优化性能不只是提升系统的响应速度。也并不是一味的优化吞吐量和优化响应速度，而是在吞吐量和响应速度之间找到一个平衡点，使用有限的服务器资源来更好的提升用户体验。
响应时间
对于响应时间来说，有两个非常重要的衡量指标。那就是：平均响应时间和百分位数。
（1）平均响应时间
通常，平均响应时间体现的是服务接口的平均处理能力。计算方式就是把所有的请求所耗费的时间加起来，然后除以请求的次数。举个简单的例子：比如：我们向一个网站发送了 5 次请求，每次请求所耗费的时间分别为：1ms，2ms，1ms，3ms，2ms，那么，平均响应时间就是（1+2+1+3+2）/ 5 = 1.8ms，所以，平均响应时间就是 1.8ms。
平均响应时间这个指标存在一个问题：如果在短时间内请求变得很慢，但很快过去了，此时使用平均响应时间就无法很好的体现出性能的波动问题。
（2）百分位数
百分位数就是我们在优化的时候，圈定一个时间范围，把每次请求的耗时加入一个列表中，然后按照从小到大的顺序将这些时间进行排序。这样，我们取出特定百分位的耗时，这个数字就是 TP 值。
TP 值表示的含义就是：超过 N% 的请求都在 X 时间内返回。比如 TP90 = 50ms，意思是超过 90th 的请求，都在 50ms 内返回。
百分位数这个指标也是很重要的，它反映的是应用接口的整体响应情况。一般会将百分位数分为 TP50、TP90、TP95、TP99、TP99.9 等多个段，对高百分位的值要求越高，对系统响应能力的稳定性要求越高。
并发量
指的是系统能够同时处理的请求数量，反映的是系统的负载能力。在对高并发系统进行优化的时候，往往也会在并发量上进行调优，调优方式也是多种多样的，目的就是提高系统同时处理请求的能力。总体来说，并发量这个指标理解起来还是比较简单的，就不做过多的描述了。
秒开率
主要针对的是前端网页或者移动端 APP 来说的，如果一个前端网页或者 APP 能够在 1 秒内很平滑的打开，尤其是首页的加载。此时，用户就会感到前端网页或者 APP 使用起来很顺畅，如果超过 3 秒甚至更长的时间，用户就有可能会直接退出前端网页或者 APP 不再使用。所以在高并发场景下优化程序，不只要对后端程序进行优化，对于前端和 APP 也是要进行优化的。
正确性
说的是无论我们以何种方式，何种手段对应用进行优化，优化后的交互数据结果必须是正确的。不能出现优化前性能比较低，数据正确，而优化后性能比较高，反而数据不正确的现象。
优化需要注意的问题
若非必要，一开始不要优化 (尤其是开发阶段)
有些优化准则已经过时，需要考虑当下的软硬件环境 (不要墨守成规)
不要过分强调某些系统级指标，如 cache 命中率，而应该聚焦性能瓶颈点
不盲从，测试、找到系统的性能瓶颈，再确定优化手段
注意权衡优化的成本和收益（有些优化可能需要现有架构做出调整、增加开发/运维成本）
优化的目标是用户体验、降低硬件成本（降低集群规模、不依赖单机高性能）
测试环境的优化手段未必对生产环境有效（优化需要针对真实情况）