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