处理高并发的通常思路

前言

今天看见有人聊目前系统有2亿的PV，该如何优化？当我看到这个话题的时候，忽然在想本身工做中也遇到了很多高并发的场景了，因此即兴发挥，在这里简单总结和分享下，欢迎指正和补充。

正文

读操做

关于读，咱们通常遵循以下优先级：

优先级	技术方案	说明	示例
最高	尽量静态化	对实时性要去不高的数据，尽量全走CDN	例如获取基础商品信息
高	就近使用内存	优先级服务器内存、远程内存服务	例如秒杀、抢购库存(优先分配库存到服务器内存，其次远程内存服务<又涉及额外网络IO>)
极低	数据库(能不读就不要读)	链接池、sql优化	常见业务

写操做

关于写，咱们通常会按照数据的一致性要求级别来看：

数据一致性要求	技术方案
不高	先写内存(优先级从服务器内存到远程内存服务) 再异步储存
高	同步完成最关键的任务 异步保证其余任务最终成功

削峰限流

从简单到复杂:

简单程度	技术方案
最简单	百分比流量拒绝(随机、没有先到先得不够公平)
简单	原子操做限流(优先级使用服务器内存、其次远程内存服务)
稍麻烦	队列限流(先到先得，公平)

服务稳定性

在高并发的场景，有时候为了保证核心业务的正常进行，咱们须要对一些次要的业务进行服务降级。简单的降级方案以下：

1. 配置开关降级：手动进行配置开关降级
2. 定时开关降级：自动定时降级

系统架构

关于系统架构，不用想的太复杂，简单的拆离此业务便可。

运维架构

部署层面，尽量的把此类服务单独部署。

武器

"工欲善其事，必先利其器"，处理高并发咱们固然少不了好的武器。如下是高并发“三剑客”：

技术名词	说明
异步	异步回调，层层回调似灾难(Promise也是很臃肿的链式代码)
epoll	IO多路复用，nginx/redis方案
协程	轻量，用户态调度高并发能力