高并发架构设计思路

并发核心：单体项目的并发

影响因素高并发架构的因素：

1.单体并发量

1.1.数据库查询

1.1.1. 查询操作

• redis 缓存
• jvm缓存热点数据
• mysql分区（不能再做子分区）

1.1.2. 插入操作

• 批量一次插入
• mq异步

当单台数据库依然无法满足时

1.1.3. 一主一从

• 主从复制读写分离

依然无法满足业务时

1.1.4. 多主多从 （数据分布式）

主服务器数据是同步的

1.1.5. 主主互为主从（数据分布式）

主服务器数据是同步的

1.1.6. 主服务器分片存储（数据分布式）

• hash算法看这条数据存放到哪台服务器
• 主服务器数据是有差异的
• hash算法一定要均匀
• 一定没有大范围的查询（造成多个主服务器大范围的查询）

1.1.7. 表的水平拆分、垂直拆分

1.2.代码书写

1.2.1 多线程

1.3.外部接口调用

如：短信、支付、人脸识别、身份证、银行卡等外部校验
外部接口拥堵 = IO等待时间 = 线程处理block状态 = 对CPU不产生影响 = 上线文切换频繁（内核态与用户态）

• 适当加大线程池容量（如：5线程等1秒，10线程也等1秒，1秒后返回10条ack）
• 调用部分拆分成单独项目，2个前提
  • 可以进行虚假返回
  • 当前项目结构规划允许
• 补偿机制（基于可以虚假返回的情况，外部接口要极其稳定的情况）

2.整体分布式

现在可动态的扩容我们的节点

2.1 数据库分布式

2.2 项目分布式

2.3 redis缓存集群

2.4 MQ集群

3.负载均衡 （分布式上层）

3.1 项目分布式

• 请求入口的负载均衡
• 项目之间调的负载均衡

3.2 中间件分布式

• 调用redis时负载均衡
• 调用mq时负载均衡
• 调用DB时负载均衡

4.CDN

• 减少网络传输长度
• 最前置的一层缓存（不需要依赖前后端代码就能返回到用户）

5.前端高并发

• 前端缓存
• 前端的限流
  • 短信验证码1分钟1次
  • 数据校验，手机号合法校验
  • 按钮请求控制，在秒杀架构下按钮置灰操作

6.真正的理解并发

• 限量秒杀，体现不了真正的并发，基于限流的基础上 （丢弃绝大部分请求，替补队列），现在秒杀更关注的是以下情况：

  • redis与db数据同步问题
  • 超卖避免问题
  • 整体的秒杀业务处理线 （下单、付款、退单、库存扣减等）

• 非限量抢购