High concurrent systems are different. For example megabits per second concurrent middleware system, gateway system daily ten billion requests per second instantaneous spike big promotion system hundreds of thousands of requests.
When they deal with high concurrency, because of the different characteristics of each system, so deal with architecture it is not the same.
In addition, such electronic business platform in order system, merchandise system, inventory system architecture design in high concurrency scenarios are different, because the business behind the scenes of what is different.
The simplest system architecture
assume that your system is just beginning to be deployed on a machine behind it connected with a database, the database is deployed on a single server.
You may even want to be realistic, give an example, your system deployment machine is a 4-core 8G, the database server is a 16-core 32G.
At this time, assuming your system to a total of 100,000 subscribers, subscribers few, Nikkatsu user differentiated according to the situation of different systems, we take a more objective proportion, 10% of it, every day active users 10000.
28 in accordance with the law, it is considered the peak of the day four hours, the peak of active users accounting for 80%, that is 8,000 people active in 4 hours.
Then everyone on your system initiated the request, we counted 20 times a day he is right. Then the peak of the 8,000-initiated request also only 16 million times per second to average (14,400 seconds) within four hours, also 10 requests per second.
Ok! Complete with high concurrency take a share, right?
Then the system level is 10 times per second request, calls to the database for each request will have several database operations, such as doing the crud and the like.
So we take a first request corresponds to three times the database requests it, that this is the case, the database layer also 30 requests per second, right?
According to this configuration database server support is absolutely no problem. The system described above, with a view showing, this is the following:
image
System cluster deployment
, assuming that the number of users you begin rapid growth, such as the amount of registered users increased 50-fold, rising to 500 million.
At this point Nikkatsu 500,000 users, the peak of requests per second, the system is 500 / s. Then the database requests per second number is 1500 / s, this time what will happen?
According to the above machine configuration, if the processing within your system is more complex some business logic, business logic is a kind of heavy system, then, is a relatively time-consuming CPU.
At this point, 4-core 8G requests per second when the machine reach 500 / s, it is likely you will find that the higher the CPU load your machine.
Then the database level, in terms of the above-described arrangement, in fact, substantially peak 1500 / s requested pressure, then still acceptable.
This is mainly to observe the machine where the database disk load, network load, CPU load, memory load, in accordance with our online experience, the configuration database is no problem under pressure in 1500 / s request.
So now you need to do a thing, the first is to support your system cluster deployment.
You can hang in front of a load-balancing layer, the request hit a uniform system level, the system can use multiple clustered machines support higher concurrency pressure.
For example, the system is assumed here that the deployment of a machine, then each machine only 250 requests / s of the.
As a result, the two machines will significantly reduce the CPU load, this initial "high concurrency" is not on the first cover live it?
If even this is not done, when that single machine load higher and higher, in extreme cases is possible to deploy the system on the machine can not have enough resources to respond to the request, and the request appears stuck, even of system downtime problem class.
So simple summary, the first step:
- Adding a load balancing layer, layer system requests evenly hit.
- System layer using cluster deployment of multiple machines, Kang Zhu preliminary concurrent pressure.
image
数据库分库分表 + 读写分离
假设此时用户量继续增长，达到了 1000 万注册用户，然后每天日活用户是 100 万。
那么此时对系统层面的请求量会达到每秒 1000/s，系统层面，你可以继续通过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。
但是，这时数据库层面接受的请求量会达到 3000/s，这个就有点问题了。
此时数据库层面的并发请求翻了一倍，你一定会发现线上的数据库负载越来越高。
每次到了高峰期，磁盘 IO、网络 IO、内存消耗、CPU 负载的压力都会很高，大家很担心数据库服务器能否抗住。
没错，一般来说，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述我们举例的那个配置，不要超过 3000/s。
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。
另外一个，压力过大把你的数据库给搞挂了怎么办？
所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写入请求的。
然后每个主库都挂载至少一个从库，由从库来承载读请求。
此时假设对数据库层面的读写并发是 3000/s，其中写并发占到了 1000/s，读并发占到了 2000/s。
那么一旦分库分表之后，采用两台数据库服务器上部署主库来支撑写请求，每台服务器承载的写并发就是 500/s。
每台主库挂载一个服务器部署从库，那么 2 个从库每个从库支撑的读并发就是 1000/s。
简单总结，并发量继续增长时，我们就需要 focus 在数据库层面：分库分表、读写分离。
此时的架构图如下所示：
image
缓存集群引入
接着就好办了，如果你的注册用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。
然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。
但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。
如果你就是简单的不停的加机器，其实是不对的。
所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。
所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。
所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。
具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。
这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
比如说上面那个图里，读请求目前是每秒 2000/s，两个从库各自抗了 1000/s 读请求，但是其中可能每秒 1800 次的读请求都是可以直接读缓存里的不怎么变化的数据的。
那么此时你一旦引入缓存集群，就可以抗下来这 1800/s 读请求，落到数据库层面的读请求就 200/s。
同样，给大家来一张架构图，一起来感受一下：
image
按照上述架构，它的好处是什么呢？
可能未来你的系统读请求每秒都几万次了，但是可能 80%~90% 都是通过缓存集群来读的，而缓存集群里的机器可能单机每秒都可以支撑几万读请求，所以耗费机器资源很少，可能就两三台机器就够了。
你要是换成是数据库来试一下，可能就要不停的加从库到 10 台、20 台机器才能抗住每秒几万的读并发，那个成本是极高的。
好了，我们再来简单小结，承载高并发需要考虑的第三个点：
- 不要盲目进行数据库扩容，数据库服务器成本昂贵，且本身就不是用来承载高并发的。
- 针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求。
image
大家看上面的架构图，首先消息中间件系统本身也是为高并发而生，所以通常单机都是支撑几万甚至十万级的并发请求的。
所以，它本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是没问题的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。
而且经过消息中间件的削峰填谷之后，比如就用稳定的 100/s 的速度写数据库，那么数据库层面接收的写请求压力，不就成了 500/s + 100/s = 600/s 了么？
大家看看，是不是发现减轻了数据库的压力？到目前为止，通过下面的手段，我们已经可以让系统架构尽可能用最小的机器资源抗住了最大的请求压力，减轻了数据库的负担：
- 系统集群化。
- 数据库层面的分库分表+读写分离。
- 针对读多写少的请求，引入缓存集群。
- 针对高写入的压力，引入消息中间件集群。
- 各种复杂的自研基础架构系统。
- 各种精妙的架构设计（比如热点缓存架构设计、多优先级高吞吐 MQ 架构设计、系统全链路并发性能优化设计，等等）。
- 还有各种复杂系统组合而成的高并发架构整体技术方案。
- 还有 NoSQL（Elasticsearch 等）/负载均衡/Web 服务器等相关技术。