基础架构架构师岗位技术手册

概述本手册面向基础架构架构师岗位，涵盖八大核心技术领域。每个领域包含原理剖析、实现机制、技术生态说明及常见典型问题。目录分布式系统容器/K8s服务网格存储系统计算调度网络可观测性成本工程1. 分布式系统1.1 一致性算法Raft 算法核心原理：Raft 通过领导者选举和日志复制实现分布式一致性，将问题分解为三个子问题：领导者选举、日志复制、安全性。实现机制：状态机： - Follower: 被动响应请求，超时后转为 Candidate - Candidate: 发起选举，获得多数票后成为 Leader - Leader: 接收客户端请求，复制日志到 Follower 领导者选举： - 任期(Term)：单调递增的逻辑时钟 - 选举超时：150-300ms 随机化，防止瓜分选票 - 心跳机制：Leader 定期发送心跳维持权威 日志复制： - Log Entry: {term, index, command} - 两阶段提交：Leader 写入本地日志后，并行发送给 Follower - 多数派确认后 apply 到状态机实践：内部数据库 ByteSQL 使用 Raft 做数据复制配置中心 etcd 集群管理服务配置强一致性存储服务采用 Multi-Raft 架构常见典型问题：Q: Raft 如何保证线性一致性？A:Leader 必须拥有所有已提交的日志条目（完整性）日志条目必须按顺序复制到多数派节点只允许追加日志，不覆盖已提交条目（匹配性）提交确认前必须持久化到多数派节点Q: 网络分区时 Raft 如何保证数据不丢失？A:只有包含多数派的分区可以选出 Leader被分割的 Follower 不处理请求，不会产生脏数据恢复网络后，Leader 将缺失的日志同步给 Follower旧 Leader 的未提交日志不会丢失（如果新 Leader 已确认）Paxos 算法核心原理：Paxos 通过两阶段提交（Prepare/Accept）达成共识，核心是少数服从多数的投票机制。实现机制：两阶段执行： Phase 1 (Prepare): - Proposer 选择提案编号 N，向多数派节点发送 Prepare(N) - Acceptor 承诺不再接受编号小于 N 的提案，并返回已接受的提案 Phase 2 (Accept): - Proposer 收到多数派响应后，发送 Accept(N, V) - Acceptor 收到 Accept 后，如未违反承诺则接受 提案值选择： - 如果多数派返回了已接受的提案，选择编号最大的值 - 否则，使用自己的值Raft vs Paxos：维度RaftPaxos可理解性强领导者，易理解分布式共识，难以理解性能领导者优化，适合读多写少无领导者，性能更均衡连续提案日志顺序保证需要 Multi-Paxos 优化1.2 分布式事务2PC (Two-Phase Commit)Phase 1 - Prepare: - TM 向所有参与者发送 Prepare 消息 - 参与者执行事务（持有什么锁） - 参与者返回 Prepare OK 或 Abort Phase 2 - Commit: - TM 收到所有 Prepare OK 后，发送 Commit - 参与者提交事务，释放锁 - 任一参与者返回 Abort 或超时，TM 发送 Rollback缺点：同步阻塞：参与者prepare后持有锁直到commit/rollback协调者单点：协调者故障可能导致参与者无限等待数据不一致：协调者崩溃后部分节点可能已提交TCC (Try-Confirm-Cancel)Try: 预留资源（冻结/预扣） Confirm: 确认执行（真正扣减） Cancel: 回滚（释放冻结）实践：交易系统使用 TCC 处理分布式事务跨机房同步使用 TCC 保证最终一致性优势：try阶段释放锁，不阻塞Saga 模式每个子事务 Si 都有对应的补偿事务 Ci 执行顺序：S1, S2, S3, ..., Sn 回滚时执行：Cn, ..., C3, C2, C1适用场景：长事务、跨服务调用、允许最终一致性的业务1.3 CAP 理论C (Consistency): 所有节点看到同一份数据 A (Availability): 每个请求都能收到响应 P (Partition Tolerance): 网络分区时系统仍能运行 CA without P: 不可能存在的系统（网络必分区） 实际选择： - CP: Zookeeper, etcd, HBase, MongoDB - AP: Cassandra, DynamoDB, CouchDB