高并发架构设计(一)——设计一个高并发系统的关键点

高并发架构设计(一)——设计一个高并发系统的关键点

原创孤傲苍狼

一、为啥会有高并发

现在用互联网的人越来越多，很多app、网站、系统承载的都是高并发请求，可能高峰期每秒并发量几千，很正常的。尤其是电商App，如果是双十一之类的，每秒并发几万几十万都有可能，高并发访问带来的问题是系统和数据库扛不住，容易宕机，要知道数据库支撑到每秒并发两三千的时候，基本就快完了，数据库如果瞬间承载每秒5000,8000，甚至上万的并发，一定会宕机，比如mysql就压根儿扛不住这么高的并发量。

那么如此之高的并发量，加上原本就如此之复杂的业务，我们该如何设计一个可以支持高并发访问的系统呢，主要从以下几点去考虑：

• 系统拆分
• 使用缓存
• 引入MQ
• 分库分表
• 读写分离

二、设计高并发系统的关键点

 

2.1、系统拆分

将一个大的系统拆分为基于微服务架构的多个子系统，技术落地选择使用SpringCloud来做，然后每个子系统连一个数据库，这样本来就一个库，现在多个数据库，这样也可以扛高并发。

2.2、使用缓存

缓存，一定要用缓存。大部分的高并发场景，都是读多写少，我们完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存，可以引入Redis作为分布式缓存的技术解决方案，redis单机就支持每秒几万的并发，在集群情况下更是可以达到每秒几十万的并发。所以我们要考虑项目里那些承载主要请求的读场景，怎么用缓存来抗高并发，同时也得处理好【缓存雪崩】、【缓存穿透】、【缓存击穿】这些问题

2.3、引入MQ

MQ，一定得用上MQ。因为系统还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，那高并发访问的情况下绝对搞挂数据库，这个时候就可以考虑用MQ去削峰，将大量的写请求先灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在数据库承载范围之内。所以我们要考虑项目里那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机可以扛得起几万并发。MQ的技术选型可以选择用rabbitMq或者Kafka。当然了，系统引入MQ之后，也会导致整个系统的可用性降低，系统复杂度提高，系统引入的外部依赖越多，越容易挂掉。所以引入MQ后，要考虑【如何保证消息队列的高可用】、【如何保证消息没有重复消费】、【如何处理消息丢失的情况】、【如何保证消息传递的顺序性】等问题，引入MQ有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉。

2.4、分库分表

分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，那么就将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持在一定范围内，提高sql跑的性能。推荐使用ShardingSphere作为分库分表的技术解决方案

2.5、读写分离

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