设计一个高并发系统

实现系统的高并发，主要从以下几个方面来考虑：

• 系统拆分
• 缓存
• MQ
• 分库分表
• 读写分离
• ElasticSearch

1、系统拆分

就是将大的系统拆分为不同的模块，不同模块之间用dubbo或RPC来调用，，一个模块单独对应一个数据库。这也是最初微服务思想的来源，提升了系统可扩展性，降低了系统间的耦合，同时扩展了数据库。

2、缓存

大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。 redis 轻轻松松单机几万的并发。所以，那些承载主要请求的读场景，用缓存来实现高并发。

3、MQ

对于高并发写的场景，比如说一个业务操作里要频繁操作数据库几十次，那高并发情况下系统是没法支持如此高的并发写情况的，如果还是用 redis 来承载写那肯定不行，数据随时可能被 LRU 了，Redis支持的数据格式也比较简单，也不提供事务支持。这时通过使用 MQ ，将大量的写请求灌入 MQ 里，排队慢慢玩儿，后边系统消费后慢慢写，控制在 mysql 承载范围之内。所以对于项目中那些承载复杂写业务逻辑的场景里，一般用 MQ 来异步写，提升并发性，毕竟MQ 单机抗几万并发也是 ok 的。

4、分库分表

应用的横向扩展往往不是难题，增加负载均衡就好，但是数据库后面会成为影响性能一个比较大的指标，这种一般采用分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 sql 跑的性能。

5，读写分离

读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

6、Elasticsearch

Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以考虑用 es 来承载。

上面的 6 点，基本就是高并发系统肯定要干的一些事儿，大家可以仔细结合之前讲过的知识考虑一下，到时候你可以系统的把这块阐述一下，然后每个部分要注意哪些问题，之前都讲过了，你都可以阐述阐述，表明你对这块是有点积累的。

说句实话，毕竟你真正厉害的一点，不是在于弄明白一些技术，或者大概知道一个高并发系统应该长什么样？其实实际上在真正的复杂的业务系统里，做高并发要远远比上面提到的点要复杂几十倍到上百倍。你需要考虑：哪些需要分库分表，哪些不需要分库分表，单库单表跟分库分表如何 join，哪些数据要放到缓存里去，放哪些数据才可以扛住高并发的请求，你需要完成对一个复杂业务系统的分析之后，然后逐步逐步的加入高并发的系统架构的改造，这个过程是无比复杂的，一旦做过一次，并且做好了，你在这个市场上就会非常的吃香。

其实大部分公司，真正看重的，不是说你掌握高并发相关的一些基本的架构知识，架构中的一些技术，RocketMQ、Kafka、Redis、Elasticsearch，高并发这一块，你了解了，也只能是次一等的人才。对一个有几十万行代码的复杂的分布式系统，一步一步架构、设计以及实践过高并发架构的人，这个经验是难能可贵的。