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