高并发

概念定义 到底什么是并发 并发 = 多个操作在同一时间窗口内同时进行，无论来自同一人还是不同人。 因为数据只有一份，多人同时操纵就会有风险：谁说了算呢？所以会产生竟态问题。cpu的并发就是最好的理解方式了：cpu核只有一个的情况下，不可能同一时刻给多人使用，所以只能大家轮着时间切片用。 一条数据会不会在同一时刻被两个操作同时修改？是的话就是存在并发问题。 什么是分布式 分布式：系统本身被拆分成了多个服务/节点。系统架构是分散的 一个人讲话给自己听，很难搞错； 三个人ABC一起传话，中间的B听错了，那传到C耳朵里的就变了。大家拿着的信息不一样了，所以分布式场景就是要解决怎么尽量去统一大家信息的问题。 什么是幂等 幂等就是：同一个操作，执行一次和多次，结果不变。 为什么我要单独把他拎出来讲？因为不幂等的设计，既是并发问题，也是分布式问题。 并发如何体现： 多个人同时下单; 一个人同一时刻点赞十次; 分布式如何体现： 项目有三个角色，分别是生产者、MQ、消费者; 还可能是更复杂的微服务项目; 通用分析方法 首先我想声明一句： 在分布式并发问题中，任何不根据具体情景分析，只讲技巧的，都是耍流氓！并发场景信息杂糅、需求各不一致。技术本身是为了解决问题的，脱离了真实情况的技术毫无用处，反而成了心智负担。 四个问题，四个数 遇到一个百万级QPS以内的分布式、并发场景，依次问四个问题，就能精准锁定架构与技术方案方向： 1. 人数 这个操作是 “单人” 还是 “多人”？ 单人操作（比如用户修改自己的头像）：不会有多人写冲突，只可能有重复提交（浏览器重试），用幂等键就够了（如 Redis SETNX）。 多人操作（比如点赞、关注、下单扣库存）：有并发争抢、写冲突风险。 2. 数据库行数 & 表数 这个操作是 “单行单表数据” 还是 “多行 / 跨表数据”？ 单行单表（点赞计数、关注关系）：数据库层的唯一索引 + 状态字段可以直接解决。 多行或跨表（下单：扣库存→生成订单→扣钱）：数据库行锁或乐观锁（version） 是核心，唯一索引只能防重复记录，但防不了库存超卖。 3. 重试数 错误可以 “直接返回” 还是必须 “排队等待”？也就是业务对失败的容忍度如何？ 可以直接返回 “请稍后重试”（如点赞冲突、重复领券）：用乐观锁或唯一键冲突，返回失败由客户端自行重试。 必须排队串行执行、不能失败丢弃（如秒杀扣库存、限量抢购）：用行锁或消息队列串行化，牺牲部分吞吐，强保数据不出错。 4. 一致数 业务需要 “强一致性” 还是 “最终一致性”？ 强一致性（转账、钱包扣款、资金交易）：必须即时数据一致，不能异步兜底，要用分布式事务、行锁、悲观锁，不能靠异步补偿。 最终一致性（普通下单、发积分、返优惠券、日志统计）：允许短暂数据不一致，可异步慢慢补齐，优先用MQ 异步、本地消息表、事务消息解耦，提升吞吐与可用性。 情景演练 情景一：关注 / 取关 问题 答案 人数 多人操作（多人同时对同一博主关注/取关，粉丝数共享） 表数 单行单表（核心socials一行，accounts计数的更新属于事务外 MQ） 重试 直接返回成功（重复操作不报错，与幂等一致） 一致性 核心强一致（关系状态原子翻转），计数最终一致（MQ 异步） ...