高并发业务场景下常见的解决方案

1.原因

由于系统都是连接数据库的,但是一般最多数据库每秒只能支撑几千的并非,如果业务量激增,会导致系统宕机;因此需要从一下几点入手设计

· 系统拆分

· 缓存

· MQ

· 分库分表

· 读写分离

· 搜索

2.系统拆分

将一个系统进行功能拆分,如现在流行的微服务,每个服务连接的数据库分开,分开部署。这样可以将压力进行拆分,缓解因为网络和数据库导致的高并发

3.缓存

大部分场景下,都是查询多余插入更新,也就是读多写少。因此设计时对常用的查询内容必须进行缓存,查询时先查缓存,再查数据库;更新时也要更新缓存;

redis 单机支持几万的并发。项目设计时针对那些承载主要请求的读场景,怎么用缓存来抗高并发。

4.MQ

再考虑高并发写的场景,比如一个业务操作要数据库操作几十次,增删改增删改,在普通环境下不会有问题,但是如果高并发绝对会出现问题;

如通讯分析项目,话单导入时多线程同时导入。如果多个用户都同时导入,会有多个导入任务,几十几百甚至启动上千的线程跑。也会导致系统出现问题;

可以将大量的写请求灌入 MQ 里,进行排队,后边系统慢慢写,控制在数据库承载范围之内。MQ 单机支持几万并发,所以设计系统时,对应承载复杂写业务逻辑的场景里,如何用 MQ 来异步写,提升并发性。

缺点:

· 系统可用性降低-外部依赖越多,越容易出现问题

· 系统复杂度提高-需要处理重复消费和丢失的问题

· 一致性问题-由于是异步需要保证数据的完整

Kafka、ActiveMQ、RabbitMQ、RocketMQ 优缺点

5.分库分表

单个数据库无法支持,可以考虑多个数据库;如果单个表内容太多可以考虑把表分开存储;单表数据量太大也可以表拆分或者类似分区表的形式处理,每个表的数据量保持少一点,提高 sql 跑的性能

6.读写分离

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

7.搜索

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

8.项目设计的思考

在实际设计项目中,做高并发要远比上面提到的点要复杂的多。需要考虑:

哪些需要分库分表,哪些不需要分库分表,单库单表跟分库分表如何 join,哪些数据要放到缓存里去,放哪些数据才可以扛住高并发的请求

需要完成对一个复杂业务系统的分析之后,然后逐步逐步的加入高并发的系统架构的改造

posted @ 2020-05-02 11:49  Water540  阅读(4126)  评论(0编辑  收藏  举报