面试：高并发系统设计

末蓝、 2022-11-06 07:50 213阅读 0赞

# 面试：高并发系统设计 #

## 总览 ##

在高并发的情景下进行系统设计，

可以分为以下 6 点：

*  系统拆分
    
     *  熔断
     *  降级
 *  缓存
 *  MQ
 *  分库分表
 *  读写分离
 *  ElasticSearch

![e224627662d77106cc658a8f39b2f3c7.png][]

## ##

### 系统拆分 ###

将一个系统拆分为多个子系统，用 RPC 来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么。

## ##

### 缓存 ###

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

## ##

### MQ ###

可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改。那高并发绝对搞挂你的系统，你要是用 Redis 来承载写那肯定不行，人家是缓存，数据随时就被 LRU 了，数据格式还无比简单，没有事务支持。所以该用 MySQL 还得用 MySQL 啊。那你咋办？用 MQ 吧，大量的写请求灌入 MQ 里，后边系统消费后慢慢写，控制在 MySQL 承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。

## ##

### 分库分表 ###

分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 SQL 跑的性能。

## ##

### 读写分离 ###

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

## ##

### ElasticSearch ###

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

# #

## 参考链接 ##

*  [如何设计一个高并发系统？][Link 1]

[e224627662d77106cc658a8f39b2f3c7.png]: /images/20221023/4cb1a4e91c574d56b52c7575051366c0.png
[Link 1]: https://doocs.github.io/advanced-java/#/./docs/high-concurrency/high-concurrency-design