分布式基础课程笔记
一、什么是分布式？
1. 权威定义
分布式系统定义为：“利用物理架构形成多个自治的处理元素，不共享主内存，通过发送消息合作”。
2. 核心解释
-
物理架构与处理元素
🌟 多台独立服务器/电脑：类比不同员工各司其职。 -
不共享主内存
🌟 各服务器内存独立：如同员工各自记账本不共享。 -
通过消息合作
🌟 只能通过消息传递协作：类似员工间用对讲机沟通。
3. 架构演进案例（老板开店故事）
-
单体架构
小卖店模式：老板包揽所有工作（收银+补货+清洁）。 -
集群架构
分店模式：老板和老板娘各开相同功能的店铺（能力未拆分）。 -
分布式架构
专业分工模式：雇佣收银员/理货员/保洁员（能力拆分+合作）。
二、关键架构对比
| 单体架构 | 集群架构 | 分布式架构 | |
|---|---|---|---|
| 特点 | 所有功能集中 | 完整功能复制 | 功能拆分+合作 |
| 类比 | 单人小卖店 | 连锁便利店 | 专业团队分工合作 |
| 优势 | 开发简单 | 高可用性 | 灵活扩展 |
| 劣势 | 单点故障风险高 | 资源浪费 | 系统复杂度高 |
分布式架构核心知识笔记
一、分布式架构的作用与演进
1. 单体应用的核心痛点
- 🚫 速度变慢：编译部署像等待老式打印机（10分钟起），新人入职配置环境如同拼装乐高积木。
- 🚫 耦合严重：代码像房间里的乱接电线（改一处可能烧毁整个系统）。
- 🚫 技术债务：历史代码如同衣柜里的旧衣服（占地方却不敢扔）。
- 🚫 协作困难：合并代码堪比多人同时编辑Excel表格（冲突频繁）。
2. 分布式架构的四大优势
| 优势维度 | 具体表现 | 生活化案例 |
|---|---|---|
| ⚡开发效率 | 微服务独立开发如同快餐店后厨分工 | 汉堡组、薯条组互不干扰 |
| 🔧技术升级 | 更新组件像更换手机APP | 单独更新微信不影响支付宝 |
| 🛡️系统可用性 | 服务隔离如同轮船防水舱设计 | 一个船舱进水不影响其他舱 |
| 💰成本优化 | 资源调配像共享充电宝部署 | 商场多放，小区少放 |
二、架构对比分析表（单体 vs 分布式）
| 对比维度 | 单体架构 | 分布式架构 | 典型误解澄清 |
|---|---|---|---|
| 🏃启动速度 | 整装待发的装甲车（全量启动） | 特种部队分散部署（独立启动） | 分布式整体协调时间常被忽视 |
| 👥团队规模 | 家庭作坊（3-5人） | 跨国公司（百人级） | 团队规模决定架构选择 |
| 🛠️维护成本 | 考古式开发（不敢删旧代码） | 模块化维护（独立升级） | 分布式初始成本更高但长期收益大 |
| 💻代码清晰度 | 意大利面式代码 | API契约式开发 | 分布式不代表绝对规范 |
| 🚨故障影响 | 多米诺骨牌效应 | 蜂巢式隔离 | 分布式故障排查更复杂 |
| 🎨设计难度 | 简笔画 | 清明上河图 | 需要架构师全局视野 |
分布式系统核心理论 CAP定理
一、CAP定理核心概念
1. 三要素定义
-
**一致性（Consistency）**🌟
所有节点同时看到相同数据。如：节点1写入X=100后，节点2读取必须也是100。 -
**可用性（Availability）**🌟
每次请求都能获得有效响应。如：购物网站必须即时显示商品库存（即使数据可能不是最新）。 -
**分区容错性（Partition Tolerance）**🌟
网络故障时系统仍可运行。如：跨国服务器集群能容忍中美海底光缆中断。
2. 铁三角悖论 🚨
数学证明三者不可兼得：网络分区必然存在 → 必须在C/A中二选一。
二、实践应用案例
1. 典型场景选择
| 业务类型 | 选择方案 | 典型代表 | 牺牲项 |
|---|---|---|---|
| 内容分发网络 | AP | 阿里云CDN | 一致性 |
| 银行转账系统 | CP | 支付宝余额宝 | 可用性 |
| 实时通讯软件 | AP | 微信消息漫游 | 一致性 |
集群、分布式与微服务核心知识点总结
一、核心概念对比
1. 集群 vs 分布式
| 维度 | 集群 | 分布式 |
|---|---|---|
| 部署内容 | 同一项目的多个副本 | 不同项目/模块部署 |
| 核心目的 | 分散压力、负载均衡 | 多节点协同工作 |
| 协作方式 | 无需业务协作 | 必须跨节点通信协作 |
| 🌟生活案例 | 麦当劳10个收银台同时服务 | 快递公司分拣中心+配送站协同工作 |
2. 集群 vs 微服务
| 维度 | 集群 | 微服务 |
|---|---|---|
| 关注点 | 部署方式 | 架构设计 |
| 能力特征 | 相同能力复制 | 独立业务能力 |
| 扩展方式 | 水平扩展 | 垂直拆分 |
| 🌟生活案例 | 银行开设5个相同业务的营业厅 | 医院分设挂号、检验、药房部门 |
3. 微服务 vs 分布式
| 维度 | 微服务 | 分布式 |
|---|---|---|
| 本质属性 | 架构设计方法论 | 系统部署方案 |
| 拆分维度 | 按业务垂直拆分 | 按功能/层次拆分 |
| 必然关系 | 微服务必须分布式部署 | 分布式不一定用微服务架构 |
| 🌟生活案例 | 电商拆分成用户/订单/商品服务 | 网站前端+API服务分开部署 |
二、分布式核心理论
1. CAP定理
| 维度 | 说明 | 选择策略 |
|---|---|---|
| C一致性 | 所有节点数据实时一致 | 金融交易系统首选（如银行转账） |
| A可用性 | 每个请求都能获得响应 | 社交平台首选（如朋友圈点赞） |
| P分区容错 | 允许网络分区故障（必须保证） | 必须满足的基础要求 |
| 🌟经典组合 | CP组合（如ZooKeeper） | AP组合（如Eureka） |
2. 分布式 vs 单体架构
✅ 分布式优势
- 故障隔离：单点故障不影响全局（如支付服务宕机不影响用户注册）。
- 弹性扩展：按需扩展特定服务（如促销时单独扩容秒杀服务）。
- 技术异构：不同服务使用不同技术栈（如推荐服务用Python，交易服务用Java）。
⚠️ 单体痛点
- 牵一发而动全身：修改用户模块可能影响订单功能。
- 扩展困难：必须整体扩容，即使只有部分模块负载高。
- 技术栈固化：所有模块必须使用相同技术体系。
scan-build与clang-tidy使用)
