Nicholas Qin1. 这套"100讲"到底讲什么——先泼盆冷水再替你拆目录
先把话说透：这种带"100讲"字样的免费开源合集，收藏夹里吃灰的概率是99%。我见过太多人转完链接之后，就再也没打开过。但如果你真的愿意往下读，这套《高并发 & 微服务 & 性能调优实战案例100讲》确实是一个值得按章节啃完的资料，因为它不是那种讲概念讲到天上去的教程，而是把问题拆成能落地的案例，每一个都能对应到真实业务里你大概率踩过的坑。
我拿到目录后，先把100讲的结构梳理了一遍，大致可以归成三条主线：
| 主线 | 大致比重 | 核心关键词 |
|---|---|---|
| 高并发 | 约35讲 | 线程池、消息队列、分布式锁、流量控制、限流熔断 |
| 微服务 | 约40讲 | 注册发现、网关、配置中心、分布式事务、服务治理 |
| 性能调优 | 约25讲 | JVM调优、慢SQL、缓存设计、连接池、性能工具 |
比例对得上它标题的顺序，也和很多团队后端技术栈的痛点排序基本一致。换句话说，它不是作者拍脑袋凑的100个标题，而是顺着一个后端项目从"并发上来了"到"服务拆开了"再到"性能出问题了"的完整过程来组织的。
适合谁？我说句实在话：工作两三年、项目里已经遇到并发问题和微服务拆分问题的人，收获最大。还在学校或者刚入行的朋友，也能看，但建议按照我后面给的学习顺序来，别一上来就啃分布式事务。
这套资料还一个好处：它标榜"开源免费"。也就是说你不光能看文章，还能找到配套的代码仓库去跑Demo。这一点比很多只放PPT截图的付费课强太多，至少每一步是怎么实现的，你可以自己验证。
下面我把三条主线分别拆开，挑其中真正值得细看的实战案例，以及我在自己项目里复现时遇到的细节，一条一条讲给你。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高并发场景：最值得反复看的五个实战案例
高并发这35讲，说穿了就是围绕一个问题：当请求量超过单一节点处理能力时，怎么让系统不崩、数据不错、响应不慢。我建议你优先看下面几个案例，它们基本覆盖了日常业务里最高频的并发场景。
2.1 秒杀系统的流量控制：限流、削峰、防超卖
秒杀几乎是所有高并发课程的第一课，因为它的流量模型最极端：瞬间流量是平时的几百倍，同时还有"超卖"这种业务上的硬约束。
这一讲我记得核心是三个动作搭配：一是用Sentinel或Guava RateLimiter做前置限流，把超过预期QPS的请求直接挡在网关层，返回"排队中"而不是让它穿透到数据库。二是用消息队列做流量削峰，把秒杀请求先落进MQ，后端按固定速率消费，避免数据库瞬间被打满。三是防超卖，经典的方案是用Redis的原子操作扣减库存，而不是直接改数据库字段。
java复制// 伪代码：Redis原子扣减库存，防止超卖
Long stock = redisTemplate.opsForValue()
.increment("seckill:stock:1001", -1);
if (stock != null && stock >= 0) {
// 扣减成功，发送MQ消息异步创建订单
} else {
// 说明库存不足，把扣减回滚
redisTemplate.opsForValue().increment("seckill:stock:1001", 1);
}
很多人在这一讲容易忽略一个点：Redis扣减成功之后，数据库的最终一致性怎么保证。如果MQ消费失败，订单没建，库存却扣了的"幽灵库存"怎么处理？答案是，设计上要允许超时关闭订单并回补库存，或者用对账任务兜底。这些细节，课程里有讲，但需要你在做Demo的时候自己补一道练习。
2.2 Kafka高并发消息处理：分区、批量、消费位点
最近一直有人在搜"kafka高并发消息处理办法"，其实核心就三件事：分区并行、批量发送/拉取、消费位点管理。Kafka说穿了是一个分布式的提交日志，它能扛住高并发，靠的是分区并行——一个Topic拆成多个Partition，每个Partition只被一个消费者线程消费，理论上分区数乘以消费线程数就是你的最大并行度。
这一讲实操上有一个容易翻车的细节：消费者线程数超过了分区数，多余的线程只会闲着，不会帮你提升消费速度。而且如果你在代码里把enable.auto.commit设为true，消费端宕机之后很容易出现重复消费，没有做幂等的话，数据就重复入库了。我在项目里吃过这个亏，后来统一改成手动提交+落库逻辑做幂等，才算彻底解决。
2.3 分布式锁：Redis锁和ZooKeeper锁怎么选
分布式锁是高并发面试里绕不开的问题，也是实战里最容易写错的模块。这套课程里讲了两套方案，Redis锁简单高效，ZooKeeper锁可靠但稍重。
Redis锁的关键点是别只写setnx加锁、del释放锁这样的两行代码就开始自嗨。必须考虑三个问题：锁一定要设置过期时间，防止持有锁的线程崩溃导致死锁；加锁时要设置唯一标识，释放锁时校验这个标识，防止误删别人的锁；在极端情况下，要用Redisson这类封装好的看门狗机制，实现锁的自动续期。
java复制// 低配版Redis锁：setnx + 过期时间
Boolean locked = redisTemplate.opsForValue()
.setIfAbsent("lock:order:" + orderId, requestId, 30, TimeUnit.SECONDS);
// 释放时先比对requestId，再delete
这一讲建议你配合后面的"分布式锁在集群环境下的坑"一起看，因为单机Redis的锁在主从切换时可能有脑裂问题，这也是生产环境不少大厂改用ZooKeeper锁的原因。看完之后，你也可以自己用Curator在本地起一个ZK集群去复现。
2.4 线程池调优：核心参数不是靠背的
高并发案例里一定会有一讲讲线程池，而且一定会贴ThreadPoolExecutor的七个参数。但只看参数没有意义，真正关键是搞清楚你的业务属于CPU密集型还是IO密集型。CPU密集型的业务，线程数建议控制在CPU核数+1左右；IO密集型的业务，可以放宽到CPU核数的两倍，因为线程大部分时间在等待IO。
更实际的问题是，线上线程池的队列满了之后怎么办。拒绝策略要按业务选：发短信通知这类可容忍丢失的，可以静默丢弃；下单这种核心链路，必须用CallerRunsPolicy做背压，宁可把压力传回调用方，也不能直接抛异常丢单。
2.5 缓存穿透、击穿、雪崩的一次完整复盘
这三个词都快被说烂了，但能说清楚区别的人很少。穿透是查一个不存在的key，导致请求一直打到数据库；击穿是一个热点key刚好过期，大量请求同时打到数据库；雪崩是多个key同时过期，数据库被一波流量压垮。
这一讲的Demo适合自己动手做一遍：布隆过滤器防穿透，互斥锁或逻辑过期防击穿，过期时间加随机值防雪崩。做完你会有一个手感，而不是只会背"缓存穿透怎么办"的八股答案。
3. 微服务链路里的"拦路虎"：从服务注册到分布式事务
微服务的40讲是整套资料的重头戏，对应的也是从"单体应用拆成多个服务"之后，一夜之间冒出来的各种问题。很多朋友从单体转微服务，第一个不适应的就是：原来一个方法调用解决的问题，现在变成了好几次网络调用，每个环节都可能失败。
3.1 服务注册与发现：Nacos还是Consul，不只看星数
微服务的第一只拦路虎，就是服务与服务之间怎么找到对方。课程里应该会对比Nacos、Consul、Eureka这几套方案。我的观点是：用Spring Cloud Alibaba的话就踏实选Nacos，因为它是阿里在双十一这种场景验证过的AP模型注册中心，而且和Spring Cloud Alibaba的集成度最好；不要因为某个组件GitHub星多就乱选，生态匹配比单个组件的口碑更重要。
这里有一个我在项目里实际踩过的坑：Nacos的临时实例掉线之后，默认心跳超时是15秒，服务消费者那边如果还拿着旧的实例列表继续调用，就会间歇性出现"找不到服务"的报错。后来把nacos.naming.heart-beat-timeout调整到更适合自己服务启动时间的数值，同时给消费方配了重试机制，才稳定下来。这种细节，教程里不一定逐字讲，但案例的某句话往往能给你一个排查方向。
3.2 配置中心：配置也能"热更新"
配置中心的核心理念一句话：把配置从代码里搬出去，让配置变成和代码发布无关的独立资产。课程里应该会演示Nacos配置中心通过长轮询机制实现配置变更的实时推送。
实操时要特别注意分组和命名空间的隔离。开发、测试、生产环境的配置，必须用不同的namespace隔开，否则你在本地改一个Redis密码，线上应用的配置也被覆盖了，那就是事故。这个我在新手期干过，记忆犹新。
3.3 分布式事务：Seata的AT模式和TCC模式区别在哪
分布式事务这讲，我建议每个微服务开发者至少看两遍。Seata有两个最常用的模式，AT模式对业务代码侵入极小，原理是拦截SQL，生成undo_log回滚日志，实现最终一致性；TCC模式则需要业务自己写Try、Confirm、Cancel三个方法，灵活性强，但开发量也大。
先说结论：跨服务的数据一致性要求高、并发量又不是特别夸张的业务，优先用AT模式。TCC模式适合"预留资源"这种语义明显的场景，比如订单预占库存、预扣余额。不要一上来就想全链路TCC，那是给压测团队找存在感。
有一个常见误区必须提醒：分布式事务不是万金油，它解决的是跨服务的数据一致性问题，但它自己也会带来性能损耗。如果你的业务可以通过"本地消息表+消息队列+对账"达到最终一致性，很多时候不需要上Seata。
3.4 服务容错：熔断、降级、限流的正确姿势
微服务50%的故障都出在"一个服务拖垮一条链路"这种连锁反应上。这一讲应该会教你用Sentinel或者Resilience4j做熔断降级。
这里最重要的价值观是：降级要敢于返回兜底结果。比如商品详情页的推荐位接口挂了，可以直接返回空列表，而不是让整个详情页都打不开。熔断打开之后，要给后端服务一个恢复的时间窗口，等它缓过来再重新放流量，这就是熔断器半开状态的用意。
3.5 从架构图到落地：别人画的微服务架构图和你项目的差距
很多人搜"微服务架构图"，收藏了一堆花花绿绿的图，但对照自己的项目一套，发现根本配不上。差距通常在于三件事：没有梳理清楚服务间的调用拓扑，没有明确网关层到底负责什么，没有定义好接口的版本兼容策略。
这一讲的价值在于，它会用一套完整的案例把"架构图上的方框"落到"工程里的代码模块"。你可以照着这个思路，把自己项目的服务按业务域画一张调用链路图，标出哪里是强依赖、哪里可以异步化，这张图比教程本身更有用。
4. 性能调优不玄学：三条能直接抄的排查路径
性能调优这25讲，很多人觉得是最"虚"的，因为问题千奇百怪。但你真去复现一遍案例就会发现，绝大多数性能问题的根因，都跑不出几个固定套路。下面这三条路径，是我从这25讲里提炼出来、并在自己项目里反复验证过的。
4.1 JVM调优第一步不是调参数，而是看日志
JVM被很多人当成玄学，最常见的行为就是拿着网上的-Xms、-Xmx参数脚本直接往生产环境贴。我只说一句：调参之前，你至少得先知道自己的系统到底是什么垃圾回收器、GC频率多少、GC停顿多久。
正确的路径是先观察再调参：用jstat -gcutil pid 1000看内存分区变化，用jmap -dump导一份堆快照，用MAT分析大对象和内存泄漏。课程里应该有一讲专门讲"一次Full GC导致的线上大面积超时排查"，这个案例强烈建议跟着做一遍，因为它把思路讲完了：先看GC日志，再确认是内存分配问题还是死循环产生大对象，最后才落到参数调整。
有了这些数据之后，调参数才有意义。比如GC频繁但每次回收后内存使用率还是很高，那就要调大堆内存或者排查内存泄漏；如果是CMS的Concurrent Mode Failure，就要把触发阈值调低一点。参数是最后的手段，不是第一步。
4.2 慢SQL优化的完整链路：explain、索引、连接池
性能调优里最好出成果的就是SQL优化，因为收益立竿见影。这一讲的案例分析方式，通常是从一个慢SQL日志开始，然后逐步做explain分析，再用索引和改写SQL来修复。
核心思路就这么几步：
- 用
slow_query_log抓出最耗时的SQL，不要凭感觉猜。 - 对慢SQL执行
explain，关注type、key、rows三个字段。 - 如果
type是ALL，说明是全表扫描，优先考虑加索引。 - 加了索引还不快，就要看SQL写法是不是导致索引失效了，比如对索引列做了函数操作、隐式类型转换。
- 最后还要检查数据库连接池：
maxPoolSize太小会导致大量请求在等连接，这个特征是"数据库CPU不高，但接口RT很高"。
注意：连接池大小不是越大越好。数据库连接是有代价的，我见过有人为了"调优"把HikariCP的maximumPoolSize调到200，结果数据库线程数被打满，反而拖垮了整个库。一般一个实例20到50个连接已经够用，关键是处理速度而不是连接数量。
4.3 性能工具组合拳：Arthas、JMeter、top少一个都别扭
调优最大的障碍是你"看不见"。所以工具链的熟练度，比背十个调优参数都重要。我现在排查一个接口慢的问题，标准动作是这三步：先用top -Hp pid看线程CPU占用，再用Arthas的trace命令跟踪方法耗时，最后用JMeter做并发压测验证修复效果。
特别是Arthas，真是后端开发的瑞士军刀。你可以不用重启应用，就实时看到某个接口内部每个方法的耗时分布。有时候"这个接口很慢"的真相，根本不在业务代码里，而在一次远程调用的网络等待上，Arthas基本上一trace就能定位到。
压测环节我多说一句：JMeter压测高并发接口的时候，一定要设置合理的超时时间，不然线程全卡在等待响应上，测出来的吞吐量会严重失真。这也是我在压测一个慢接口时得到的教训，当时把超时时间从3秒改成1秒，吞吐量数据立马变了个样。
4.4 从调优案例反推架构设计：提前把问题消灭在流量进来之前
25讲快看完的时候，你会发现自己看问题的方式变了：以前是"出了问题赶紧修"，现在是"这个设计一开始就会出问题"。这就是Case学习最大的好处——你在别人的故障里积累经验。比如看到缓存雪崩的案例，就会在设计阶段主动给缓存过期时间加随机值；看到数据库连接池被打满的案例，就会在写代码时主动控制事务时间，不在事务里做远程调用。
5. 别囤100讲就吃灰——我的围观顺序和笔记方法
最后这部分，是给已经决定要学习的你准备的。我见过太多人学习这套资料的姿势是三连然后遗忘，所以把我的经验直接分享出来：先怎么学、学的时候怎么记、遇到看不懂的怎么办。
5.1 正确的打开顺序：从你手头正在遇到的问题开始
别从第1讲开始按顺序看，那是看书的方法，不是看案例的方法。正确做法是：遇到一个具体问题，就去目录里找到对应的一讲，看完立刻动手复现。
我自己的顺序是这样的：先看高并发里"线程池调优"和"缓存穿透/击穿/雪崩"这两讲，因为它们覆盖面广、见效快。然后把"秒杀"和"消息队列削峰"当作一个完整项目做一遍，把限流、异步、防超卖串起来。工作涉及微服务之后，再看"分布式事务"和"服务熔断降级"，既有基础又接地气。性能调优放最后，因为那是需要更多背景知识才能看懂的。
5.2 怎么记笔记才不是自欺欺人
我的笔记方法很简单：每个案例只记三件事——问题是什么、我踩的坑是什么、修好之后和修好之前有什么变化。不要抄大段的原理，那些PDF文档里都有，你抄了也不看。要记的是"你自己亲手操作之后才理解的那部分"。
比如Redis分布式锁那一讲，我的笔记只写了一句话："用setIfAbsent时记得带requestId，否则在并发请求下可能删除别人的锁"。就这一句话，比抄整页代码有用得多。
另外，每学完一个案例，用一句话总结：以后什么场景下我会用这个方案。这句话是今后你写系统设计时的决策依据。
5.3 复现案例的一些建议
如果你决定把这个Demo仓库clone下来跑一遍，我有几个建议：
- 先把本地环境准备好：JDK8或JDK11、Maven、Docker，这套案例应该都是基于Java生态的。
- 尽量用Docker起中间件，Redis、Nacos、MySQL都容器化，不会把自己的开发机搞乱。
- 每个案例单独建分支或者单独跑，不要图省事把100个案例的依赖都塞进同一个工程，依赖冲突会浪费你很多时间。
- 跑通了不算完，自己改一改参数再观察现象，比如把一个限流阈值从100改成10，看看流量被挡住之后日志输出什么。这个"改参数看现象"的过程，才是真正学到东西的过程。
- 有些并发场景单机起Demo是复现不出效果来的，比如分布式事务、注册中心集群。建议用本地Docker Compose起一个三节点的小集群，否则你能看到的只是"程序没报错"，看不到真实的网络抖动和节点切换现象。
5.4 最后分享一个我个人的小习惯
我现在同时保持着一个习惯：每个季度，翻一翻自己收藏的这些免费开源教程目录，看看目录里有没有自己最近踩过的坑。如果发现了，就把这一讲重新看一遍，用现在的经验去对照它的方案，往往会有新的理解。技术资料的价值不在于你收藏的那一刻，而在于你在不同成长阶段回看时，每一次都能读出新东西。这套《高并发 & 微服务 & 性能调优实战案例100讲》，值得被这样对待。
我的建议是别把这个链接发给朋友就算完事，你俩真的一起把里面某个案例复现跑通，那个学习效率比自己看十遍视频高得多。