如何设计一个高并发系统的关键点

这篇文章主要讲解了“如何设计一个高并发系统的关键点”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“如何设计一个高并发系统的关键点”吧！

一、为啥会有高并发

现在用互联网的人越来越多，很多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、读写分离

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

感谢各位的阅读，以上就是“如何设计一个高并发系统的关键点”的内容了，经过本文的学习后，相信大家对如何设计一个高并发系统的关键点这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！