Foreword
In fact, the so-called high concurrency, if you want to understand the problem does, in fact, you have to start from the root causes of high concurrency, why have high concurrency? Why high concurrency very fast hardware?
Said a little plain, very simple, because the beginning of the system are connected to the database, but the database to know when to support concurrent two or three thousand per second, basically finished soon. So I have said many companies, the beginning of the dry, technology is relatively low, the result of business development too fast, sometimes the system could not carry the pressure hung up.
Of course, hung up, why not hang? If your database instantly carry 5000/8000 per second, or even thousands of concurrent, will be down, such as mysql because it simply did not carry such a high concurrency.
So why high concurrency regressed? Because now more and more people use the Internet, many app, website, system load is high concurrent requests, the peak may be complicated by several thousand per second, normal. What if two-eleven and the like, complicated by the tens of thousands to hundreds of thousands per second are possible.
So so high concurrency, coupled with already so complicated business, a quick play? Really powerful, it must be playing in complex business systems in high concurrency architecture of people, but you do not, then I tell you about how you should answer this question:
It can be divided into the following 6:00:
1. System Split
2. Cache
3.MQ
4. A sub-library sub-table
The separate read and write
6.ElasticSearch
Split system
A system into multiple subsystems, with dubbo Laigao. Each system then even a database, a library so already, now multiple databases, can not carry it high concurrency.
Cache
Cache, have to use the cache. Most of the high concurrency scenarios, reading and writing are less, then you can write in a database and cache, then read when the cache does not have to walk a lot. After all, people redis easily tens of thousands of concurrent single. So you can think about your project, those who read the scene carrying the main request, how to resist high concurrency with cache.
MQ
MQ, have to use MQ. You may still appear high concurrent write a scene, such as a business operating in dozens of databases to engage in frequent, additions and deletions additions and deletions, crazy. That high concurrency definitely hang out your system, if you use to carry redis write it certainly will not do, people are cached, LRU data at any time was up, the data format is also very simple, no transaction support. So that had to use mysql with mysql ah.
那你咋办？用 MQ 吧，大量的写请求灌入 MQ 里，排队慢慢玩儿，后边系统消费后慢慢写，控制在 mysql 承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。MQ 单机抗几万并发也是 ok 的，这个之前还特意说过。
分库分表
分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 sql 跑的性能。
读写分离
读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。
ElasticSearch
Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以考虑用 es 来承载。
欢迎大家关注我的公种浩【程序员追风】，文章都会在里面更新，整理的资料也会放在里面。
上面的 6 点，基本就是高并发系统肯定要干的一些事儿，大家可以仔细结合之前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要注意哪些问题，之前都讲过了，你都可以阐述阐述，表明你对这块是有点积累的。
说句实话，毕竟你真正厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？其实实际上在真正的复杂的业务系统里，做高并发要远远比上面提到的点要复杂几十倍到上百倍。
You need to consider: what needs to be sub-library sub-table, which does not require sub-library sub-table, single table with a single library sub-library sub-table how to join, what data should go into the cache, which can put data Kangzhu high concurrency after the request, you need to complete the analysis of a complex business system, and then step by step to join the transformation of the system architecture of high concurrency, this process is very complex, once done once and well, you're in the market It will be very popular.
In fact, most of the company's real value, not that you have some technical high concurrency related to some basic knowledge of architecture, architecture, RocketMQ, Kafka, Redis, Elasticsearch, high concurrency this one, you know, can only It is a second-class talent. Of a complex distributed systems hundreds of thousands of lines of code, step by step, architecture, design and practice of architecture is too high concurrency people, this experience is valuable.
At last
Welcome to share with everyone, like the point of a praise yo remember the article, thanks for the support!