并发核心：单体项目的并发
影响因素高并发架构的因素：
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数据同步问题
- 超卖避免问题
- 整体的秒杀业务处理线 （下单、付款、退单、库存扣减等）
-
非限量抢购