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