他们在应对高并发的时候，由于系统各自特点的不同，以是应对架构都是不一样的。
其余，比如电商平台中的订单系统、商品系统、库存系统，在高并发场景下的架构设计也是不同的，由于背后的业务场景什么的都不一样。
假设刚刚开始你的系统就支配在一台机器上，背后就连接了一台数据库，数据库支配在一台做事器上。
我们乃至可以再现实点，给个例子，你的系统支配的机器是 4 核 8G，数据库做事器是 16 核 32G。
此时假设你的系统用户量统共就 10 万，用户量很少，日活用户按照不同系统的场景有差异，我们取一个较为客不雅观的比例，10% 吧，每天生动的用户就 1 万。
按照 28 法则，每天高峰期算它 4 个小时，高峰期生动的用户占比达到 80%，便是 8000 人生动在 4 小时内。
然后每个人对你的系统发起的要求，我们算他每天是 20 次吧。那么高峰期 8000 人发起的要求也才 16 万次，均匀到 4 小时内的每秒（14400 秒），每秒也就 10 次要求。
好吧！
完备跟高并发搭不上边，对不对？
然后系统层面每秒是 10 次要求，对数据库的调用每次要求都会有好几次数据库操作的，比如做做 crud 之类的。
那么我们取一个一次要求对应 3 次数据库要求吧，那这样的话，数据库层每秒也就 30 次要求，对不对？
按照这台数据库做事器的配置，支撑是绝对没问题的。上述描述的系统，用一张图表示，便是下面这样：
数据库分库分表 + 读写分离
假设此时用户量连续增长，达到了 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 做事器等干系技能。以是大家牢记要对技能保持敬畏之心，这些东西都很难通过一些文章来表述清楚。
末了，真正在生产落地的时候，高并发场景下你的系统会涌现大量的技能问题。
比如说中间件吞吐量上不去须要优化、磁盘写压力过大性能太差、内存花费过大随意马虎撑爆、分库分表中间件不知道为什么丢了数据，等等。
