技术栈完善指南

完整技术栈清单

后端基础
├─ Java/Spring
├─ 数据库（MySQL/PostgreSQL）
└─ Linux/Shell

缓存层 (Redis)
├─ 基础数据类型操作
├─ 高级特性
│  ├─ 缓存策略（LRU/LFU）
│  ├─ 过期策略
│  ├─ 持久化（RDB/AOF）
│  └─ 集群方案（Cluster/Sentinel/Proxy）
├─ 缓存问题解决
│  ├─ 缓存击穿（热key、布隆过滤器）
│  ├─ 缓存穿透（数据库穿透）
│  ├─ 缓存雪崩（多层缓存、随机过期）
│  └─ 缓存一致性（Canal、MQ、延迟双删）
└─ 性能优化
   ├─ 连接池
   ├─ 序列化优化
   └─ 读写分离

消息队列 (MQ)
├─ Kafka
│  ├─ 高吞吐、大数据场景
│  ├─ 分布式、集群、副本机制
│  ├─ 消费者组、Offset管理
│  └─ 可靠性保证
├─ RabbitMQ
│  ├─ AMQP协议
│  ├─ 交换机、队列、绑定
│  ├─ 路由、延迟队列、死信队列
│  └─ 事务、确认机制
├─ RocketMQ
│  ├─ 高并发、可靠性强
│  ├─ 顺序消息、延迟消息
│  ├─ 事务消息
│  └─ 重试机制
└─ MQ通用问题
   ├─ 消息可靠性（生产端、消费端、Broker端）
   ├─ 防重复消费（幂等性、去重表）
   ├─ 消息堆积处理
   │  ├─ 提高消费速率
   │  ├─ 增加消费者实例
   │  └─ 流量削峰
   └─ 异常处理（重试、死信队列、告警）

微服务架构
├─ 服务拆分
│  ├─ 按功能拆分（DDD分层）
│  ├─ 按流量拆分
│  └─ 边界明确、低耦合
├─ 服务注册与发现
│  ├─ Nacos（注册中心+配置中心）✓
│  ├─ Eureka
│  └─ Consul
├─ 远程调用
│  ├─ OpenFeign（声明式调用）✓
│  ├─ RestTemplate
│  └─ gRPC、Dubbo
├─ 负载均衡
│  ├─ Ribbon（客户端）✓
│  ├─ 负载均衡策略（轮询、随机、最少连接）
│  └─ 权重、健康检查
├─ 熔断降级限流
│  ├─ Netflix Hystrix
│  │  ├─ 熔断、降级、限流
│  │  └─ 隔离策略（线程池/信号量）
│  ├─ Alibaba Sentinel ✓
│  │  ├─ 实时监控、可视化控制台
│  │  ├─ 流量控制
│  │  ├─ 熔断降级
│  │  └─ 热点参数限流
│  └─ Resilience4j
├─ 配置中心
│  ├─ Nacos ✓
│  ├─ Apollo
│  └─ Spring Cloud Config + Git
└─ 分布式事务
   ├─ Seata ✓
   │  ├─ AT模式（自动补偿）
   │  ├─ TCC模式（强一致性）
   │  └─ Saga模式（长事务）
   └─ 基于MQ的最终一致性

容器与编排
├─ Docker ✓
│  ├─ 镜像构建
│  ├─ 容器运行
│  ├─ 网络、存储
│  └─ Docker Compose
├─ Kubernetes
│  ├─ 基本概念（Pod、Service、Deployment）
│  ├─ 配置管理（ConfigMap、Secret）
│  ├─ 存储（PV、PVC）
│  ├─ 服务暴露（Ingress）
│  ├─ 自动扩容（HPA、VPA）
│  └─ 监控日志（Prometheus、ELK）
└─ 云原生
   ├─ Service Mesh（Istio）
   ├─ Serverless
   └─ GitOps

并发与性能
├─ 超卖问题（库存扣减）
│  ├─ 数据库悲观锁
│  ├─ 数据库乐观锁
│  ├─ Redis分布式锁
│  │  ├─ SET NX EX
│  │  ├─ Redisson
│  │  └─ 锁续期（看门狗机制）
│  ├─ 消息队列削峰
│  └─ 库存预热、扣减策略
├─ 高并发场景
│  ├─ 线程池优化
│  ├─ 异步处理（CompletableFuture、Reactor）
│  ├─ 流量削峰（MQ、限流）
│  └─ 缓存加速
└─ 秒杀方案
   ├─ 前端限流、倒计时
   ├─ 后端限流（Sentinel）
   ├─ MQ削峰
   ├─ Redis库存扣减
   └─ 异步处理订单

数据一致性
├─ 缓存与数据库一致性
│  ├─ Canal订阅Binlog
│  ├─ 延迟双删
│  ├─ MQ事件驱动
│  └─ TTL策略
├─ 分布式事务
│  └─ Seata
└─ 消息可靠性
   └─ 生产/消费/Broker确认

监控与运维
├─ 日志
│  ├─ ELK Stack
│  ├─ 链路追踪（SkyWalking/Jaeger）
│  └─ 日志聚合
├─ 监控
│  ├─ Prometheus + Grafana
│  ├─ 自定义指标
│  └─ 告警规则
├─ 性能诊断
│  ├─ JVM分析（heap dump、GC logs）
│  ├─ CPU profile
│  └─ 火焰图
└─ 服务健康检查
   ├─ 心跳机制
   └─ 健康端点

开发工具与最佳实践
├─ 版本控制：Git
├─ CI/CD：Jenkins、GitLab CI、GitHub Actions
├─ 代码质量：SonarQube
├─ 压测工具：JMeter、Apache AB、wrk
└─ 编写规范：阿里巴巴Java规范

选型优先级与引入时机

上面的清单是"全景地图"，不代表都要上。按项目阶段决定引入顺序，每个中间件都应有明确的问题驱动——先有问题，再引入对应组件：

阶段一：起步期（3 个服务以内，单库够用）

阶段二：并发与稳定性（出现慢查询、超时、偶发故障）

阶段三：规模化（多服务多库、数据量大）

判断"是否该引入"的三个问题

1. 现在的问题，不引入能不能忍？——能忍就先不引（复杂度是最贵的成本，呼应 02 篇"用最少复杂度获得核心价值"）
2. 引入后谁来运维？——没有维护人 = 引入一个未来故障源
3. 有没有更轻的替代？——要分布式锁先试数据库乐观锁，要搜索先试 SQL LIKE + 索引

项目分区导航：⬅️ 03-项目完整启动指南 | 04-技术栈完善指南 | ➡️ 00-实战项目