OSI 七层                    TCP/IP 四层          协议/设备示例
┌─────────────┐          ┌─────────────┐
│  应用层      │          │             │        HTTP, HTTPS, DNS,
│  表示层      │          │   应用层     │        SMTP, FTP, SSH,
│  会话层      │          │             │        WebSocket
├─────────────┤          ├─────────────┤
│  传输层      │          │   传输层     │        TCP, UDP
├─────────────┤          ├─────────────┤
│  网络层      │          │   网络层     │        IP, ICMP, 路由器
├─────────────┤          ├─────────────┤
│ 数据链路层    │          │ 网络接口层   │        MAC, ARP, 交换机
│  物理层      │          │             │        网线, 光纤, 集线器
└─────────────┘          └─────────────┘

三次握手（建立连接）：
Client                              Server
  │─────── SYN, seq=x ──────────────▶│
  │                                   │
  │◀── SYN+ACK, seq=y, ack=x+1 ──────│
  │                                   │
  │─────── ACK, ack=y+1 ────────────▶│
  │                                   │
  │         ESTABLISHED               │

为什么要三次？
- 防止已失效的连接请求到达服务端（历史连接问题）
- 确认双方的发送和接收能力都正常
- 同步双方的初始序列号 (ISN)

四次挥手（断开连接）：
Client                              Server
  │─────── FIN, seq=u ──────────────▶│  "我不发了"
  │◀────── ACK, ack=u+1 ─────────────│  "知道了"
  │                                   │
  │◀────── FIN, seq=v ───────────────│  "我也不发了"
  │─────── ACK, ack=v+1 ────────────▶│  "知道了"
  │                                   │
  │ 等待 2MSL → CLOSED                │

为什么四次？
- TCP 全双工，双方独立关闭
- 收到 FIN 只表示对方不再发数据，自己还可以继续发

为什么 TIME_WAIT 要等 2MSL？
- 确保最后的 ACK 能被对方收到
- 让旧连接的报文在网络中消失

┌─────────────────────────────────────────────────────────┐
│ 1. 可靠传输                                              │
│    ├─ 确认应答 (ACK) + 序列号 (seq)                       │
│    ├─ 超时重传 (RTO)                                     │
│    └─ 校验和                                              │
│                                                          │
│ 2. 流量控制（滑动窗口）                                    │
│    接收方告知自己的接收窗口大小 (rwnd)                      │
│    发送方根据 rwnd 控制发送速率                            │
│                                                          │
│ 3. 拥塞控制                                               │
│    ├─ 慢启动：cwnd 从 1 指数增长                          │
│    ├─ 拥塞避免：超过 ssthresh 后线性增长                   │
│    ├─ 快重传：收到 3 个重复 ACK 立即重传                   │
│    └─ 快恢复：不进入慢启动，直接进入拥塞避免                │
│                                                          │
│ 4. 粘包与拆包                                             │
│    原因：TCP 是流式协议，没有消息边界                       │
│    解决：定长消息 / 分隔符 / 消息头+消息体                  │
└─────────────────────────────────────────────────────────┘

HTTP/1.0：短连接，每次请求建 TCP
HTTP/1.1：持久连接 (Keep-Alive)，管道化（串行）
HTTP/2.0：多路复用、头部压缩 (HPACK)、服务器推送、二进制分帧
HTTP/3.0：基于 QUIC (UDP)，0-RTT 连接，彻底解决队头阻塞

TLS 1.3 握手流程（1-RTT）：
Client                                    Server
  │── ClientHello (密钥协商参数) ─────────▶│
  │◀── ServerHello + 证书 + Finished ──────│  ← 服务端先完成
  │── Finished ──────────────────────────▶│  ← 客户端完成，开始传输数据

                    总耗时：1 RTT（比 TLS 1.2 快 1 个 RTT）

核心概念：
- 非对称加密：交换对称密钥（RSA / ECDHE）
- 对称加密：加密数据（AES-GCM / ChaCha20）
- 数字证书：CA 签名，验证公钥归属
- 证书链：Root CA → 中间 CA → 网站证书

┌──────────────────────────────────────────────────────────┐
│                      进程 vs 线程                         │
├──────────────┬───────────────────┬───────────────────────┤
│    维度       │      进程          │       线程            │
├──────────────┼───────────────────┼───────────────────────┤
│ 资源         │ 独立资源（内存/文件）│ 共享进程资源            │
│ 创建开销      │ 大                 │ 小                    │
│ 通信         │ IPC(管道/共享内存)   │ 直接读写共享变量        │
│ 隔离性        │ 强（一个崩溃不影响） │ 弱（一个崩溃全挂）       │
│ 切换开销      │ 大                 │ 小                    │
│ 调度         │ 操作系统调度        │ 操作系统调度            │
└──────────────┴───────────────────┴───────────────────────┘

协程（Coroutine）：
- 用户态轻量级线程，调度由程序控制（非 OS）
- 切换开销极小（不需要内核态切换）
- Goroutine、async/await、Kotlin 协程

                    ┌──────────┐
                    │  创建     │
                    └────┬─────┘
                         │
                    ┌────▼─────┐
              ┌─────│  就绪    │◄────────────┐
              │     └────┬─────┘             │
              │          │ 调度              │
              │     ┌────▼─────┐   时间片到   │
              │     │  运行    │─────────────┘
              │     └────┬─────┘
              │          │ 等待事件
              │     ┌────▼─────┐
              │     │  阻塞    │
              │     └────┬─────┘
              │          │ 事件完成
              │          └────────┐
              │                  │
              │            ┌────▼─────┐
              └────────────│  终止    │
                           └──────────┘

虚拟地址空间布局（Linux 进程）：

高地址  ┌──────────────┐
        │   内核空间     │  (1GB, 不可直接访问)
        ├──────────────┤
        │   栈 (Stack)  │  ↓ 向下增长（局部变量、函数调用）
        │      ↓       │
        │              │
        │      ↑       │  ↑ 向上增长（动态分配）
        │   堆 (Heap)   │  malloc / new
        ├──────────────┤
        │   BSS 段      │  未初始化全局变量
        ├──────────────┤
        │   Data 段     │  已初始化全局变量
        ├──────────────┤
        │   Text 段     │  代码段（只读）
低地址  └──────────────┘

# === 系统信息 ===
uname -a          # 内核版本
cat /etc/os-release  # 系统版本
lscpu / free -h   # CPU / 内存
df -h / du -sh *  # 磁盘
top / htop        # 实时监控

# === 进程管理 ===
ps aux            # 所有进程
pstree            # 进程树
lsof -p <pid>     # 进程打开的文件
kill -9 <pid>     # 强制杀进程
kill -15 <pid>    # 优雅杀进程 (SIGTERM)
nohup cmd &       # 后台运行
jobs / fg / bg    # 作业控制

# === 网络 ===
ss -tlnp          # 监听端口
iptables -L       # 防火墙规则
tcpdump -i eth0 port 80  # 抓包
curl -v https://example.com
mtr example.com   # 路由追踪+丢包

# === 文件 ===
find / -name "*.log" -mtime -1
grep -r "ERROR" /var/log/
tail -f /var/log/app.log
chmod 755 / chown user:group
rsync -avz src/ dest/

# === 性能分析 ===
vmstat 1          # 虚拟内存统计
iostat -x 1       # 磁盘 I/O
sar -n DEV 1      # 网络流量
perf top          # CPU 性能分析
strace -p <pid>   # 跟踪系统调用

┌─────────────────────────────────────────────────────────┐
│ A — Atomicity (原子性)                                    │
│     事务是一个不可分割的单位，要么全做，要么全不做           │
│     实现：Undo Log                                       │
├─────────────────────────────────────────────────────────┤
│ C — Consistency (一致性)                                  │
│     事务执行前后，数据库从一种一致状态变为另一种            │
│     实现：约束、触发器、应用层逻辑                         │
├─────────────────────────────────────────────────────────┤
│ I — Isolation (隔离性)                                    │
│     并发事务之间互不干扰                                   │
│     实现：锁 (Lock) + MVCC（多版本并发控制）               │
├─────────────────────────────────────────────────────────┤
│ D — Durability (持久性)                                   │
│     事务一旦提交，即使系统崩溃也不丢失                      │
│     实现：Redo Log                                       │
└─────────────────────────────────────────────────────────┘

脏读      ：读到其他事务未提交的数据
不可重复读：同一事务两次读到同一行的值不同（被其他事务 UPDATE）
幻读      ：同一事务两次查询返回的结果行数不同（被其他事务 INSERT）

MVCC (Multi-Version Concurrency Control)：
- 每行数据有多个版本，每个事务看到的是特定的快照版本
- 写不阻塞读，读不阻塞写（读写不冲突）

MySQL InnoDB 实现：
┌────────┬──────────┬─────────────┐
│  DB_TRX_ID      │  DB_ROLL_PTR │  数据列...
│  (创建事务ID)    │  (回滚指针)   │
└────────┴──────────┴─────────────┘
                        │
                        ▼
              ┌─────────────────┐
              │   Undo Log      │
              │  (旧版本数据链)   │
              └─────────────────┘

ReadView：事务启动时记录当前活跃事务列表
- 如果数据的 DB_TRX_ID < ReadView.min_trx_id → 可见
- 如果数据的 DB_TRX_ID > ReadView.max_trx_id → 不可见
- 如果在活跃列表中 → 不可见，沿 Undo Log 链找旧版本

B+ 树索引：
                ┌─────────┐
                │  根节点   │  (只存索引，不存数据)
                └────┬─────┘
           ┌─────────┼─────────┐
      ┌────▼────┐ ┌──▼─────┐ ┌▼──────┐
      │ 中间节点 │ │中间节点 │ │中间节点│  (只存索引)
      └────┬────┘ └────┬───┘ └───┬───┘
    ┌──────┼──────┐     │        │
┌───▼──┐┌──▼──┐┌─▼──┐┌▼──┐┌───▼──┐
│叶子节点││叶子 ││叶子 ││叶子││叶子  │  ← 叶子层：存完整数据
│       ││节点 ││节点 ││节点││节点  │
└───┬───┘└──┬──┘└──┬──┘└─┬─┘└──┬───┘
    └───────┴──────┴─────┴─────┘
         双向链表连接（支持范围查询）

B+ 树 vs B 树：
- B+ 树数据只存叶子节点，B 树所有节点都存数据
- B+ 树叶子节点有链表，范围查询快
- B+ 树树高更低，IO 次数更少

Hash 索引 vs B+ 树索引：
- Hash：= 查询 O(1)，但不支持范围查询和排序
- B+ 树：范围查询和排序高效

1. 慢查询定位
   slow_query_log → mysqldumpslow / pt-query-digest

2. EXPLAIN 分析
   type 字段（从好到差）：
   system > const > eq_ref > ref > range > index > ALL
                                               ↑ 全表扫描，避免
   key       → 实际使用的索引（NULL = 没用到）
   rows      → 预计扫描行数
   Extra     → Using filesort / Using temporary（需要优化）

3. 索引优化
   - 最左前缀原则：联合索引 (a,b,c)，a / a,b / a,b,c 能用索引
   - 覆盖索引：查询列都在索引中，不需要回表
   - 索引下推 (ICP)：存储引擎层过滤，减少回表
   - 避免索引失效：函数/计算/类型转换/前置通配符(like '%x')

4. 表结构优化
   - 字段尽量 NOT NULL
   - 使用合适的数据类型（越小越好）
   - 垂直拆分（把大字段/冷数据分离）

1. 双指针
   快慢指针：链表判环、找中点
   左右指针：有序数组两数之和、反转数组

2. 滑动窗口
   适用：子串/子数组问题
   维护 left/right，右扩满足条件，左收优化结果

3. 动态规划
   关键：定义状态 + 状态转移方程 + 初始条件
   经典：背包问题、最长公共子序列、编辑距离

4. 贪心
   每步取局部最优，最终全局最优
   前提：局部最优 = 全局最优（需证明）

5. 回溯
   试探 → 失败 → 撤销 → 重试
   八皇后、全排列、组合问题

布隆过滤器 (Bloom Filter)：
├─ 判断"一定不存在"或"可能存在"
├─ 空间效率极高（1 亿数据 ≈ 115MB）
└─ 应用：Redis 缓存穿透防护、垃圾邮件过滤

LSM-Tree（Log-Structured Merge-Tree）：
├─ 写入先写内存 (MemTable)，再顺序写磁盘 (SSTable)
├─ 写性能极好，牺牲部分读性能
└─ 应用：LevelDB, RocksDB, HBase, Cassandra

跳表 (Skip List)：
├─ 多层链表，概率平衡
├─ 实现比红黑树简单，性能相当
└─ 应用：Redis Zset, LevelDB MemTable

一致性哈希 (Consistent Hashing)：
├─ 增删节点只影响相邻节点数据
├─ 虚拟节点解决数据倾斜
└─ 应用：分布式缓存、CDN

创建型（5 种）— 对象怎么创建
├─ 单例模式    全局唯一实例（Spring Bean 默认）
├─ 工厂方法    子类决定创建什么对象
├─ 抽象工厂    创建相关对象家族
├─ 建造者      分步构建复杂对象（StringBuilder, Lombok @Builder）
└─ 原型模式    克隆对象（Object.clone()）

结构型（7 种）— 类/对象怎么组合
├─ 适配器      转换接口（电源适配器）
├─ 装饰器      动态添加功能（Java IO: BufferedInputStream）
├─ 代理        控制访问（Spring AOP, MyBatis Mapper）
├─ 外观        统一入口（Controller → Service → DAO）
├─ 桥接        分离抽象和实现（JDBC: Driver + Connection）
├─ 组合        树形结构（文件系统目录树）
└─ 享元        共享对象（Integer 缓存 -128~127）

行为型（11 种）— 对象怎么协作
├─ 观察者      发布订阅（消息队列, EventListener）
├─ 策略        算法族可切换（支付方式切换）
├─ 模板方法    父类定义流程，子类实现细节（JdbcTemplate）
├─ 责任链      请求沿链传递（Filter, Interceptor）
├─ 命令        请求封装为对象（线程池 Runnable）
└─ 状态        根据状态改变行为（订单状态流转）

S — 单一职责 (SRP)
    一个类只负责一件事
    例：UserService 只处理用户业务，不处理日志

O — 开闭原则 (OCP)
    对扩展开放，对修改关闭
    例：用策略模式新增支付方式，不修改原有代码

L — 里氏替换 (LSP)
    子类可以替换父类而不影响程序正确性
    例：Rectangle(长方形) 和 Square(正方形) 违反 LSP

I — 接口隔离 (ISP)
    不强迫客户端依赖它不需要的接口
    例：拆分为 UserReadService / UserWriteService

D — 依赖倒置 (DIP)
    依赖抽象（接口），不依赖具体实现
    例：Service 依赖 IRepository 接口，不依赖 MySQL 实现

面向对象 (OOP)       封装、继承、多态
函数式 (FP)         纯函数、不可变数据、高阶函数
                    例：Java Stream, React Hooks, Scala
响应式 (RP)         数据流 + 变化传播
                    例：RxJava, WebFlux, Vue Reactivity
声明式              描述"是什么"，不描述"怎么做"
                    例：SQL, HTML, Kubernetes YAML

CAP：一个分布式系统最多同时满足两项

          C (一致性)
         /\
        /  \
       /    \
      /  CP  \         CP: ZooKeeper, etcd
     /  (银行)\
    /         \
   /           \
  /   AP        \      AP: Eureka, Cassandra
 /   (DNS)       \
P──────────────────A
    可用性

选择策略：
- CP：需要强一致（金融交易、分布式锁）→ ZooKeeper → CP
- AP：需要高可用（服务注册、CDN）→ Eureka → AP
- 实际中：BASE 理论，舍弃强一致换取可用性

Basically Available（基本可用）
    系统出现故障时，允许损失部分可用性
    例：响应时间从 50ms 降到 3s，或引导到降级页面

Soft state（软状态）
    允许系统存在中间状态，无需实时一致
    例：订单"支付中"状态

Eventually consistent（最终一致性）
    不保证实时一致，但最终会达到一致
    例：DNS 更新需要时间传播到所有节点

两阶段提交 (2PC)：
协调者 → 所有参与者：准备提交？
        参与者 → 协调者：YES/NO
协调者 → 所有参与者：提交/回滚

问题：同步阻塞、单点故障、数据不一致风险

三阶段提交 (3PC)：
在 2PC 基础上加入超时机制和预提交阶段，减少阻塞

TCC (Try-Confirm-Cancel)：
Try:   预留资源（冻结库存）
Confirm: 确认执行（扣减库存）
Cancel: 取消执行（释放冻结）

Paxos / Raft：
共识算法，用于选主和日志复制
Raft 比 Paxos 更易理解（Leader 选举 + 日志复制 + 安全性）

1. 分布式 ID 生成
   方案：Snowflake (1bit + 41bit时间 + 10bit机器 + 12bit序号)
        号段模式 (美团 Leaf)
        数据库自增 (单点瓶颈)

2. 分布式锁
   方案：Redis (SET NX EX + Redlock)
        ZooKeeper (临时顺序节点)
        etcd

3. 分布式事务
   方案：2PC / 3PC / TCC / Saga / 本地消息表 + MQ

4. 限流算法
   固定窗口：简单但有临界问题
   滑动窗口：更精确
   漏桶：固定速率流出（NGINX limit_req）
   令牌桶：允许突发（Guava RateLimiter）

5. 服务降级与熔断
   降级：关掉非核心功能（关闭推荐、返回缓存数据）
   熔断：错误率达到阈值 → 快速失败 → 半开探测 → 恢复
        (Hystrix → Resilience4j → Sentinel)

四层负载 (L4, 传输层)：
├─ 基于 IP + Port
├─ 性能高，无法根据 URL 路由
└─ 实现：LVS, F5, Nginx Stream

七层负载 (L7, 应用层)：
├─ 基于 URL / Header / Cookie
├─ 更智能，支持 SSL 终结
└─ 实现：Nginx, HAProxy, Traefik, Envoy

算法：
轮询、加权轮询、最少连接、IP Hash、一致性 Hash

需求分析 → 系统设计 → 编码实现 → 测试 → 部署 → 运维

瀑布模型：    顺序执行，不可回溯（适合需求稳定的项目）
敏捷 (Scrum)：迭代增量，2-4 周一个 Sprint
DevOps：      打通 Dev + Ops，CI/CD 持续交付

           ┌──────┐
           │ E2E  │  UI 端到端测试（少而精）
           │ 10%  │
          ┌┴──────┴┐
          │ 集成测试│  API/服务间测试
          │  20%   │
         ┌┴────────┴┐
         │  单元测试  │  快速、大量
         │   70%    │
         └──────────┘

// 单元测试 (JUnit 5)
@Test
void shouldCreateOrderSuccessfully() {
    // Given
    OrderDTO dto = new OrderDTO(1L, 100);
    when(orderRepo.save(any())).thenReturn(mockOrder);

    // When
    Order result = orderService.create(dto);

    // Then
    assertThat(result.getStatus()).isEqualTo(OrderStatus.PENDING);
}

// 集成测试
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class OrderControllerTest {
    @Test
    void shouldReturnOrderById() {
        given()
            .contentType(ContentType.JSON)
        .when()
            .get("/api/orders/1")
        .then()
            .statusCode(200)
            .body("id", equalTo(1));
    }
}

圈复杂度 (Cyclomatic Complexity)：
  衡量代码逻辑复杂度，if/else/for 越多越高
  建议 ≤ 10（单个方法）

代码重复率：
  建议 < 5%（SonarQube 检测）

测试覆盖率：
  行覆盖率 > 80%（核心业务 > 90%）
  分支覆盖率 > 70%

技术债务：
  SonarQube 技术债务比率 < 5%

Git Flow：
main ─────●──────────●──────────●
           \         /          /
  develop───●──●──●──●──●──●──●
              \ /     \ /
  feature──────●       ●

GitHub Flow（简化版）：
  main ← feature branch ← PR ← Review ← Merge

GitLab Flow：
  main → pre-production → production
  （环境分支模型）

常用操作：
  git rebase -i HEAD~3    # 合并最近 3 个提交
  git cherry-pick <hash>  # 挑一个提交合入
  git reflog              # 找回丢失的提交
  git bisect              # 二分法找 bug 提交

代码提交 ──▶ 编译 ──▶ 单元测试 ──▶ 代码扫描 ──▶ 构建镜像 ──▶
            │                                          │
            └──────── 失败则通知 ──────────────────────┘
                                                       │
         ┌─────────────────────────────────────────────┘
         ▼
   部署到 DEV ──▶ 集成测试 ──▶ 部署到 STAGING ──▶ UAT ──▶
                                                       │
         ┌─────────────────────────────────────────────┘
         ▼
   蓝绿/金丝雀发布 ──▶ PRODUCTION ──▶ 监控告警

# GitHub Actions CI 示例
name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Build & Test
        run: mvn verify
      - name: SonarQube Scan
        run: mvn sonar:sonar -Dsonar.host.url=$SONAR_URL
      - name: Build Docker Image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push to Registry
        run: docker push myapp:${{ github.sha }}

蓝绿部署 (Blue-Green)：
├─ 两套完全相同的环境：Blue (当前) + Green (新版本)
├─ 流量一次性切换到 Green
├─ 优点：秒级回滚
└─ 缺点：双倍资源

金丝雀发布 (Canary)：
├─ 新版本先部署到少量实例（5%）
├─ 验证无问题逐步扩大比例
├─ 优点：风险可控
└─ 缺点：需要流量路由能力

滚动发布 (Rolling)：
├─ 逐个替换实例
├─ 优点：资源利用率高
└─ 缺点：回滚慢，短暂多版本共存

A/B 测试：
├─ 不是发布策略，是业务实验
├─ 两套方案给不同用户群体
└─ 比较转化率/用户反馈

镜像 (Image)：    应用程序的只读模板
容器 (Container)：镜像的可运行实例（镜像 + 可写层）
仓库 (Registry)： 存储和分发镜像（Docker Hub, Harbor）
Dockerfile：     构建镜像的脚本
Docker Compose： 多容器编排（开发/测试环境）

# 多阶段构建（减小镜像体积）
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

FROM eclipse-temurin:17-jre-alpine
RUN addgroup -S app && adduser -S app -G app
USER app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
HEALTHCHECK CMD wget -qO- http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-jar", "app.jar"]

┌─────────────────────────────────────────────────────────┐
│                      Cluster                             │
│  ┌─────────────────────────────────────────────────────┐│
│  │                    Node (Worker)                     ││
│  │  ┌─────────────┐  ┌─────────────┐                  ││
│  │  │    Pod      │  │    Pod      │                  ││
│  │  │ ┌─────────┐ │  │ ┌─────────┐ │                  ││
│  │  │ │Container│ │  │ │Container│ │                  ││
│  │  │ └─────────┘ │  │ └─────────┘ │                  ││
│  │  └─────────────┘  └─────────────┘                  ││
│  │       ↑ Service 提供稳定访问                         ││
│  └─────────────────────────────────────────────────────┘│
│                                                          │
│  Deployment: 管理 Pod 副本和滚动更新                       │
│  Service:    Pod 的负载均衡入口                           │
│  Ingress:    外部流量入口（HTTP 路由）                    │
│  ConfigMap:  配置管理                                    │
│  Secret:     敏感信息                                    │
└─────────────────────────────────────────────────────────┘

监控四层模型：
┌──────────────────────────────────────┐
│ 第 4 层：业务监控                     │
│   订单量、GMV、注册数、转化率          │
├──────────────────────────────────────┤
│ 第 3 层：应用监控                     │
│   QPS、响应时间、错误率、GC           │
├──────────────────────────────────────┤
│ 第 2 层：中间件监控                   │
│   MySQL/Redis/MQ 连接数和性能         │
├──────────────────────────────────────┤
│ 第 1 层：基础设施监控                  │
│   CPU、内存、磁盘、网络               │
└──────────────────────────────────────┘

黄金指标（Google SRE 四大指标）：
1. 延迟 (Latency)：P50 / P99 / P999
2. 流量 (Traffic)：QPS / TPS
3. 错误 (Errors)：5xx / 异常率
4. 饱和度 (Saturation)：连接数 / 队列长度 / CPU

RTO (Recovery Time Objective)：
  故障后多久能恢复服务？（目标恢复时间）
  例：RTO = 30 分钟 → 必须在 30 分钟内恢复

RPO (Recovery Point Objective)：
  允许丢失多少数据？（目标恢复点）
  例：RPO = 5 分钟 → 最多丢 5 分钟的数据

灾备级别：
┌──────────┬────────────┬──────────┐
│   级别    │    RTO      │   方案    │
├──────────┼────────────┼──────────┤
│ 热备      │ 秒-分钟     │ 多活/主从自动切换  │
│ 暖备      │ 分钟-小时   │ 主从手动切换       │
│ 冷备      │ 小时-天     │ 全量备份恢复       │
│ 异地容灾  │ 视方案而定   │ 异地多活 / 两地三中心│
└──────────┴────────────┴──────────┘

MTBF (Mean Time Between Failures)：平均故障间隔时间
MTTR (Mean Time To Repair)：      平均修复时间

故障响应流程：
发现 → 通告 → 止损 → 定位 → 修复 → 复盘

止损三板斧：
1. 回滚：回到上一个稳定版本
2. 降级：关闭非核心功能
3. 限流：限制入口流量

故障复盘 (Postmortem)：
├─ 时间线：发生了什么，什么时候
├─ 根因：5-Why 分析法
├─ 影响：用户/业务影响范围
├─ 改进：Action Items + 责任人 + 截止日期
└─ 心态：对事不对人

SLO (Service Level Objective)：服务等级目标
  例：99.9% 的请求在 500ms 内完成

SLI (Service Level Indicator)：服务等级指标
  实际测量值，如 P99 延迟 = 480ms

SLA (Service Level Agreement)：服务等级协议
  合同约定，不达标要赔偿

错误预算 (Error Budget)：
  错误预算 = 1 - SLO
  例：SLO = 99.9% → 错误预算 = 0.1%（每月约 43 分钟）
  如果错误预算没花完 → 可以加速发布
  如果错误预算花完了 → 暂停发布，优先稳定性

单体架构 → 垂直拆分 → SOA → 微服务 → Service Mesh

单体：
  优势：简单、开发快、部署容易
  挑战：耦合高、扩展难、部署慢

微服务：
  优势：独立部署、独立扩展、技术异构
  挑战：分布式复杂性、数据一致性、运维成本高

判断是否该拆：
  - 团队规模 > 2-pizza team (8-10 人)
  - 模块间耦合度低，各自独立变更
  - 不同模块有不同的扩展需求
  - 不同模块有不同的技术栈需求

战略设计：
├─ 统一语言 (Ubiquitous Language)
├─ 限界上下文 (Bounded Context)
└─ 上下文映射 (Context Map)

战术设计：
├─ 实体 (Entity)：有唯一标识，可变
├─ 值对象 (Value Object)：无标识，不可变
├─ 聚合 (Aggregate)：实体+值对象的聚合体，通过聚合根访问
├─ 领域服务 (Domain Service)：不属于特定实体的领域逻辑
├─ 仓库 (Repository)：聚合的持久化接口
└─ 领域事件 (Domain Event)：领域中发生的重要事件

架构分层：
  用户接口层 → 应用层 → 领域层 → 基础设施层
      ↑                     ↑
    Controller/UI    Service(编排) + Domain(核心)

事件驱动架构 (EDA)：
  服务 A 发布事件 → MQ → 服务 B/C/D 订阅消费
  优点：解耦、异步、可扩展
  适合：订单→库存→物流→通知 这种链式场景

CQRS (命令查询职责分离)：
  写模型：Command → 写数据库
  读模型：Query → 读数据库（独立优化的查询库）
  适合：读写比例悬殊、查询模型复杂的场景

Clean Architecture（六边形架构/洋葱架构）：
  ┌─────────────────────────────┐
  │       Frameworks & Drivers  │  外层
  │  ┌───────────────────────┐  │
  │  │  Interface Adapters   │  │
  │  │  ┌─────────────────┐  │  │
  │  │  │  Application    │  │  │
  │  │  │  ┌───────────┐  │  │  │
  │  │  │  │  Domain   │  │  │  │  内层（核心）
  │  │  │  └───────────┘  │  │  │
  │  │  └─────────────────┘  │  │
  │  └───────────────────────┘  │
  └─────────────────────────────┘
  核心原则：依赖方向 → 向内，外层依赖内层

分层架构 / 整洁架构 / 六边形架构都是此思想。

评估维度（加权打分）：
├─ 功能匹配度 (30%)：是否满足业务需求？
├─ 技术成熟度 (20%)：社区活跃度、文档、案例
├─ 团队能力 (20%)：团队是否熟悉？
├─ 性能与扩展 (15%)：能否支撑业务增长？
├─ 运维成本 (10%)：部署、监控、升级难度
└─ 许可证与成本 (5%)：是否开源？商业授权？

决策矩阵示例：
        功能  成熟  团队  性能  运维  许可  总分
方案A    9     8     7     8     7     10    8.1
方案B    8     9     5     7     8     10    7.7
→ 选方案A

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  概念     │───▶│  设计     │───▶│  开发     │───▶│  运营     │───▶│  退市     │
│  验证     │    │  原型     │    │  迭代     │    │  增长     │    │  迁移     │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘

关键活动：
概念：用户需求调研、竞品分析、可行性评估
设计：信息架构、交互原型 (Figma)、PRD
开发：需求评审、Sprint 计划、验收
运营：数据分析、用户反馈、A/B 测试
退市：数据迁移、用户通知、替代方案

用户故事格式：
  作为 <角色>，我想要 <功能>，以便 <价值>

  例：作为 买家，我想要 按价格筛选商品，以便 快速找到符合预算的商品

INVEST 原则（好的用户故事）：
  Independent  — 独立（故事之间尽量解耦）
  Negotiable   — 可协商（细节通过沟通确认）
  Valuable     — 有价值（对用户/业务有明确价值）
  Estimable    — 可估算（团队能估算工作量）
  Small        — 小粒度（一个 Sprint 内完成）
  Testable     — 可测试（有明确的验收条件）

验收条件 (Acceptance Criteria)：
  当 [场景]，如果 [操作]，那么 [预期结果]

  例：当 用户输入有效的用户名和密码，点击登录按钮，
      那么 系统跳转到首页并在右上角显示用户名。

KANO 模型：
  基本型需求：没有=极度不满，有=理所当然（登录、支付安全）
  期望型需求：越多越满意，越少越不满（响应速度、UI 美观度）
  兴奋型需求：没有=不会不满，有=超出预期（智能推荐、夜间模式）

AARRR 海盗模型：
  Acquisition  获取（用户从哪里来？下载/访问量）
  Activation   激活（用户首次体验到核心价值？注册完成率）
  Retention    留存（用户会回来吗？次日/7日/30日留存率）
  Revenue      变现（如何赚钱？付费率、ARPU、GMV）
  Referral     推荐（用户会推荐给别人吗？邀请率）

北极星指标 (North Star Metric)：
  最能代表产品价值的核心指标
  例：Spotify → 总听歌时长
      Airbnb → 预订天数
      Slack → 发送的消息数

数据驱动决策：
  1. 定义问题（What/Why/How）
  2. 提出假设（如果做 X → 会导致 Y，因为 Z）
  3. 设计实验（A/B Test 样本量、时长）
  4. 分析结果（统计显著性 P < 0.05）
  5. 落地决策（发布/放弃/继续迭代）

┌─────────────────────────────────────────────┐
│ 产品需求文档 (PRD)                           │
│                                             │
│ 1. 背景与目标                                │
│    为什么要做？解决什么问题？衡量成功的指标？    │
│                                             │
│ 2. 用户分析                                  │
│    目标用户画像、使用场景、痛点                │
│                                             │
│ 3. 功能详述                                  │
│    功能列表、流程图、原型图、交互说明           │
│                                             │
│ 4. 非功能需求                                │
│    性能指标、安全要求、兼容性（APP / 浏览器）   │
│                                             │
│ 5. 验收标准                                  │
│    可测试的通过条件                           │
│                                             │
│ 6. 发布计划                                  │
│    版本规划、灰度策略、回滚方案                │
│                                             │
│ 7. 风险与依赖                                │
│    技术风险、依赖的外部系统、法规合规           │
└─────────────────────────────────────────────┘

1.  整合管理    项目章程、项目管理计划、变更管理
2.  范围管理    需求收集、WBS（工作分解结构）
3.  进度管理    里程碑、关键路径、甘特图
4.  成本管理    估算、预算、挣值分析 (EVM)
5.  质量管理    质量标准、测试策略、评审
6.  资源管理    团队组建、RACI 矩阵
7.  沟通管理    沟通计划、状态报告
8.  风险管理    风险识别、概率×影响矩阵、应对计划
9.  采购管理    招标、合同管理
10. 干系人管理  识别干系人、管理期望

瀑布 (Waterfall)：
  需求 → 设计 → 开发 → 测试 → 部署
  适合：需求明确、变更少（如政府项目、嵌入系统）
  风险：后期才发现问题，改造成本高

敏捷 (Agile)：
  Sprint 1    Sprint 2    Sprint 3
  ┌────────┐ ┌────────┐ ┌────────┐
  │需求设计│ │需求设计│ │需求设计│
  │开发测试│ │开发测试│ │开发测试│
  │交付评审│ │交付评审│ │交付评审│
  └────────┘ └────────┘ └────────┘
  适合：需求不确定、需要快速验证（互联网产品）
  核心：拥抱变化、快速迭代、持续交付

角色：
├─ Product Owner (PO)：定义需求、排优先级、验收
├─ Scrum Master (SM)：引导流程、移除障碍、教练
└─ Development Team (Dev)：开发、自组织（5-9人）

仪式（Sprint 周期 2-4 周）：
├─ Sprint Planning：定 Sprint 目标 + 选 Backlog
├─ Daily Standup (15min)：昨天做了什么/今天做什么/有什么阻碍
├─ Sprint Review：演示交付物 → 收集反馈
└─ Sprint Retrospective：改进流程（KPT: Keep/Problem/Try）

工件：
├─ Product Backlog：所有需求清单（PO 负责优先级）
├─ Sprint Backlog：本 Sprint 要完成的需求
├─ Increment：Sprint 产出的可用产品增量
└─ Burndown Chart：剩余工作量趋势图

故事点 (Story Point)：
  相对估算单位，不是工时
  代表复杂度+工作量+不确定性
  例：Fibonacci 数列（1, 2, 3, 5, 8, 13, 21）

规划扑克 (Planning Poker)：
  每人出牌 → 最高和最低解释 → 第二轮投票 → 达成共识

三点估算法：
  乐观(O) + 最可能(M) + 悲观(P)
  期望值 = (O + 4M + P) / 6

风险矩阵：
              影响程度
              低    中    高    极高
概率  高       关注   重要   严重   灾难
      中       关注   关注   重要   严重
      低       忽略   关注   关注   重要
      极低     忽略   忽略   关注   关注

风险应对策略：
├─ 规避：不干了（取消高风险活动）
├─ 转移：让别人承担（买保险、外包）
├─ 缓解：降低概率或影响（增加测试、冗余）
├─ 接受：留应急储备（可接受的风险）
└─ 利用：机会（有利的不确定性）

RACI 矩阵：
┌────────────┬─────┬─────┬─────┬─────┐
│   活动      │ PM  │ PO  │ Dev │ QA  │
├────────────┼─────┼─────┼─────┼─────┤
│ 需求定义    │  C  │  R  │  C  │  I  │
│ 架构设计    │  I  │  C  │  R  │  I  │
│ 开发编码    │  I  │  I  │  R  │  C  │
│ 测试验收    │  A  │  C  │  C  │  R  │
│ 部署发布    │  A  │  I  │  R  │  C  │
└────────────┴─────┴─────┴─────┴─────┘
R=执行 (Responsible)
A=负责 (Accountable) — 最终拍板的
C=咨询 (Consulted)
I=知情 (Informed)

OWASP Top 10 (Web 安全十大风险)：

1. 注入 (Injection)
   SQL 注入：' OR '1'='1' --
   防护：参数化查询、ORM、输入校验

2. 失效的身份验证
   弱密码、Session 劫持
   防护：MFA、密码复杂度、Session 过期

3. 敏感数据泄露
   明文存储、日志泄露密码
   防护：加密存储(bcrypt)、脱敏日志、HTTPS

4. XXE (XML 外部实体注入)
   防护：禁用 DTD、使用 JSON

5. 失效的访问控制
   越权：修改 URL 参数访问他人数据
   防护：服务端权限校验、RBAC

6. 安全配置错误
   默认密码、错误信息暴露版本
   防护：安全基线、信息最小化

7. XSS (跨站脚本)
   反射型/存储型/DOM 型
   防护：输出编码、CSP、HttpOnly Cookie

8. 不安全的反序列化
   防护：白名单、签名校验、RASP

9. 使用含已知漏洞的组件
   防护：依赖扫描、及时更新

10. 日志和监控不足
    防护：集中日志、异常告警

认证 (Authentication)：你是谁？
├─ 密码 / MFA / OTP
├─ OAuth 2.0（微信登录、GitHub 登录）
├─ SSO (Single Sign-On)
└─ 生物特征

授权 (Authorization)：你能做什么？
├─ RBAC：基于角色（admin / user / guest）
├─ ABAC：基于属性（时间+地点+设备+...）
├─ OAuth 2.0 Scope：基于范围
└─ ACL：基于访问控制列表

JWT (JSON Web Token)：
  Header.Payload.Signature
  无状态，服务端不需要存 Session
  注意：payload 仅 Base64 编码，非加密！不存敏感信息

纵深防御 (Defense in Depth)：
  多层防护，一层破了还有下一层
  网络层(WAF/IP白名单) → 应用层(输入校验) → 数据层(加密)

最小权限原则 (Least Privilege)：
  只给完成任务所需的最小权限
  例：普通用户不能访问管理接口

默认安全 (Secure by Default)：
  默认配置即安全
  例：MySQL 8.0 默认 localhost 访问

零信任 (Zero Trust)：
  永不信任，始终验证
  不因在内网就信任，每次请求都要认证+授权

运维工程师核心能力：
├─ Linux 系统管理：启动流程、systemd、内核参数、故障排查
├─ 网络：TCP/IP 协议栈、抓包分析 (tcpdump/Wireshark)、DNS/CDN
├─ 脚本：Shell/Python 自动化
├─ 数据库运维：备份恢复、主从管理、慢查询优化
├─ 中间件：Nginx/Tomcat/Redis/MySQL/RabbitMQ 部署调优
├─ 容器化：Docker + K8s（Deployment/Service/Ingress/ConfigMap）
├─ 监控：Prometheus + Grafana + ELK
├─ CI/CD：Jenkins/GitLab CI/GitHub Actions
├─ 云平台：至少熟悉阿里云/AWS/Azure 之一
└─ 自动化：Terraform/Ansible

高频面试题：
Q: 服务器 CPU 飙升 100%，怎么排查？
A: top → 找出进程 → top -Hp <pid> 找线程 → 
   jstack (Java) / 看代码逻辑 → 是死循环？频繁 GC？大量计算？

Q: 网站访问慢，怎么排查？
A: 分层定位 —
   1. 前端：Network 面板看资源加载时间
   2. Nginx：$request_time / $upstream_response_time
   3. 应用：JVM GC / 线程池 / 数据库连接池
   4. 数据库：慢查询 / 锁 / 连接数
   5. 系统：CPU / 内存 / 磁盘 I/O / 网络带宽

核心能力：
├─ 语言深度：JVM 原理 / Go 并发 / Python 元类
├─ 数据结构与算法：LeetCode 200+
├─ 设计模式：能说出项目中用到的 5+ 种模式
├─ 框架原理：Spring IoC/AOP/事务、MyBatis 插件
├─ 数据库：索引优化、SQL 改写、分库分表方案
├─ 中间件：Redis 缓存设计、MQ 消息可靠性
├─ 系统设计：秒杀、短链、IM、Feed 流
├─ 代码质量：重构、单元测试、Code Review

高频面试题：
Q: ConcurrentHashMap 原理？
A: JDK 7: Segment 分段锁（默认 16 段）
   JDK 8: CAS + synchronized（锁粒度更细）
   红黑树优化：链表长度 ≥ 8 转红黑树

Q: MySQL 一条 SQL 的执行过程？
A: 连接器 → 分析器 → 优化器 → 执行器 → 存储引擎
   优化器：选择索引、Join 顺序
   执行器：调用存储引擎接口逐行读取

核心能力：
├─ 系统设计：高并发、高可用、高扩展
├─ 分布式理论：CAP/BASE/共识算法/分布式事务
├─ 架构模式：微服务/事件驱动/CQRS/DDD
├─ 技术广度：能选型，知道各方案的 trade-off
├─ 性能优化：全链路压测、性能瓶颈定位
├─ 容量规划：预估 QPS → 需要的机器数
├─ 技术领导力：推动技术演进、制定规范

高频面试题：
Q: 设计一个秒杀系统？
A: 
1. 前端：按钮防重复 + 验证码
2. 网关：限流（令牌桶）
3. 服务层：Redis 预减库存 → 消息队列异步下单
4. 数据库：行级锁扣库存 + 热点隔离
5. 容量：预估 QPS → 扩容机器 → 压测验证

Q: 微服务拆分原则？
A: 
- 按业务域拆分（DDD 限界上下文）
- 高内聚低耦合
- 独立变更和部署
- 数据独立性（每服务独立数据库）
- 团队对齐（康威定律）

核心能力：
├─ 需求分析：用户调研、竞品分析、数据洞察
├─ 产品设计：原型(Axure/Figma)、交互、信息架构
├─ 数据分析：AARRR、留存分析、漏斗分析
├─ 项目管理：需求优先级、版本规划、跨部门协调
├─ 商业思维：商业模式画布、ROI 分析
└─ 技术理解：能评估技术可行性、理解开发成本

高频面试题：
Q: 怎么判断一个需求做不做？
A: 
1. 是否符合产品战略和 OKR？
2. 用户价值 × 用户量 × 影响强度
3. 开发成本 / 实现难度
4. 投入产出比 (ROI)
5. 是否紧急？是否有依赖？

Q: 如何确定需求优先级？
A: 
- RICE 模型：Reach(覆盖) × Impact(影响) × Confidence(信心) / Effort(成本)
- MoSCoW：Must/Should/Could/Won't
- KANO：基本型 > 期望型 > 兴奋型

核心能力：
├─ 计划制定：WBS、甘特图、关键路径
├─ 进度跟踪：燃尽图、里程碑、站会
├─ 风险管理：风险识别、评估、应对
├─ 沟通协调：干系人管理、跨团队协调
├─ 质量管理：评审机制、质量标准
└─ 方法论：Scrum/Kanban/SAFe

高频面试题：
Q: 项目延期了怎么办？
A: 
1. 分析原因：需求变更？估算不准？依赖阻塞？
2. 评估影响：延期多久？影响哪些里程碑？
3. 制定方案：
   - 赶工：增加资源（但可能降低质量）
   - 快速跟进：并行原本串行的任务（增加风险）
   - 削减范围：协商优先级，延迟低优先级
   - 调整日期：与管理层/客户沟通新日期
4. 总结经验：改进估算流程、增加缓冲

Q: 怎么管理需求变更？
A: 
1. 建立变更控制流程（CCB）
2. 评估变更影响（范围/进度/成本/质量）
3. 与干系人沟通（告知代价）
4. 记录所有变更（可追溯）
5. 整体考虑，不单看一个变更

                    ┌─────────────────────────────────────┐
                    │           IT 知识体系全景             │
                    └─────────────────────────────────────┘
                                      │
        ┌──────────┬──────────┬───────┴───────┬──────────┬──────────┐
        │          │          │               │          │          │
   ┌────▼───┐ ┌───▼────┐ ┌──▼───┐     ┌─────▼────┐ ┌───▼───┐ ┌───▼────┐
   │ 计算机  │ │ 编程   │ │数据库 │     │ 分布式   │ │ 工程  │ │ 业务   │
   │ 基础    │ │ 语言   │ │      │     │ 系统     │ │ 实践  │ │ 领域   │
   └────┬───┘ └───┬────┘ └──┬───┘     └─────┬────┘ └───┬───┘ └───┬────┘
        │         │         │               │          │         │
   ┌────▼───┐     │    ┌────▼───┐      ┌────▼───┐      │         │
   │·OS     │     │    │·MySQL  │      │·CAP    │  ┌───▼───┐     │
   │·网络   │     │    │·Redis  │      │·BASE   │  │·Git   │     │
   │·DS/ALG │     │    │·ES     │      │·Raft   │  │·CI/CD │     │
   │·编译   │     │    │·MongoDB│      │·微服务  │  │·DevOps│     │
   └────────┘     │    └────────┘      │·消息队列│  │·Docker│     │
                  │                    │·分布式锁│  │·K8s   │     │
              ┌───▼────┐               └────────┘  └───────┘     │
              │ Java   │                                          │
              │ Go     │                                     ┌────▼───┐
              │ Python │                                     │·电商   │
              │ JS/TS  │                                     │·金融   │
              └────────┘                                     │·SaaS   │
                                                             └────────┘

运维侧重点：OS/网络 → 中间件运维 → 容器/K8s → 监控 → CI/CD
开发侧重点：语言 → 框架 → 数据库 → 中间件 → 系统设计
架构侧重点：分布式 → DDD → 微服务 → 容量规划 → 技术选型
产品侧重点：需求分析 → 数据驱动 → 商业模式 → 技术理解
项目侧重点：敏捷/Scrum → 风险 → 沟通 → 干系人