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