2023年7月10日发(作者：)

500并发⼀台服务器的性能_你的系统如何⽀撑⾼并发？⾼并发系统各不相同。⽐如每秒百万并发的中间件系统、每⽇百亿请求的⽹关系统、瞬时每秒⼏⼗万请求的秒杀⼤促系统。他们在应对⾼并发的时候，因为系统各⾃特点的不同，所以应对架构都是不⼀样的。另外，⽐如电商平台中的订单系统、商品系统、库存系统，在⾼并发场景下的架构设计也是不同的，因为背后的业务场景什么的都不⼀样。最简单的系统架构假设刚刚开始你的系统就部署在⼀台机器上，背后就连接了⼀台数据库，数据库部署在⼀台服务器上。我们甚⾄可以再现实点，给个例⼦，你的系统部署的机器是 4 核 8G，数据库服务器是 16 核 32G。此时假设你的系统⽤户量总共就 10 万，⽤户量很少，⽇活⽤户按照不同系统的场景有区别，我们取⼀个较为客观的⽐例，10% 吧，每天活跃的⽤户就 1 万。按照 28 法则，每天⾼峰期算它 4 个⼩时，⾼峰期活跃的⽤户占⽐达到 80%，就是 8000 ⼈活跃在 4 ⼩时内。然后每个⼈对你的系统发起的请求，我们算他每天是 20 次吧。那么⾼峰期 8000 ⼈发起的请求也才 16 万次，平均到 4 ⼩时内的每秒(14400 秒)，每秒也就 10 次请求。好吧！完全跟⾼并发搭不上边，对不对？然后系统层⾯每秒是 10 次请求，对数据库的调⽤每次请求都会有好⼏次数据库操作的，⽐如做做 crud 之类的。那么我们取⼀个⼀次请求对应 3 次数据库请求吧，那这样的话，数据库层每秒也就 30 次请求，对不对？按照这台数据库服务器的配置，⽀撑是绝对没问题的。上述描述的系统，⽤⼀张图表⽰，就是下⾯这样：系统集群化部署假设此时你的⽤户数开始快速增长，⽐如注册⽤户量增长了 50 倍，上升到了 500 万。此时⽇活⽤户是 50 万，⾼峰期对系统每秒请求是 500/s。然后对数据库的每秒请求数量是 1500/s，这个时候会怎么样呢？按照上述的机器配置来说，如果你的系统内处理的是较为复杂的⼀些业务逻辑，是那种重业务逻辑的系统的话，是⽐较耗费 CPU 的。此时，4 核 8G 的机器每秒请求达到 500/s 的时候，很可能你会发现你的机器 CPU 负载较⾼了。然后数据库层⾯，以上述的配置⽽⾔，其实基本上 1500/s 的⾼峰请求压⼒的话，还算可以接受。这个主要是要观察数据库所在机器的磁盘负载、⽹络负载、CPU 负载、内存负载，按照我们的线上经验⽽⾔，那个配置的数据库在1500/s 请求压⼒下是没问题的。所以此时你需要做的⼀个事情，⾸先就是要⽀持你的系统集群化部署。你可以在前⾯挂⼀个负载均衡层，把请求均匀打到系统层⾯，让系统可以⽤多台机器集群化⽀撑更⾼的并发压⼒。⽐如说这⾥假设给系统增加部署⼀台机器，那么每台机器就只有 250/s 的请求了。这样⼀来，两台机器的 CPU 负载都会明显降低，这个初步的“⾼并发”不就先 cover 住了吗？要是连这个都不做，那单台机器负载越来越⾼的时候，极端情况下是可能出现机器上部署的系统⽆法有⾜够的资源响应请求了，然后出现请求卡死，甚⾄系统宕机之类的问题。所以，简单⼩结，第⼀步要做的：添加负载均衡层，将请求均匀打到系统层。系统层采⽤集群化部署多台机器，扛住初步的并发压⼒。此时的架构图变成下⾯的样⼦：数据库分库分表 + 读写分离假设此时⽤户量继续增长，达到了 1000 万注册⽤户，然后每天⽇活⽤户是 100 万。那么此时对系统层⾯的请求量会达到每秒 1000/s，系统层⾯，你可以继续通过集群化的⽅式来扩容，反正前⾯的负载均衡层会均匀分散流量过去的。但是，这时数据库层⾯接受的请求量会达到 3000/s，这个就有点问题了。此时数据库层⾯的并发请求翻了⼀倍，你⼀定会发现线上的数据库负载越来越⾼。每次到了⾼峰期，磁盘 IO、⽹络 IO、内存消耗、CPU 负载的压⼒都会很⾼，⼤家很担⼼数据库服务器能否抗住。没错，⼀般来说，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述我们举例的那个配置，不要超过 3000/s。因为数据库压⼒过⼤，⾸先⼀个问题就是⾼峰期系统性能可能会降低，因为数据库负载过⾼对性能会有影响。另外⼀个，压⼒过⼤把你的数据库给搞挂了怎么办？所以此时你必须得对系统做分库分表 + 读写分离，也就是把⼀个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写⼊请求的。然后每个主库都挂载⾄少⼀个从库，由从库来承载读请求。此时假设对数据库层⾯的读写并发是 3000/s，其中写并发占到了 1000/s，读并发占到了 2000/s。那么⼀旦分库分表之后，采⽤两台数据库服务器上部署主库来⽀撑写请求，每台服务器承载的写并发就是 500/s。每台主库挂载⼀个服务器部署从库，那么 2 个从库每个从库⽀撑的读并发就是 1000/s。简单总结，并发量继续增长时，我们就需要 focus 在数据库层⾯：分库分表、读写分离。此时的架构图如下所⽰：缓存集群引⼊接着就好办了，如果你的注册⽤户量越来越⼤，此时你可以不停的加机器，⽐如说系统层⾯不停加机器，就可以承载更⾼的并发请求。然后数据库层⾯如果写⼊并发越来越⾼，就扩容加数据库服务器，通过分库分表是可以⽀持扩容机器的，如果数据库层⾯的读并发越来越⾼，就扩容加更多的从库。但是这⾥有⼀个很⼤的问题：数据库其实本⾝不是⽤来承载⾼并发请求的，所以通常来说，数据库单机每秒承载的并发就在⼏千的数量级，⽽且数据库使⽤的机器都是⽐较⾼配置，⽐较昂贵的机器，成本很⾼。如果你就是简单的不停的加机器，其实是不对的。所以在⾼并发架构⾥通常都有缓存这个环节，缓存系统的设计就是为了承载⾼并发⽽⽣。所以单机承载的并发量都在每秒⼏万，甚⾄每秒数⼗万，对⾼并发的承载能⼒⽐数据库系统要⾼出⼀到两个数量级。所以你完全可以根据系统的业务特性，对那种写少读多的请求，引⼊缓存集群。具体来说，就是在写数据库的时候同时写⼀份数据到缓存集群⾥，然后⽤缓存集群来承载⼤部分的读请求。这样的话，通过缓存集群，就可以⽤更少的机器资源承载更⾼的并发。⽐如说上⾯那个图⾥，读请求⽬前是每秒 2000/s，两个从库各⾃抗了 1000/s 读请求，但是其中可能每秒 1800 次的读请求都是可以直接读缓存⾥的不怎么变化的数据的。那么此时你⼀旦引⼊缓存集群，就可以抗下来这 1800/s 读请求，落到数据库层⾯的读请求就 200/s。同样，给⼤家来⼀张架构图，⼀起来感受⼀下：按照上述架构，它的好处是什么呢？可能未来你的系统读请求每秒都⼏万次了，但是可能 80%~90% 都是通过缓存集群来读的，⽽缓存集群⾥的机器可能单机每秒都可以⽀撑⼏万读请求，所以耗费机器资源很少，可能就两三台机器就够了。你要是换成是数据库来试⼀下，可能就要不停的加从库到 10 台、20 台机器才能抗住每秒⼏万的读并发，那个成本是极⾼的。好了，我们再来简单⼩结，承载⾼并发需要考虑的第三个点：不要盲⽬进⾏数据库扩容，数据库服务器成本昂贵，且本⾝就不是⽤来承载⾼并发的。针对写少读多的请求，引⼊缓存集群，⽤缓存集群抗住⼤量的读请求。引⼊消息中间件集群接着再来看看数据库写这块的压⼒，其实是跟读类似的。假如说你所有写请求全部都落地数据库的主库层，当然是没问题的，但是写压⼒要是越来越⼤了呢？⽐如每秒要写⼏万条数据，此时难道也是不停的给主库加机器吗？可以当然也可以，但是同理，你耗费的机器资源是很⼤的，这个就是数据库系统的特点所决定的。相同的资源下，数据库系统太重太复杂，所以并发承载能⼒就在⼏千/s的量级，所以此时你需要引⼊别的⼀些技术。⽐如说消息中间件技术，也就是 MQ 集群，它可以⾮常好的做写请求异步化处理，实现削峰填⾕的效果。假如说，你现在每秒是 1000/s 次写请求，其中⽐如 500 次请求是必须请求过来⽴马写⼊数据库中的，但是另外 500 次写请求是可以允许异步化等待个⼏⼗秒，甚⾄⼏分钟后才落⼊数据库内的。那么此时你完全可以引⼊消息中间件集群，把允许异步化的每秒 500 次请求写⼊ MQ，然后基于 MQ 做⼀个削峰填⾕。⽐如就以平稳的 100/s 的速度消费出来，然后落⼊数据库中即可，此时就会⼤幅度降低数据库的写⼊压⼒。此时，架构图变成了下⾯这样：⼤家看上⾯的架构图，⾸先消息中间件系统本⾝也是为⾼并发⽽⽣，所以通常单机都是⽀撑⼏万甚⾄⼗万级的并发请求的。所以，它本⾝也跟缓存系统⼀样，可以⽤很少的资源⽀撑很⾼的并发请求，⽤它来⽀撑部分允许异步化的⾼并发写⼊是没问题的，⽐使⽤数据库直接⽀撑那部分⾼并发请求要减少很多的机器使⽤量。⽽且经过消息中间件的削峰填⾕之后，⽐如就⽤稳定的 100/s 的速度写数据库，那么数据库层⾯接收的写请求压⼒，不就成了 500/s +100/s = 600/s 了么？⼤家看看，是不是发现减轻了数据库的压⼒？到⽬前为⽌，通过下⾯的⼿段，我们已经可以让系统架构尽可能⽤最⼩的机器资源抗住了最⼤的请求压⼒，减轻了数据库的负担：系统集群化。数据库层⾯的分库分表+读写分离。针对读多写少的请求，引⼊缓存集群。针对⾼写⼊的压⼒，引⼊消息中间件集群。初步来说，简单的⼀个⾼并发系统的阐述是说完了。但是，故事到这⾥还远远没有结束。⾸先，⾼并发这个话题本⾝是⾮常复杂的，远远不是⼀些⽂章可以说的清楚的，它的本质就在于，真实的⽀撑复杂业务场景的⾼并发系统架构其实是⾮常复杂的。⽐如说每秒百万并发的中间件系统、每⽇百亿请求的⽹关系统、瞬时每秒⼏⼗万请求的秒杀⼤促系统、⽀撑⼏亿⽤户的⼤规模⾼并发电商平台架构，等等。为了⽀撑⾼并发请求，在系统架构的设计时，会结合具体的业务场景和特点，设计出各种复杂的架构，这需要⼤量底层技术⽀撑，需要精妙的架构和机制设计的能⼒。最终，各种复杂系统呈现出来的架构复杂度会远远超出⼤部分没接触过的同学的想象。但是那么复杂的系统架构，通过⼀些⽂章是很难说的清楚⾥⾯的各种细节以及落地⽣产的过程的。其次，⾼并发这话题本⾝包含的内容也远远不⽌本⽂说的这么⼏个 topic：分库分表、缓存、消息。⼀个完整⽽复杂的⾼并发系统架构中，⼀定会包含：各种复杂的⾃研基础架构系统。各种精妙的架构设计(⽐如热点缓存架构设计、多优先级⾼吞吐 MQ 架构设计、系统全链路并发性能优化设计，等等)。还有各种复杂系统组合⽽成的⾼并发架构整体技术⽅案。还有 NoSQL(Elasticsearch 等)/负载均衡/Web 服务器等相关技术。所以⼤家切记要对技术保持敬畏之⼼，这些东西都很难通过⼀些⽂章来表述清楚。最后，真正在⽣产落地的时候，⾼并发场景下你的系统会出现⼤量的技术问题。⽐如说消息中间件吞吐量上不去需要优化、磁盘写压⼒过⼤性能太差、内存消耗过⼤容易撑爆、分库分表中间件不知道为什么丢了数据，等等。