如何理解高并发系统
高并发系统的定义:
- 保证整体可用
- 能够处理很高的并发用户请求
- 能够承受很大的流量冲击
需要处理的系统瓶颈问题:
- 内存不足
- 磁盘空间不够
- 连接数不够
- 网络带宽不够
如何设计高并发系统的几个大方面
分而治之,横向拓展
微服务拆分(系统拆分)
分库分表
- MySQL单机磁盘容量有限
- 数据库连接数是有限的
- 单表数据量太多,影响SQL性能
池化技术
我们请求调用数据库的时候,都会先获取数据的连接,然后依靠这个连接来查询数据,搞完收工,最后关闭连接,释放资源。如果我们不用数据库连接池的话,每次执行SQL,都要创建和销毁,这样就使每次查询请求变得更慢了。因此要使用数据库连接池,HTTP连接池,Redis连接池等等都是一样的道理。
主从分离
读从库,写主库,主从赋值。
使用缓存
这里包括构建多级缓存
CDN加速静态资源访问
消息队列,削峰
ElasticSearch
ES扩容方便,天然支持高并发。当数据量大的时候,不用动不动就加机器扩容,分库等等,可用考虑用ES来支持简单的查询搜索,统计类的操作。
降级熔断
保护系统的一种机制。当前互联网一般都是分布式部署的,而分布式系统中偶尔会出现某个基础服务不可用,最终导致整个系统不可用的情况,这种现象叫做服务雪崩。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZxKSwW1J-1674050535303)(D:\A\图片\板书\服务雪崩.excalidraw.png)]
如果服务C出现延迟,比如是因为慢SQL查询,那将导致B也会延迟,从而A的延迟越来越多。堵住A请求会消耗系统的线程,IO,CPU等资源。当请求A的服务越来越多,占用的计算机资源也就越多,最终会导致系统瓶颈出现,造成其他的请求同样不可用,最后导致业务崩溃,这就叫服务雪崩。
服务限流
-
限流算法
- 固定窗口限流算法
- 滑动窗口限流算法
- 漏桶算法
- 令牌桶算法
-
限流组件
- guava的RateLimiter单机版限流
- Redis分布式限流
- sentinel限流
异步
跟消息队列有关系
接口常规优化
- 批量思想,批量操作数据库
- 异步思想:耗时操作优先异步处理,前提是业务可以容忍
- 空间换取时间:恰当使用缓存
- 预取思想:提取初始化到缓存
- 池化思想:预分配和循环使用
- 事件回调,拒绝阻塞等待
- 远程调用由串行改为并行
- 锁粒度避免过粗
- 切换存储方式:文件中暂存数据
- 索引
- 优化SQL
- 避免大事务问题
- 优化深分页问题
- 优化程序结构
- 压缩传输内容
- 海量数据处理
- 线程池设计要合理
- 机器问题(fullGC,线程打满等)
压力测试确定系统瓶颈
应对突发流量峰值:扩容+切流量
扩容:增加从库,提升配置
切流量:服务多机房部署