浅谈如何设计一个高并发系统
本文最后更新于 701 天前,其中的信息可能已经有所发展或是发生改变。

概述

为什么要设计高并发的系统呢?随着日益增长的用户量,一般来说,一个系统起步都是直接是连接数据库的,而数据库支撑到每秒并发两三千的时候,基本就快完了,不断的堆配置,加集群始终不是解决之道。

一个高并发的系统,应该从以下几个方面逐步优化:

  • 系统拆分
  • 缓存中间件
  • MQ 消息队列
  • 分库分表
  • 数据库读写分离
  • ElasticSearch
105841_bd19b44d_955503

系统拆分

将一个系统,按照业务拆分成多个服务,可以用 dubbo、springcloud 来做,每个模块连接一个单独的数据库,服务之间通过 RPC 来进行通信,这就是微服务的雏形,还有很多需要考虑的东西,如网关、鉴权、链路追踪、服务降级、熔断等等

缓存中间件

大部分的高并发场景,都是读多写少,完全可以先从缓存查询,这一步可以用 Redis 来做,由于直接操作内存的特性,可以轻松抗住单机几万的并发量,当然有些关键的问题也是需要考虑的,如缓存与数据库不一致、缓存雪崩、缓存击穿、缓存并发竞争等问题。

MQ 消息队列

MQ 的存在,也是为了对抗高并发的业务请求,大量的查询请求被打到了缓存,但是写操作呢?直接打到数据库一样死翘翘,这时我们可以利用 MQ 消息队列来做削峰处理,管你多少请求,我一并写到消息队列,然后以一个合理的速度慢慢的往数据库写,控制在 MySQL 的承受范围内。当然这个写操作是异步的,所以得考虑哪些数据实时性要求不高且数据相对比较复杂,适合用异步来做。

分库分表

虽然已经按照业务,拆分了数据库,但是单个数据库也是有瓶颈的,这时又不得不考虑分库分表了,那么就将一个数据库拆分为多个库,多个库来扛更高的并发;然后将一个表拆分为多个表,每个表的数据量保持少一点,提高 SQL 跑的性能。

数据库读写分离

对于大部分系统来说,都是读多写少,写的操作对数据库来说压力更大,这时我们可以搞个读写分离,因为没必要所有的请求都在一个库上,可以搞个主从架构,主库写入,从库读取。读流量太多的时候,还可以加更多的从库。

ElasticSearch

从海量数据中检索数据,就不要傻傻的写 SQL 查询了,稍不注意就玩死了,花点时间,搭建一个搜索引擎,es 是分布式的,可以随便扩容,分布式天然就可以支撑高并发。

暂无评论

发送评论 编辑评论

|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇