(1)系统拆分
将一个系统拆分为多个子系统,用dubbo来搞,然后每个系统连接一个数据库,这样本来一个库,现在多个数据库,可以提高并发。
(2)缓存
必须会用到缓存,大部分的高并发场景,都是读多写少。那么完全可以在数据库和缓存里都写一份。然后读的时候大量走缓存,如 redis 轻松单机 几万的并发。所以,可以考虑你的项目中,那些承载主要请求的读场景,怎么同缓存来抗高并发。
(3)MQ
必须要用MQ,可能你还是会出现高并发写的场景。比如说一个业务操作里要频繁搞数据库几十次增删改,这样的高并发用 redis 承载写肯定不行。redis是缓存,数据随时就被 LRU了,数据格式还无比简单,没有事务支持。所以此时只能同MQ,大量的写请求灌入MQ里,排队慢慢玩,后边系统消费后慢慢写,控制在MySQL承载范围内。所以得考虑项目中,那些承载复杂写业务逻辑的场景里,如何用MQ来异步写,提升并发性,MQ单机抗几万并发也是OK的。
(4)分库分表
分库分表可能到了最后数据库层面还是免不了抗高并发的要求,那么就将一个数据库拆分成多个库。多个库来抗更高的并发,然后将一个表拆分为多个表。每个表的数据量保持少一点,提高spl跑的性能。
(5)读写分离
读写分离就是说大部分时候数据库可能也是读多写少,没必要所有请求都集中在一个库上。可以搞一个主从架构,主库写入、从库读取,搞一个读写分离。读流量太多时,还可以加入更多的从库。
(6)ElastieSearch
ElasticSearch简称es,是分布式的,可以随便扩容,分布式天然就可以支撑高并发,因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作,可以考虑用es来承载。还有一些全文搜索类的操作,也可以考虑用es来承载。
5万+

被折叠的 条评论
为什么被折叠?



