简介这一压缩包是谷粒商城电商实战项目的全阶段课件合集面向正在系统学习微服务、分布式架构与云原生部署的Java后端开发者也适合培训讲师、高校学员作为课程串讲与项目复盘材料。资料按基础篇、运维篇、高级篇三个目录层次组织基础篇覆盖分布式基础、项目环境搭建、SpringCloud组件、前端基础与商品服务运维篇提供K8s部署与DevOps落地课件。高级篇则深入响应式编程、接口幂等性、本地与分布式事务、性能压测、缓存与分布式锁、ElasticSearch检索、异步与线程池、单点登录、RabbitMQ消息队列、支付、定时任务及ShardingSphere分库分表等核心专题三篇合计20余份PDF课件压缩包约33.51MB目录层级清晰便于定位。目前已有2090人学习浏览整套内容串联从环境搭建到生产级组件落地的完整链路PDF课件按专题拆分、层次分明既可用于日常复习也可作为项目复盘与面试梳理的浓缩材料。1. 谷粒商城课件到底讲什么先确认这份资料适不适合你我第二次打开这份谷粒商城课件时才意识到它比我想象中厚实得多。目录从分布式基础一路排到 K8S 部署三十份左右的 PDF 把电商项目的骨架拆成三个层次基础篇讲环境搭建、SpringCloud 组件、商品服务高级篇把事务、幂等、缓存、ElasticSearch、RabbitMQ、ShardingSphere 这些硬骨头单独拎出来运维篇负责容器化部署和 DevOps。它解决的核心问题不是“看懂概念”而是“照着把一个微服务商城搭起来”。适合做毕设、补分布式实战经验、或者面试前想系统性过一遍项目细节的人。下面按我实际复现时的顺序讲讲每份课件该怎么看、参数怎么设、坑在哪。2. 基础篇落地顺序环境、注册中心、网关先跑通再学业务2.1 分布式基础与环境搭建先把能跑的服务跑起来《01、分布式基础项目环境搭建.pdf》我建议第一个读但不要逐页当教材翻。它核心是让你理解微服务怎么划分谷粒商城把后台拆成商品、订单、库存、会员、营销等多个服务每个服务独立数据库。真正要落地的动作只有两个准备虚拟机用 Docker 把 MySQL、Redis、Nginx 这些基础组件拉起来。我在复现时用 Vagrant 起 CentOS7虚拟机内存给到 8G磁盘 50G。因为后面要同时跑 Nacos、Seata、ES、RabbitMQ、ShardingSphere内存小于 6G 基本会卡到怀疑人生。Vagrant 配置最关键的两个参数是config.vm.box centos/7 config.vm.memory 8192 config.vm.cpus 4memory单位是 MBcpus建议给 4 核我在 2 核机器上跑过编译一次前台项目能等一分钟心态容易崩。如果你用的是 VMware Workstation 或 VirtualBox自己建虚拟机也行镜像选 CentOS 7 或 8 都可以重点是磁盘容量要开够Docker 镜像和日志都很占空间。基础组件我用 docker-compose 统一管理一套起步配置长这样version: 3 services: mysql: image: mysql:8.0 container_name: mall-mysql ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root volumes: - ./mysql/data:/var/lib/mysql redis: image: redis:6.2 container_name: mall-redis ports: - 6379:6379 command: redis-server --appendonly yes这里有三个点容易踩坑。第一MySQL 8.0 默认密码认证插件是caching_sha2_password客户端连不上时要么在容器内执行ALTER USER root% IDENTIFIED WITH mysql_native_password BY root要么直接换 5.7 镜像。第二ports 里宿主机端口和容器端口都要写不然外部只能进容器内部访问。第三volumes 必须挂否则容器一删数据全没属于没有后悔药的教训。Redis 那段command里的--appendonly yes是开启 AOF 持久化开发环境下建议开省得重启后缓存里的热点数据全丢。提示镜像版本按你自己环境调整mysql:8.0 和 redis:6.2 只是我身边用得最多的组合不代表课件指定版本。基础篇里还带了一张《谷粒商城-分布式基础-图.pdf》这张架构图是整套资料的灵魂。我把它单独存下来遇到的调用关系不清时就看一眼比翻任何一段文字都高效。建议你也单独摘出来后面每一步都用得上。2.2 SpringCloud 组件与商品服务Nacos、Feign、Gateway 是如何分工的《02、SpringCloud组件.pdf》和《04、商品服务.pdf》是配套的。组件课件讲选型商品服务课件讲真实业务里怎么协作商品服务是基础数据服务被订单、购物车、搜索等上层服务调用。核心链路是“服务注册、服务发现、远程调用、网关路由”。谷粒商城的注册中心和配置中心用 Nacos服务间调用走 Feign外部请求先过 Gateway。你至少要能写出一份正确的服务注册配置spring: application: name: product-service cloud: nacos: discovery: server-addr: 192.168.56.101:8848spring.application.name必须是全系统唯一的服务名Nacos 页面里服务列表靠它区分重复注册会让调用方拉错实例。server-addr要填虚拟机实际 IP不要图省事写 localhost否则服务注册到 Nacos 的是 127.0.0.1其他服务根本调不通。网关和它是两个服务别写到同一份 yaml 里。网关侧核心配置是路由表spring: cloud: gateway: routes: - id: product_route uri: lb://product-service predicates: - Path/api/product/**uri用lb://前缀表示走客户端负载均衡后面跟服务名不要写死 IP否则多实例部署直接失效。Path断言里**表示匹配该路径下的所有子路径。我验证这套链路时按“先注册、再发现、后调用”三步走先在 Nacos 服务列表里看到 product-service再在另一个服务里用 Feign 调它的接口最后才配网关路径。顺序反了出了问题都不知道该查哪一层。Feign 调用还有一组容易忽略的超时参数ribbon: ConnectTimeout: 3000 ReadTimeout: 5000ConnectTimeout是建立连接超时ReadTimeout是等待响应超时。商品详情接口如果内部有慢查询这两个值设太小会频繁超时设太大又可能拖垮线程池。我一般先把 ReadTimeout 调到 5000压测后看平均响应时间再收紧。如果你用的是新版 Spring Cloud LoadBalancer这套 Ribbon 配置可能不生效需要到 feign client 里单独设置超时但思路是一样的。商品服务课件里的 SPU、SKU、属性分组属于电商领域知识不是技术难点却是业务难点。看的时候顺着实体类把几张核心表建出来搞清楚 spu_id 对应几个 sku_id、哪些属性是规格参数、哪些是销售属性后面 ES 检索和购物车都要依赖这个模型。只读文字不建表大概率看完就忘。2.3 前端基础与 Thymeleaf花最少时间拿到够用的部分《03、前端开发基础知识.pdf》和usingthymeleaf这两份定位特殊。谷粒商城后台管理页面是 Vue ElementUI 技术栈所以前端课件讲 ES6、Vue 基础语法、组件通信、axios 封装。如果你的目标是“把后端接口调通”花一个下午速刷就行不必钻组件源码。需要动手验证的部分是能看懂.vue单文件组件、知道 created 和 mounted 的区别、会用 axios 调接口。usingthymeleaf是服务端渲染模板前台页面里确实有用但如果走前后端分离这份可以先放。我的习惯是前端课件只看两遍一遍扫目录一遍照着做一个最小 demo。后面真的遇到页面渲染再回来查也不迟。基础章的目标就一条——把商品服务相关接口跑通别在视图层耗太多时间高级篇那些分布式问题才是真正拉开差距的地方。3. 高级篇硬骨头分布式事务、幂等、缓存与锁的取舍3.1 本地事务与分布式事务Seata 的边界条件《03、本地事务分布式事务.pdf》在高级篇里最容易被忽略但最关键。下单链路跨了订单、库存、积分多个服务单体时代的Transactional一拆微服务就失效。课件先讲本地事务边界再引出分布式事务方案2PC、TCC、Saga、Seata AT。谷粒商城落地用的是 Seata核心思想是“用全局事务 ID 把多个服务的本地事务串起来”。我在订单服务里先写一个入口验证全局事务GlobalTransactional(name create-order, rollbackFor Exception.class) public void createOrder(OrderCreateRequest request) { orderService.insert(request); inventoryService.deduct(request.getSkuId(), request.getCount()); couponService.markUsed(request.getCouponId()); }GlobalTransactional是 Seata 注解name 是事务名rollbackFor 指定触发全局回滚的异常类型。三个子调用任意一个抛异常Seata 协调所有参与服务回滚。参与的服务必须都接入 Seata否则全局事务只回滚本服务其他服务的脏数据就留在库里等对账时才发现那种问题排查成本比写代码高多了。另外本地要先启动 seata-server否则注解根本不会生效这一点课件里容易一带而过。选型上我的建议是链路短、一致性要求极高的场景用 AT 模式侵入小、回滚靠 undo_log不能接受数据库额外表的场景再考虑 TCC。不过最终都要压测说话课件给的是标准答案实际参数要结合机器决定。内存小就少开 Seata 连接池别把 Tomcat 线程池挤到无响应。3.2 接口幂等性与分布式锁订单防重和库存扣减《02、接口幂等性.pdf》单独成章有道理。任何一个商城项目订单提交、支付回调、优惠券领取都有重复请求。幂等性要求同一请求执行一次和执行多次结果一致。常见方案有唯一索引、状态机、Token 机制、幂等表。下单场景我推荐“唯一业务键 幂等表”成本最低、效果最直接CREATE TABLE order_idempotent ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL, service_name VARCHAR(32) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_biz_service (biz_id, service_name) );biz_id存业务幂等键比如订单号service_name存服务名。插入成功才继续执行后续逻辑插入撞唯一键冲突就返回成功。这个表只做“处理过没有”的判断数据量不大。biz_id必须是能唯一代表一次业务动作的键不能随便拿请求头或普通字段凑数否则会误拦正常请求。《05、缓存分布式锁.pdf》解决的是“读多写少”和“写并发互斥”。缓存扛读压力扛不住写并发库存扣减、优惠券数量这类互斥场景要用分布式锁。Redisson 把锁粒度细化到业务资源上RLock lock redissonClient.getLock(lock:sku: skuId); boolean locked lock.tryLock(3, 10, TimeUnit.SECONDS); if (locked) { try { int remain stockService.getRemain(skuId); if (remain count) { stockService.deduct(skuId, count); } } finally { lock.unlock(); } }tryLock第一个参数是等待锁时间第二个是自动释放时间单位秒。等待时间设太短竞争激烈直接放弃设太长请求排队严重。finally 里的unlock()必须执行否则锁自动释放时业务还在跑数据照样崩。锁 key 要带业务维度lock:sku:1001和lock:sku:1002不互相阻塞这是提升并发的第一步。课件还会讲缓存穿透、击穿、雪崩这几个坑我到第 5 章展开讲。3.3 异步与线程池别把性能优化做成 SQL 玄学《04、性能与压力测试.pdf》和《07、异步线程池.pdf》是配套的。接口慢不要第一反应去调 SQL先压测定位瓶颈。常见路径是先用 JMeter 打满一个接口看 TPS 和平均响应时间再去看数据库慢查询、GC 日志、连接数。我遇到最典型的场景商品详情页查商品基本信息、库存、营销活动三个服务同步调用加起来 800ms压测直接不过。优化方向是异步编排用CompletableFuture把没有依赖关系的调用并行执行总耗时从串行变成最慢链路的时间。线程池要单独定义不要用Executors.newFixedThreadPool它的队列无界高并发下内存会被堆满。我一般这样配ThreadPoolExecutor pool new ThreadPoolExecutor( 10, 20, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100), new ThreadFactoryBuilder().setNameFormat(detail-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() );核心线程 10最大 20队列容量 100。队列满以后拒绝策略用CallerRunsPolicy让提交任务的线程自己执行削峰更平滑不会直接抛异常。线程名前缀写detail-pool-%d这是压测后看线程栈时养成的习惯否则分不清是哪个池的线程。参数不要照着抄先用压测报告定基线再调核心线程和队列长度。线程池调参没有银弹只能一个场景一个场景试。4. 中间件实战ElasticSearch、RabbitMQ、ShardingSphere 的参数边界4.1 ElasticSearch商品检索的索引与查询怎么定义《06、ElasticSearch.pdf》内容比较深因为 ES 不仅承担搜索还要做商品列表的筛选、排序、分词匹配。看课件先把 mapping 结构吃透再谈查询。商品索引典型字段配置{ mappings: { properties: { skuId: { type: keyword }, skuTitle: { type: text, analyzer: ik_max_word }, price: { type: double }, categoryPath: { type: keyword } } } }skuId用keyword只做精确匹配skuTitle用text配ik_max_word用户搜“手机”能命中“新款手机 5G”。price留给范围查询categoryPath存分类路径过滤时走 keyword。最容易翻车的点是 mapping 里字段类型一旦定义就不能修改要加字段基本要靠 reindex 建新索引。所以“先设计索引再写业务”不是口号。查询侧核心是 bool 查询分类过滤、品牌过滤、价格区间、关键词组合。重点是区分match和filtermatch 参与相关性打分filter 只过滤不参与打分。商品筛选场景尽量把过滤条件放 filter 上下文性能和分数都更稳。课件里如果提到聚合先看懂terms聚合品牌列表和分类列表都是用它做的。4.2 RabbitMQ订单超时关单的延迟队列怎么配《10、RabbitMQ.pdf》常见落地场景两个订单超时未支付自动关单、商品上下架后通知搜索服务更新索引。前者用延迟队列后者用广播或路由。RabbitMQ 原生不支持指定延迟时间常见做法是“TTL 死信队列”——消息先发到设置 TTL 的队列超时后被投递到死信交换机最终进业务队列。关键配置Bean public Queue orderDelayQueue() { return QueueBuilder.durable(order.delay.queue) .ttl(60000) .deadLetterExchange(order.exchange) .deadLetterRoutingKey(order.close) .build(); }ttl是队列级消息存活时间单位毫秒60000 就是 60 秒。deadLetterExchange和deadLetterRoutingKey指定死信去向业务消费者监听order.close最终拿到超时消息。这里有个容易被忽略的细节队列级 TTL 在队列里有不同延迟时会出现“头阻塞”排在前面的消息不超时后面的消息即使超时了也投不出去。不同延迟时间要建不同队列不要偷懒公用一个。如果要精细控制每一条消息的延迟时间需要改用 per-message TTL 或者延迟插件但整体思路不变。消息可靠投递分三段生产者到交换机、交换机到队列、队列到消费者。只开 confirm 不解决消费者丢消息。我血泪经验是消费者业务处理成功后必须手动 ack配合幂等表才能扛住重复消费。课件如果画了 RabbitMQ 架构图记得把“手动 ack”和“死信”标在图上这两处最容易在实际项目里翻车。4.3 ShardingSphere分片键和绑定表怎么设计才不翻车《13、ShardingSphere.pdf》是高级篇里偏进阶的一份。订单表不到千万级其实不用拆但课件既然讲了至少要理解分片键、分片算法、广播表、绑定表这组概念。订单表最常见分片键是user_id或order_id。用user_id的好处是同一用户订单都在一个库查用户订单列表不用聚合。rules: - !SHARDING tables: t_order: actualDataNodes: ds$-{0..1}.t_order_$-{0..1} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: user_id_mod keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: user_id_mod: type: INLINE props: algorithm-expression: t_order_$-{user_id % 2}actualDataNodes表示两个数据源、每库两张物理表。shardingColumn必须出现在 SQL 的 where 条件里否则 ShardingSphere 不知道路由到哪张表只能全路由性能直接崩。algorithm-expression里的% 2是取模分片简单但容易造成数据倾斜热点用户集中在一个分片。课件如果讲广播表和绑定表意思是公共表和强关联表要跟主表用同样的分片方式或者广播全库否则 join 查不到数据。这个设计要尽早和 DBA 对齐不是开发一个人能定的。5. 常见问题排查服务调不通、压测不过、支付回调重复5.1 服务调不通先查注册中心Nacos 注册的是容器内网 IP现象本地商品服务起好了Nacos 服务列表里能看到但订单服务远程调用一直连接被拒日志里报 ConnectException。原因服务跑在 Docker 容器里时默认注册的 IP 是容器网段地址比如 172.17.0.x宿主机以外的环境访问不到另一种是把server-addr配成 localhost注册地址变成 127.0.0.1别的服务一样调不通。解决在 Nacos discovery 配置里显式指定ip为宿主机 IP容器启动加--network host或者把端口映射写明确。排查顺序固定在“看 Nacos 服务列表里的 IP → 用 telnet 探端口 → 再看业务日志”九成服务调不通都能定位在这一层。5.2 压测不过线程池和数据库连接池在抢资源现象JMeter 压测刚开始 TPS 还算正常不到一分钟大面积超时日志出现HikariPool-1 - Connection is not available。原因默认的数据库连接池和 Tomcat 线程池都偏小接口一并发Tomcat 线程全阻塞在等数据库连接队列越长雪崩越快。解决先按第 3 章拆并行调用再把 HikariCP 调到合适的值spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 leak-detection-threshold: 60000maximum-pool-size是最大连接数不要超过数据库实例能承受的上限leak-detection-threshold开启连接泄露检测60 秒没归还就告警这对排查慢 SQL 和连接泄漏非常有用。压测是逐步加压的过程每轮记录 TPS、响应时间、错误率再调线程池和连接池千万别上来就开 500 线程。5.3 支付回调重复通知状态机少了中间态现象支付平台回调会重试多次大部分时候能正常入账但偶尔出现已支付订单被后续回调重复处理甚至把“已发货”状态又改回“已支付”。原因回调处理逻辑直接用update order set status paid没有校验订单当前状态。重复通知不可怕可怕的是没有状态流转校验。解决给订单状态机加前置条件更新 SQL 带上当前状态UPDATE order_info SET status PAID, pay_time NOW() WHERE order_no #{orderNo} AND status WAIT_PAY影响 0 行就直接返回成功给支付平台不做任何业务操作。这个兜底让我少接了很多对账电话。支付回调里再叠加一层幂等查询双保险更稳。5.4 K8S 部署翻车镜像 tag 和健康检查配置现象Pod 一直ImagePullBackOff或者起来后反复CrashLoopBackOff页面时好时坏。原因镜像 tag 写错或本地没有该 tagK8S 拉不到镜像Deployment 只配置了资源限制没配健康检查服务端口没就绪就被打进负载均衡。解决镜像 tag 固定用 commit short sha不要用 latest避免不同环境拉到的镜像不一致。Deployment 里配好探针readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10readiness 探针控制服务是否接收流量liveness 探针决定容器是否重启。两个必须配否则发布时流量已经切过来但服务还没就绪一样报错。运维篇《K8S部署DevOps.pdf》里的流水线我不建议照抄先手工把 Deployment 和 Service 跑通再上 Jenkins 或 GitLab CI一步到位容易翻大车。5.5 缓存穿透、击穿、雪崩不要背概念要看 miss 日志现象缓存命中率很高但数据库某段时间 QPS 突然飙升接口响应时间明显拉长。原因热点 key 过期瞬间被大量请求打到数据库是击穿查询参数在库里不存在导致缓存一直 miss 是穿透大量 key 同一时间过期是雪崩。三个现象经常一起出现只背概念分不清实际是哪一种。解决在缓存访问层打 miss 日志按 key 的分布和过期时间定位。空值也缓存 60 秒解决穿透热点 key 加随机过期时间解决雪崩并发极高的 key 用 Redisson 互斥锁控制回源只让一个线程去查库。String value stringRedisTemplate.opsForValue().get(key); if (value null) { RLock lock redissonClient.getLock(lock:cache: key); lock.lock(3, TimeUnit.SECONDS); try { value stringRedisTemplate.opsForValue().get(key); if (value null) { value loadFromDatabase(key); stringRedisTemplate.opsForValue().set(key, value, 300 RandomUtil.randomInt(60), TimeUnit.SECONDS); } } finally { lock.unlock(); } }代码里先查一次缓存加锁后再查一次这叫双重检查避免重复回源。过期时间 300 秒加 0 到 60 秒随机值防止雪崩。这个 pattern 课件里会有但很容易被忽略真遇到线上事故时它就是后悔药。6. 进阶用法把课件重排成自己的项目清单配一张速查表拿到课件别从头刷到尾。我第二次看谷粒商城换了一种方式先花半小时把全部 PDF 按“环境 → 骨架 → 业务 → 中间件 → 上线”五步重排每份课件对应一个可验证目标。环境阶段目标是docker ps能看到 mysql 和 redis中间件阶段目标是“用 ES 搜到商品、用 RabbitMQ 关掉超时订单”。目标不是“看完 PDF”而是“跑通一个命令或接口”。我给自己做了一张速查表你也按这个格式做| 学习阶段 | 对应课件 | 验收动作 | | 环境 | 01 分布式基础 | docker ps 能看到 mysql/redis | | 骨架 | 02 SpringCloud 组件 | Nacos 服务列表有 product-service | | 业务 | 04 商品服务 | 接口返回 sku 详情 | | 中间件 | 06 ElasticSearch、10 RabbitMQ | 搜索命中商品超时订单自动关闭 | | 运维 | K8S 部署 DevOps | 部署后健康检查通过 |每份课件读两遍第一遍只看标题和架构图画出与别章的关系第二遍只补自己缺的参数细节。然后把所有架构图截图汇总成一张总图标出调用关系。面试被问到部署链路时你能直接对着图说不用现场翻 PDF。最后把各课件里零散的配置片段汇总成一个deploy.sh和一份配置清单以后重装环境直接跑脚本。从那以后我拿到任何项目课件都强制先做重排先跑通再深挖整个过程自己心里也踏实。希望帮到你。本文还有配套的精品资源点击获取 简介这一压缩包是谷粒商城电商实战项目的全阶段课件合集面向正在系统学习微服务、分布式架构与云原生部署的Java后端开发者也适合培训讲师、高校学员作为课程串讲与项目复盘材料。资料按基础篇、运维篇、高级篇三个目录层次组织基础篇覆盖分布式基础、项目环境搭建、SpringCloud组件、前端基础与商品服务运维篇提供K8s部署与DevOps落地课件。高级篇则深入响应式编程、接口幂等性、本地与分布式事务、性能压测、缓存与分布式锁、ElasticSearch检索、异步与线程池、单点登录、RabbitMQ消息队列、支付、定时任务及ShardingSphere分库分表等核心专题三篇合计20余份PDF课件压缩包约33.51MB目录层级清晰便于定位。目前已有2090人学习浏览整套内容串联从环境搭建到生产级组件落地的完整链路PDF课件按专题拆分、层次分明既可用于日常复习也可作为项目复盘与面试梳理的浓缩材料。1. 谷粒商城课件到底讲什么先确认这份资料适不适合你我第二次打开这份谷粒商城课件时才意识到它比我想象中厚实得多。目录从分布式基础一路排到 K8S 部署三十份左右的 PDF 把电商项目的骨架拆成三个层次基础篇讲环境搭建、SpringCloud 组件、商品服务高级篇把事务、幂等、缓存、ElasticSearch、RabbitMQ、ShardingSphere 这些硬骨头单独拎出来运维篇负责容器化部署和 DevOps。它解决的核心问题不是“看懂概念”而是“照着把一个微服务商城搭起来”。适合做毕设、补分布式实战经验、或者面试前想系统性过一遍项目细节的人。下面按我实际复现时的顺序讲讲每份课件该怎么看、参数怎么设、坑在哪。2. 基础篇落地顺序环境、注册中心、网关先跑通再学业务2.1 分布式基础与环境搭建先把能跑的服务跑起来《01、分布式基础项目环境搭建.pdf》我建议第一个读但不要逐页当教材翻。它核心是让你理解微服务怎么划分谷粒商城把后台拆成商品、订单、库存、会员、营销等多个服务每个服务独立数据库。真正要落地的动作只有两个准备虚拟机用 Docker 把 MySQL、Redis、Nginx 这些基础组件拉起来。我在复现时用 Vagrant 起 CentOS7虚拟机内存给到 8G磁盘 50G。因为后面要同时跑 Nacos、Seata、ES、RabbitMQ、ShardingSphere内存小于 6G 基本会卡到怀疑人生。Vagrant 配置最关键的两个参数是config.vm.box centos/7 config.vm.memory 8192 config.vm.cpus 4memory单位是 MBcpus建议给 4 核我在 2 核机器上跑过编译一次前台项目能等一分钟心态容易崩。如果你用的是 VMware Workstation 或 VirtualBox自己建虚拟机也行镜像选 CentOS 7 或 8 都可以重点是磁盘容量要开够Docker 镜像和日志都很占空间。基础组件我用 docker-compose 统一管理一套起步配置长这样version: 3 services: mysql: image: mysql:8.0 container_name: mall-mysql ports: - 3306:3306 environment: MYSQL_ROOT_PASSWORD: root volumes: - ./mysql/data:/var/lib/mysql redis: image: redis:6.2 container_name: mall-redis ports: - 6379:6379 command: redis-server --appendonly yes这里有三个点容易踩坑。第一MySQL 8.0 默认密码认证插件是caching_sha2_password客户端连不上时要么在容器内执行ALTER USER root% IDENTIFIED WITH mysql_native_password BY root要么直接换 5.7 镜像。第二ports 里宿主机端口和容器端口都要写不然外部只能进容器内部访问。第三volumes 必须挂否则容器一删数据全没属于没有后悔药的教训。Redis 那段command里的--appendonly yes是开启 AOF 持久化开发环境下建议开省得重启后缓存里的热点数据全丢。提示镜像版本按你自己环境调整mysql:8.0 和 redis:6.2 只是我身边用得最多的组合不代表课件指定版本。基础篇里还带了一张《谷粒商城-分布式基础-图.pdf》这张架构图是整套资料的灵魂。我把它单独存下来遇到的调用关系不清时就看一眼比翻任何一段文字都高效。建议你也单独摘出来后面每一步都用得上。2.2 SpringCloud 组件与商品服务Nacos、Feign、Gateway 是如何分工的《02、SpringCloud组件.pdf》和《04、商品服务.pdf》是配套的。组件课件讲选型商品服务课件讲真实业务里怎么协作商品服务是基础数据服务被订单、购物车、搜索等上层服务调用。核心链路是“服务注册、服务发现、远程调用、网关路由”。谷粒商城的注册中心和配置中心用 Nacos服务间调用走 Feign外部请求先过 Gateway。你至少要能写出一份正确的服务注册配置spring: application: name: product-service cloud: nacos: discovery: server-addr: 192.168.56.101:8848spring.application.name必须是全系统唯一的服务名Nacos 页面里服务列表靠它区分重复注册会让调用方拉错实例。server-addr要填虚拟机实际 IP不要图省事写 localhost否则服务注册到 Nacos 的是 127.0.0.1其他服务根本调不通。网关和它是两个服务别写到同一份 yaml 里。网关侧核心配置是路由表spring: cloud: gateway: routes: - id: product_route uri: lb://product-service predicates: - Path/api/product/**uri用lb://前缀表示走客户端负载均衡后面跟服务名不要写死 IP否则多实例部署直接失效。Path断言里**表示匹配该路径下的所有子路径。我验证这套链路时按“先注册、再发现、后调用”三步走先在 Nacos 服务列表里看到 product-service再在另一个服务里用 Feign 调它的接口最后才配网关路径。顺序反了出了问题都不知道该查哪一层。Feign 调用还有一组容易忽略的超时参数ribbon: ConnectTimeout: 3000 ReadTimeout: 5000ConnectTimeout是建立连接超时ReadTimeout是等待响应超时。商品详情接口如果内部有慢查询这两个值设太小会频繁超时设太大又可能拖垮线程池。我一般先把 ReadTimeout 调到 5000压测后看平均响应时间再收紧。如果你用的是新版 Spring Cloud LoadBalancer这套 Ribbon 配置可能不生效需要到 feign client 里单独设置超时但思路是一样的。商品服务课件里的 SPU、SKU、属性分组属于电商领域知识不是技术难点却是业务难点。看的时候顺着实体类把几张核心表建出来搞清楚 spu_id 对应几个 sku_id、哪些属性是规格参数、哪些是销售属性后面 ES 检索和购物车都要依赖这个模型。只读文字不建表大概率看完就忘。2.3 前端基础与 Thymeleaf花最少时间拿到够用的部分《03、前端开发基础知识.pdf》和usingthymeleaf这两份定位特殊。谷粒商城后台管理页面是 Vue ElementUI 技术栈所以前端课件讲 ES6、Vue 基础语法、组件通信、axios 封装。如果你的目标是“把后端接口调通”花一个下午速刷就行不必钻组件源码。需要动手验证的部分是能看懂.vue单文件组件、知道 created 和 mounted 的区别、会用 axios 调接口。usingthymeleaf是服务端渲染模板前台页面里确实有用但如果走前后端分离这份可以先放。我的习惯是前端课件只看两遍一遍扫目录一遍照着做一个最小 demo。后面真的遇到页面渲染再回来查也不迟。基础章的目标就一条——把商品服务相关接口跑通别在视图层耗太多时间高级篇那些分布式问题才是真正拉开差距的地方。3. 高级篇硬骨头分布式事务、幂等、缓存与锁的取舍3.1 本地事务与分布式事务Seata 的边界条件《03、本地事务分布式事务.pdf》在高级篇里最容易被忽略但最关键。下单链路跨了订单、库存、积分多个服务单体时代的Transactional一拆微服务就失效。课件先讲本地事务边界再引出分布式事务方案2PC、TCC、Saga、Seata AT。谷粒商城落地用的是 Seata核心思想是“用全局事务 ID 把多个服务的本地事务串起来”。我在订单服务里先写一个入口验证全局事务GlobalTransactional(name create-order, rollbackFor Exception.class) public void createOrder(OrderCreateRequest request) { orderService.insert(request); inventoryService.deduct(request.getSkuId(), request.getCount()); couponService.markUsed(request.getCouponId()); }GlobalTransactional是 Seata 注解name 是事务名rollbackFor 指定触发全局回滚的异常类型。三个子调用任意一个抛异常Seata 协调所有参与服务回滚。参与的服务必须都接入 Seata否则全局事务只回滚本服务其他服务的脏数据就留在库里等对账时才发现那种问题排查成本比写代码高多了。另外本地要先启动 seata-server否则注解根本不会生效这一点课件里容易一带而过。选型上我的建议是链路短、一致性要求极高的场景用 AT 模式侵入小、回滚靠 undo_log不能接受数据库额外表的场景再考虑 TCC。不过最终都要压测说话课件给的是标准答案实际参数要结合机器决定。内存小就少开 Seata 连接池别把 Tomcat 线程池挤到无响应。3.2 接口幂等性与分布式锁订单防重和库存扣减《02、接口幂等性.pdf》单独成章有道理。任何一个商城项目订单提交、支付回调、优惠券领取都有重复请求。幂等性要求同一请求执行一次和执行多次结果一致。常见方案有唯一索引、状态机、Token 机制、幂等表。下单场景我推荐“唯一业务键 幂等表”成本最低、效果最直接CREATE TABLE order_idempotent ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL, service_name VARCHAR(32) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_biz_service (biz_id, service_name) );biz_id存业务幂等键比如订单号service_name存服务名。插入成功才继续执行后续逻辑插入撞唯一键冲突就返回成功。这个表只做“处理过没有”的判断数据量不大。biz_id必须是能唯一代表一次业务动作的键不能随便拿请求头或普通字段凑数否则会误拦正常请求。《05、缓存分布式锁.pdf》解决的是“读多写少”和“写并发互斥”。缓存扛读压力扛不住写并发库存扣减、优惠券数量这类互斥场景要用分布式锁。Redisson 把锁粒度细化到业务资源上RLock lock redissonClient.getLock(lock:sku: skuId); boolean locked lock.tryLock(3, 10, TimeUnit.SECONDS); if (locked) { try { int remain stockService.getRemain(skuId); if (remain count) { stockService.deduct(skuId, count); } } finally { lock.unlock(); } }tryLock第一个参数是等待锁时间第二个是自动释放时间单位秒。等待时间设太短竞争激烈直接放弃设太长请求排队严重。finally 里的unlock()必须执行否则锁自动释放时业务还在跑数据照样崩。锁 key 要带业务维度lock:sku:1001和lock:sku:1002不互相阻塞这是提升并发的第一步。课件还会讲缓存穿透、击穿、雪崩这几个坑我到第 5 章展开讲。3.3 异步与线程池别把性能优化做成 SQL 玄学《04、性能与压力测试.pdf》和《07、异步线程池.pdf》是配套的。接口慢不要第一反应去调 SQL先压测定位瓶颈。常见路径是先用 JMeter 打满一个接口看 TPS 和平均响应时间再去看数据库慢查询、GC 日志、连接数。我遇到最典型的场景商品详情页查商品基本信息、库存、营销活动三个服务同步调用加起来 800ms压测直接不过。优化方向是异步编排用CompletableFuture把没有依赖关系的调用并行执行总耗时从串行变成最慢链路的时间。线程池要单独定义不要用Executors.newFixedThreadPool它的队列无界高并发下内存会被堆满。我一般这样配ThreadPoolExecutor pool new ThreadPoolExecutor( 10, 20, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(100), new ThreadFactoryBuilder().setNameFormat(detail-pool-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() );核心线程 10最大 20队列容量 100。队列满以后拒绝策略用CallerRunsPolicy让提交任务的线程自己执行削峰更平滑不会直接抛异常。线程名前缀写detail-pool-%d这是压测后看线程栈时养成的习惯否则分不清是哪个池的线程。参数不要照着抄先用压测报告定基线再调核心线程和队列长度。线程池调参没有银弹只能一个场景一个场景试。4. 中间件实战ElasticSearch、RabbitMQ、ShardingSphere 的参数边界4.1 ElasticSearch商品检索的索引与查询怎么定义《06、ElasticSearch.pdf》内容比较深因为 ES 不仅承担搜索还要做商品列表的筛选、排序、分词匹配。看课件先把 mapping 结构吃透再谈查询。商品索引典型字段配置{ mappings: { properties: { skuId: { type: keyword }, skuTitle: { type: text, analyzer: ik_max_word }, price: { type: double }, categoryPath: { type: keyword } } } }skuId用keyword只做精确匹配skuTitle用text配ik_max_word用户搜“手机”能命中“新款手机 5G”。price留给范围查询categoryPath存分类路径过滤时走 keyword。最容易翻车的点是 mapping 里字段类型一旦定义就不能修改要加字段基本要靠 reindex 建新索引。所以“先设计索引再写业务”不是口号。查询侧核心是 bool 查询分类过滤、品牌过滤、价格区间、关键词组合。重点是区分match和filtermatch 参与相关性打分filter 只过滤不参与打分。商品筛选场景尽量把过滤条件放 filter 上下文性能和分数都更稳。课件里如果提到聚合先看懂terms聚合品牌列表和分类列表都是用它做的。4.2 RabbitMQ订单超时关单的延迟队列怎么配《10、RabbitMQ.pdf》常见落地场景两个订单超时未支付自动关单、商品上下架后通知搜索服务更新索引。前者用延迟队列后者用广播或路由。RabbitMQ 原生不支持指定延迟时间常见做法是“TTL 死信队列”——消息先发到设置 TTL 的队列超时后被投递到死信交换机最终进业务队列。关键配置Bean public Queue orderDelayQueue() { return QueueBuilder.durable(order.delay.queue) .ttl(60000) .deadLetterExchange(order.exchange) .deadLetterRoutingKey(order.close) .build(); }ttl是队列级消息存活时间单位毫秒60000 就是 60 秒。deadLetterExchange和deadLetterRoutingKey指定死信去向业务消费者监听order.close最终拿到超时消息。这里有个容易被忽略的细节队列级 TTL 在队列里有不同延迟时会出现“头阻塞”排在前面的消息不超时后面的消息即使超时了也投不出去。不同延迟时间要建不同队列不要偷懒公用一个。如果要精细控制每一条消息的延迟时间需要改用 per-message TTL 或者延迟插件但整体思路不变。消息可靠投递分三段生产者到交换机、交换机到队列、队列到消费者。只开 confirm 不解决消费者丢消息。我血泪经验是消费者业务处理成功后必须手动 ack配合幂等表才能扛住重复消费。课件如果画了 RabbitMQ 架构图记得把“手动 ack”和“死信”标在图上这两处最容易在实际项目里翻车。4.3 ShardingSphere分片键和绑定表怎么设计才不翻车《13、ShardingSphere.pdf》是高级篇里偏进阶的一份。订单表不到千万级其实不用拆但课件既然讲了至少要理解分片键、分片算法、广播表、绑定表这组概念。订单表最常见分片键是user_id或order_id。用user_id的好处是同一用户订单都在一个库查用户订单列表不用聚合。rules: - !SHARDING tables: t_order: actualDataNodes: ds$-{0..1}.t_order_$-{0..1} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: user_id_mod keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: user_id_mod: type: INLINE props: algorithm-expression: t_order_$-{user_id % 2}actualDataNodes表示两个数据源、每库两张物理表。shardingColumn必须出现在 SQL 的 where 条件里否则 ShardingSphere 不知道路由到哪张表只能全路由性能直接崩。algorithm-expression里的% 2是取模分片简单但容易造成数据倾斜热点用户集中在一个分片。课件如果讲广播表和绑定表意思是公共表和强关联表要跟主表用同样的分片方式或者广播全库否则 join 查不到数据。这个设计要尽早和 DBA 对齐不是开发一个人能定的。5. 常见问题排查服务调不通、压测不过、支付回调重复5.1 服务调不通先查注册中心Nacos 注册的是容器内网 IP现象本地商品服务起好了Nacos 服务列表里能看到但订单服务远程调用一直连接被拒日志里报 ConnectException。原因服务跑在 Docker 容器里时默认注册的 IP 是容器网段地址比如 172.17.0.x宿主机以外的环境访问不到另一种是把server-addr配成 localhost注册地址变成 127.0.0.1别的服务一样调不通。解决在 Nacos discovery 配置里显式指定ip为宿主机 IP容器启动加--network host或者把端口映射写明确。排查顺序固定在“看 Nacos 服务列表里的 IP → 用 telnet 探端口 → 再看业务日志”九成服务调不通都能定位在这一层。5.2 压测不过线程池和数据库连接池在抢资源现象JMeter 压测刚开始 TPS 还算正常不到一分钟大面积超时日志出现HikariPool-1 - Connection is not available。原因默认的数据库连接池和 Tomcat 线程池都偏小接口一并发Tomcat 线程全阻塞在等数据库连接队列越长雪崩越快。解决先按第 3 章拆并行调用再把 HikariCP 调到合适的值spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 leak-detection-threshold: 60000maximum-pool-size是最大连接数不要超过数据库实例能承受的上限leak-detection-threshold开启连接泄露检测60 秒没归还就告警这对排查慢 SQL 和连接泄漏非常有用。压测是逐步加压的过程每轮记录 TPS、响应时间、错误率再调线程池和连接池千万别上来就开 500 线程。5.3 支付回调重复通知状态机少了中间态现象支付平台回调会重试多次大部分时候能正常入账但偶尔出现已支付订单被后续回调重复处理甚至把“已发货”状态又改回“已支付”。原因回调处理逻辑直接用update order set status paid没有校验订单当前状态。重复通知不可怕可怕的是没有状态流转校验。解决给订单状态机加前置条件更新 SQL 带上当前状态UPDATE order_info SET status PAID, pay_time NOW() WHERE order_no #{orderNo} AND status WAIT_PAY影响 0 行就直接返回成功给支付平台不做任何业务操作。这个兜底让我少接了很多对账电话。支付回调里再叠加一层幂等查询双保险更稳。5.4 K8S 部署翻车镜像 tag 和健康检查配置现象Pod 一直ImagePullBackOff或者起来后反复CrashLoopBackOff页面时好时坏。原因镜像 tag 写错或本地没有该 tagK8S 拉不到镜像Deployment 只配置了资源限制没配健康检查服务端口没就绪就被打进负载均衡。解决镜像 tag 固定用 commit short sha不要用 latest避免不同环境拉到的镜像不一致。Deployment 里配好探针readinessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 10 periodSeconds: 5 livenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 30 periodSeconds: 10readiness 探针控制服务是否接收流量liveness 探针决定容器是否重启。两个必须配否则发布时流量已经切过来但服务还没就绪一样报错。运维篇《K8S部署DevOps.pdf》里的流水线我不建议照抄先手工把 Deployment 和 Service 跑通再上 Jenkins 或 GitLab CI一步到位容易翻大车。5.5 缓存穿透、击穿、雪崩不要背概念要看 miss 日志现象缓存命中率很高但数据库某段时间 QPS 突然飙升接口响应时间明显拉长。原因热点 key 过期瞬间被大量请求打到数据库是击穿查询参数在库里不存在导致缓存一直 miss 是穿透大量 key 同一时间过期是雪崩。三个现象经常一起出现只背概念分不清实际是哪一种。解决在缓存访问层打 miss 日志按 key 的分布和过期时间定位。空值也缓存 60 秒解决穿透热点 key 加随机过期时间解决雪崩并发极高的 key 用 Redisson 互斥锁控制回源只让一个线程去查库。String value stringRedisTemplate.opsForValue().get(key); if (value null) { RLock lock redissonClient.getLock(lock:cache: key); lock.lock(3, TimeUnit.SECONDS); try { value stringRedisTemplate.opsForValue().get(key); if (value null) { value loadFromDatabase(key); stringRedisTemplate.opsForValue().set(key, value, 300 RandomUtil.randomInt(60), TimeUnit.SECONDS); } } finally { lock.unlock(); } }代码里先查一次缓存加锁后再查一次这叫双重检查避免重复回源。过期时间 300 秒加 0 到 60 秒随机值防止雪崩。这个 pattern 课件里会有但很容易被忽略真遇到线上事故时它就是后悔药。6. 进阶用法把课件重排成自己的项目清单配一张速查表拿到课件别从头刷到尾。我第二次看谷粒商城换了一种方式先花半小时把全部 PDF 按“环境 → 骨架 → 业务 → 中间件 → 上线”五步重排每份课件对应一个可验证目标。环境阶段目标是docker ps能看到 mysql 和 redis中间件阶段目标是“用 ES 搜到商品、用 RabbitMQ 关掉超时订单”。目标不是“看完 PDF”而是“跑通一个命令或接口”。我给自己做了一张速查表你也按这个格式做| 学习阶段 | 对应课件 | 验收动作 | | 环境 | 01 分布式基础 | docker ps 能看到 mysql/redis | | 骨架 | 02 SpringCloud 组件 | Nacos 服务列表有 product-service | | 业务 | 04 商品服务 | 接口返回 sku 详情 | | 中间件 | 06 ElasticSearch、10 RabbitMQ | 搜索命中商品超时订单自动关闭 | | 运维 | K8S 部署 DevOps | 部署后健康检查通过 |每份课件读两遍第一遍只看标题和架构图画出与别章的关系第二遍只补自己缺的参数细节。然后把所有架构图截图汇总成一张总图标出调用关系。面试被问到部署链路时你能直接对着图说不用现场翻 PDF。最后把各课件里零散的配置片段汇总成一个deploy.sh和一份配置清单以后重装环境直接跑脚本。从那以后我拿到任何项目课件都强制先做重排先跑通再深挖整个过程自己心里也踏实。希望帮到你。本文还有配套的精品资源点击获取