如何设计一个高并发架构

为什么需要高并发架构

一个简单的系统，从最开始的时候如果只有10w以内的用户，那么QPS最多也不会超过1000/s。我们开发一个单机的java工程，数据由mysql进行落地是完全可以支持的。
但是如果随着用户体量的增大，就需要开始将系统慢慢的做优化，来支撑高并发，高性能，并且依旧需要高可用。那么我们该如何一步步优化，设计一个高并发的架构呢。

如何设计高并发架构

1、拆分

当系统的业务复杂到一定程度，共同维护开发的人员超过3-5个的时候，就必须要拆分系统。按照业务模块将不同的功能拆分成一个个的小系统，交给不同的人员分别维护。一方面可以减少业务功能之间的耦合，一方面每次更新上线的时候不用全部人员全量测试全量上线。

2、缓存

想要让QPS上升一个等级，必须要有缓存，因为数据库的性能再好，终究是要基于磁盘，性能有着天然性的限制，如果用上了redis这种基于内存的数据存储，那QPS轻轻松松上几万。这是缓存的天然优势，一般系统都是查询请求比较多的，那么用上缓存就是很有必要的。需要注意的就是数据一致性，高可用性

3、MQ消息队列

如果修改数据的请求达到一定体量的时候，就需要用mq来进行异步削峰，避免高峰期的时候数据库扛不住。因为如果不用消息队列的话会出现一个矛盾，高峰期的时候数据库要求性能比较高，但是低谷期时又会造成资源浪费。
所以当高峰期的时候用消息队列来缓解数据库的压力，慢慢处理修改数据的请求，将高峰期的请求往低谷期拖延，这样可以减少资源浪费，避免数据库崩溃，也可以帮助数据库的QPS再上一个层级。

4、分库分表

俗话说打铁还需自身硬，就算使用了消息队列进行削峰，可能请求量到一定程度的时候还是数据库要扛得住压力。那么这时候就有必要进行分库分表，将数据使用主键进行hash算法之类的，存在不同的主机不同的表空间，那么请求自然也就不会放着一个主机上了，这样QPS可以再上一个层级

5、读写分离

这个就属于数据库的优化，如果想要保证数据库的QPS可以扩容增加，那么可以使用主从架构，进行数据库的读写分离。主库写入，从库读取，因为一个系统的请求终究还是读多写少，那么想要承受更大量的读请求，就可以增加更多的从库。

6、Elasticsearch

可以考虑使用es，因为它是分布式的，天然支持高并发。一些简单的查询统计类的操作，或者全文搜索之类的可以使用它来承载。并且可以随便扩容来增加更高的并发量

一个高并发的架构基本上是这些内容，如果面试中被问到了可以按照这种模式大概介绍一下。但是要知道，这只是一个简单的高并发架构可能使用到的技术。里面真正的内容光凭几句话是说不清楚的，比如分库分表该按照什么方式分？读写分离的时候具体要怎么分离？消息队列如何保证系统高可用？幂等性？真正的业务中是否需要保证分布式事务？等等等等一系列的问题。
所以，还是需要多接触一些大项目，去了解真正的项目中有哪些坑，哪些问题比较严重，是怎么解决的，该如何避免。