分布式基礎課程筆記
一、什么是分布式？
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使用)
