前言
今天看见有人聊目前系统有2亿的PV,该如何优化?当我看到这个话题的时候,突然在想自己工作中也遇到了不少高并发的场景了,所以即兴发挥,在这里简单总结和分享下,欢迎指正和补充。
正文
读操作
关于读,我们一般遵循如下优先级:
优先级 | 技术方案 | 说明 | 示例 |
---|---|---|---|
最高 | 尽可能静态化 | 对实时性要去不高的数据,尽可能全走CDN | 例如获取基础商品信息 |
高 | 就近使用内存 | 优先级服务器内存、远程内存服务 | 例如秒杀、抢购库存(优先分配库存到服务器内存,其次远程内存服务<又涉及额外网络IO>) |
极低 | 数据库(能不读就不要读) | 连接池、sql优化 | 常见业务 |
写操作
关于写,我们一般会按照数据的一致性要求级别来看:
数据一致性要求 | 技术方案 |
---|---|
不高 | 先写内存(优先级从服务器内存到远程内存服务) 再异步储存 |
高 | 同步完成最关键的任务 异步保证其他任务最终成功 |
削峰限流
从简单到复杂:
简单程度 | 技术方案 |
---|---|
最简单 | 百分比流量拒绝(随机、没有先到先得不够公平) |
简单 | 原子操作限流(优先级使用服务器内存、其次远程内存服务) |
稍麻烦 | 队列限流(先到先得,公平) |
服务稳定性
在高并发的场景,有时候为了保证核心业务的正常进行,我们需要对一些次要的业务进行服务降级。简单的降级方案如下:
- 配置开关降级:手动进行配置开关降级
- 定时开关降级:自动定时降级
系统架构
关于系统架构,不用想的太复杂,简单的拆离此业务即可。
运维架构
部署层面,尽可能的把此类服务单独部署。
武器
"工欲善其事,必先利其器",处理高并发我们当然少不了好的武器。以下是高并发“三剑客”:
技术名词 | 说明 |
---|---|
异步 | 异步回调,层层回调似灾难(Promise也是很臃肿的链式代码) |
epoll | IO多路复用,nginx/redis方案 |
协程 | 轻量,用户态调度高并发能力 |
有疑问加站长微信联系(非本文作者)