設(shè)計速查表：高可用、高吞吐與高擴(kuò)展的實(shí)戰(zhàn)方案)
后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載本速查表整理自 data/guides/system-design-cheat-sheet.md并輔以倉庫內(nèi)相關(guān)指南交叉印證。系統(tǒng)設(shè)計面試與真實(shí)架構(gòu)評審中最常被問到的三個核心目標(biāo)是高可用High Availability、高吞吐High Throughput、高擴(kuò)展High Scalability。讀完本文你將掌握三者的精確定義與度量方式、達(dá)成每個目標(biāo)的成熟架構(gòu)方案冗余模式、緩存策略、擴(kuò)展路徑并能依據(jù)響應(yīng)時間與可用性指標(biāo)做出可落地的架構(gòu)取舍。一、速查表講的是什么三個常被混用的設(shè)計目標(biāo)在系統(tǒng)設(shè)計場景里我們經(jīng)常被要求為高可用、高擴(kuò)展、高吞吐而設(shè)計。這三個詞看似相近實(shí)則對應(yīng)完全不同的關(guān)注點(diǎn)與衡量指標(biāo)設(shè)計目標(biāo)核心關(guān)注點(diǎn)常用度量高可用系統(tǒng)在約定水平上的持續(xù)在線能力uptime可用性百分比3 nines / 4 nines高吞吐單位時間內(nèi)能處理多少請求QPSquery per second、TPStransaction per second高擴(kuò)展能否快速、低成本地擴(kuò)容以容納更多流量或功能響應(yīng)時間、擴(kuò)容成本曲線三者在架構(gòu)上互相配合但并不等同可用性靠冗余吞吐靠緩存與并發(fā)擴(kuò)展靠架構(gòu)的可伸縮設(shè)計。下面分別展開。二、高可用High Availability用幾個九說話2.1 什么是可用性目標(biāo)高可用意味著確保系統(tǒng)達(dá)到約定級別的高在線時間uptime。我們通常用幾個九來描述設(shè)計目標(biāo)3 nines99.9% 在線時間意味著每天最多約 86.4 秒不可用每年約 8.76 小時。4 nines99.99% 在線時間意味著每天只能停機(jī) 8.64 秒每年約 52.6 分鐘。倉庫內(nèi)配套指南 data/guides/how-do-we-design-for-high-availability.md 給出了同樣的口徑當(dāng)設(shè)計目標(biāo)是 4 nines 時服務(wù)一年只能停擺約 52.5 分鐘。同時該文檔強(qiáng)調(diào)了一個容易忽略的邊界——可用性只保證能收到響應(yīng)并不保證返回的數(shù)據(jù)是最新的這為后面討論最終一致性埋下了伏筆。2.2 達(dá)成高可用的四類冗余模式要實(shí)現(xiàn)高可用核心手段是在系統(tǒng)中設(shè)計冗余redundancy。速查表給出了四種經(jīng)典模式1. Hot-hot熱-熱雙活兩個實(shí)例接收相同的輸入并把輸出同時發(fā)給下游服務(wù)。當(dāng)一側(cè)宕機(jī)時另一側(cè)可立即接管無需切換時間。關(guān)鍵代價由于兩側(cè)都在向下游發(fā)送輸出下游系統(tǒng)必須做去重dedupe否則會產(chǎn)生重復(fù)數(shù)據(jù)或重復(fù)副作用。2. Hot-warm熱-溫主備兩個實(shí)例接收相同輸入但只有**熱hot**一側(cè)向下游發(fā)送輸出當(dāng)熱側(cè)宕機(jī)時溫warm側(cè)接管并開始發(fā)送輸出。與 hot-hot 相比下游無需去重但存在切換延遲窗口。3. Single-leader cluster單主集群一個 leader 實(shí)例從上游接收數(shù)據(jù)并復(fù)制replicate到其他副本replica。這是數(shù)據(jù)庫主從復(fù)制read replica的經(jīng)典形態(tài)寫集中在 leader副本可分擔(dān)讀流量。倉庫中的 data/guides/read-replica-pattern.md 與 data/guides/how-to-implement-read-replica-pattern.md 對此有更細(xì)化的說明。4. Leaderless cluster無主集群集群中沒有 leader任何寫入都會復(fù)制到其他實(shí)例。只要寫入實(shí)例數(shù) 讀取實(shí)例數(shù) 總實(shí)例數(shù)就總能讀到有效數(shù)據(jù)。這正是 Dynamo 風(fēng)格架構(gòu)與分布式一致性 Quorum 的思想用多數(shù)派約束保證讀寫交集非空?？蓞⒖?data/guides/top-eventual-consistency-patterns-you-must-know.md 理解由此帶來的最終一致性問題。2.3 冗余之外故障容錯的配套措施速查表只給了冗余模式但要讓4 nines真正成立還必須配套故障容錯手段。data/guides/a-cheat-sheet-for-designing-fault-tolerant-systems.md 歸納了六項(xiàng)原則與速查表互為補(bǔ)充Replication復(fù)制在不同節(jié)點(diǎn)/位置保存數(shù)據(jù)或服務(wù)的多份拷貝Redundancy冗余為故障預(yù)留可隨時頂替的額外組件Load Balancing負(fù)載均衡讓流量分散到多臺服務(wù)器避免單點(diǎn)成為故障源Failover Mechanisms故障切換主組件故障時自動切換到備用組件Graceful Degradation優(yōu)雅降級部分組件失效時系統(tǒng)降級運(yùn)行而非整體崩潰Monitoring and Alerting監(jiān)控告警持續(xù)觀測健康度與性能對異常及時告警。另外data/guides/how-do-we-design-for-high-availability.md 從節(jié)點(diǎn)拓?fù)浣嵌妊a(bǔ)充了三種架構(gòu)變體Primary-Backup主備備份節(jié)點(diǎn)只待命主節(jié)點(diǎn)故障需手動切換硬件利用率低Primary-Secondary主從從節(jié)點(diǎn)可承接讀請求分擔(dān)讀負(fù)載但復(fù)制延遲會導(dǎo)致讀到不一致數(shù)據(jù)Primary-Primary雙主兩節(jié)點(diǎn)都支持讀寫并互相復(fù)制吞吐更高但適用場景有限——若兩側(cè)同時更新同一商品最終狀態(tài)可能不可預(yù)測需謹(jǐn)慎使用。該文檔還給出了一個直觀的量化例子單節(jié)點(diǎn)部署在可用性約 90% 的環(huán)境如 EC2 單機(jī)時改成雙節(jié)點(diǎn)架構(gòu)后可用性可提升至約 99%。三、高吞吐High ThroughputQPS/TPS 與三把板斧3.1 度量與含義高吞吐指在給定時間段內(nèi)處理大量請求的能力常用指標(biāo)是QPSQueries Per Second每秒查詢數(shù)TPSTransactions Per Second每秒事務(wù)數(shù)。吞吐與延遲相互影響單個請求的延遲越低、并發(fā)能力越強(qiáng)單位時間能處理的總請求數(shù)就越高。3.2 達(dá)成高吞吐的常用手段速查表給出三條路徑1. 加緩存Cache在架構(gòu)中加入緩存層讓請求直接返回避免打到數(shù)據(jù)庫、磁盤等較慢的 I/O 設(shè)備。倉庫中圍繞緩存的縱深資料非常豐富data/guides/learn-cache.md 與 data/guides/cache-systems-every-developer-should-know.md 給出緩存體系全景data/guides/top-5-caching-strategies.md 與 data/guides/what-are-the-top-caching-strategies.md 介紹緩存讀寫策略data/guides/top-8-cache-eviction-strategies.md 與 data/guides/most-popular-cache-eviction.md 覆蓋淘汰策略。2. 增加線程數(shù)并發(fā)對于計算密集型任務(wù)增加線程數(shù)量可以提升并行度。但注意線程并非越多越好過多線程會因上下文切換、鎖競爭而反而惡化性能。正確做法是先定位瓶頸再有節(jié)制地擴(kuò)容并發(fā)。3. 異步處理Async Processing用異步處理把重負(fù)載組件從主請求鏈路中隔離出來是隔離重活的有效手段。典型形態(tài)包括消息隊(duì)列與后臺 Workerdata/guides/types-of-message-queue.md 與 data/guides/explaining-the-4-most-commonly-used-types-of-queues-in-a-single-diagram.md 介紹隊(duì)列選型data/guides/how-do-message-queue-architectures-evolve.md 梳理消息隊(duì)列架構(gòu)的演進(jìn)脈絡(luò)data/guides/top-5-kafka-use-cases.md 與 data/guides/the-ultimate-kafka-101-you-cannot-miss.md 給出以 Kafka 為代表的異步解耦實(shí)戰(zhàn)。3.3 吞吐優(yōu)化的配套細(xì)節(jié)高吞吐場景下還需要配套關(guān)注負(fù)載均衡將請求分散到多臺服務(wù)器避免單機(jī)成為瓶頸。負(fù)載均衡器從實(shí)現(xiàn)上可分為硬件、軟件、云廠商托管如 AWS ELB、Google Cloud Load Balancing、Azure Load Balancer從協(xié)議層次上分為 L4按 IP/TCP/UDP 端口轉(zhuǎn)發(fā)與 L7應(yīng)用層轉(zhuǎn)發(fā)詳見 data/guides/what-is-a-load-balancer.md、data/guides/cloud-load-balancer-cheat-sheet.md。重試策略分布式與網(wǎng)絡(luò)環(huán)境下瞬態(tài)錯誤不可避免data/guides/how-do-we-retry-on-failures.md 總結(jié)了線性退避、線性抖動退避、指數(shù)退避、指數(shù)抖動退避四種策略其中指數(shù)抖動退避能最大程度避免重試風(fēng)暴retry storm導(dǎo)致的高并發(fā)下資源爭用。四、高擴(kuò)展High Scalability橫向與縱向以及何時擴(kuò)容4.1 定義能快速且容易地擴(kuò)展高擴(kuò)展意味著系統(tǒng)可以快速、輕松地擴(kuò)展以容納更多流量橫向擴(kuò)展 horizontal scalability或更多功能縱向擴(kuò)展 vertical scalability。橫向擴(kuò)展增加更多服務(wù)器節(jié)點(diǎn)把負(fù)載分?jǐn)傞_縱向擴(kuò)展單點(diǎn)能力或功能的增強(qiáng)。判斷是否需要擴(kuò)容通常觀察響應(yīng)時間response time當(dāng)響應(yīng)時間開始劣化說明現(xiàn)有容量接近上限需要觸發(fā)擴(kuò)容。4.2 擴(kuò)展的三個瓶頸data/guides/a-crash-course-on-architectural-scalability.md 進(jìn)一步剖析了阻礙擴(kuò)展的三個典型瓶頸與速查表直接呼應(yīng)集中式組件Centralized components成為單點(diǎn)故障SPOF難以水平擴(kuò)展高延遲組件High latency components執(zhí)行耗時的操作拖慢整體吞吐緊耦合Tight coupling組件相互依賴過強(qiáng)無法獨(dú)立伸縮。因此構(gòu)建可擴(kuò)展系統(tǒng)應(yīng)遵循三條原則無狀態(tài)statelessness、松耦合loose coupling、異步處理asynchronous processing。4.3 八種必知擴(kuò)展策略data/guides/8-must-know-scalability-strategies.md 把擴(kuò)展策略系統(tǒng)化為八條與速查表形成完整配套無狀態(tài)服務(wù)Stateless Services服務(wù)不依賴服務(wù)器本地狀態(tài)數(shù)據(jù)最易擴(kuò)展橫向擴(kuò)展Horizontal Scaling增加服務(wù)器分?jǐn)偣ぷ髫?fù)載負(fù)載均衡Load Balancing用負(fù)載均衡器把請求均勻分到多臺服務(wù)器自動伸縮Auto Scaling按實(shí)時流量調(diào)整資源實(shí)施擴(kuò)縮容策略緩存Caching降低數(shù)據(jù)庫壓力規(guī)?；瘧?yīng)對重復(fù)請求數(shù)據(jù)庫復(fù)制Database Replication跨多節(jié)點(diǎn)復(fù)制數(shù)據(jù)擴(kuò)展讀操作并提升冗余數(shù)據(jù)庫分片Database Sharding把數(shù)據(jù)分布到多個實(shí)例同時擴(kuò)展讀寫異步處理Async Processing把耗時、資源密集的任務(wù)轉(zhuǎn)移到后臺 Worker為新增請求騰出能力。其中分片與復(fù)制相關(guān)主題可繼續(xù)閱讀 data/guides/a-crash-course-in-database-sharding.md、data/guides/key-concepts-to-understand-database-sharding.md、data/guides/top-4-data-sharding-algorithms-explained.md 與 data/guides/consistent-hashing.md。五、三者的權(quán)衡可用性、一致性與吞吐的邊界速查表的三節(jié)內(nèi)容彼此獨(dú)立但真實(shí)架構(gòu)中它們經(jīng)?；ハ酄恐朴袃蓚€關(guān)鍵邊界必須記住可用性 ≠ 數(shù)據(jù)新鮮度高可用只承諾有響應(yīng)不承諾數(shù)據(jù)最新。冗余復(fù)制引入的復(fù)制延遲正是 data/guides/top-eventual-consistency-patterns-you-must-know.md 中四類最終一致性模式事件驅(qū)動、后臺同步、Saga、CQRS要解決的問題。線程數(shù) ≠ 吞吐盲目加線程反而劣化性能吞吐優(yōu)化的正確姿勢是先找瓶頸再定向擴(kuò)容并用異步處理把重活移出主鏈路。此外倉庫還提供了更宏觀的權(quán)衡視角data/guides/10-system-design-tradeoffs-you-cannot-ignore.md、data/guides/top-5-trade-offs-in-system-designs.md以及面試向的 data/guides/algorithms-you-should-know-before-taking-system-design-interviews.md可作為繼續(xù)深挖的入口。六、速查表使用方式與倉庫定位本篇速查表在倉庫中歸屬Cloud Distributed Systems分類見 data/categories/cloud-distributed-systems.md其定位是一頁圖看懂三大設(shè)計目標(biāo)適合在系統(tǒng)設(shè)計面試前做快速復(fù)習(xí)、在架構(gòu)評審時做方案對齊。倉庫通過 scripts/readme.ts依賴 gray-matter 解析每篇指南的 front matter按分類與創(chuàng)建時間排序自動生成 README 目錄每篇指南文件均以title、description、categories、tags等元信息開頭如本文件data/guides/system-design-cheat-sheet.md的 front matter保證了分類與檢索的一致性——這也是搜索引擎與 Agent 能夠高效定位本文的前提。一句話使用建議面試或評審前先用本文把三個九 / QPS / 響應(yīng)時間這三組口徑說清楚再按需切入上文的對應(yīng)專題文檔展開細(xì)節(jié)。這比一上來就堆砌組件更能體現(xiàn)對系統(tǒng)設(shè)計的本質(zhì)理解。贊分享后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載相關(guān)推薦EnergyBar深度評測為什么它是Mac Touch Bar的最佳替代方案EnergyBar深度評測為什么它是Mac Touch Bar的最佳替代方案 EnergyBar是一款能夠?yàn)镸ac Touch Bar帶來全新生命力的實(shí)用工具system-design-101 可擴(kuò)展性指南8 大必備擴(kuò)展策略與系統(tǒng)設(shè)計實(shí)踐system design 101 可擴(kuò)展性指南8 大必備擴(kuò)展策略與系統(tǒng)設(shè)計實(shí)踐 本篇指南以倉庫 8 must know scalability strate后端文檔教程System Design 101從零構(gòu)建高性能報表系統(tǒng)架構(gòu)的完整指南System Design 101從零構(gòu)建高性能報表系統(tǒng)架構(gòu)的完整指南 在當(dāng)今數(shù)據(jù)驅(qū)動的時代報表系統(tǒng)作為業(yè)務(wù)決策的核心工具其架構(gòu)設(shè)計直接影響企業(yè)的數(shù)據(jù)分析后端文檔教程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 System Design 101 系統(tǒng)設(shè)計速查表：高可用、高吞吐與高擴(kuò)展的實(shí)戰(zhàn)方案
后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載本速查表整理自 data/guides/system-design-cheat-sheet.md并輔以倉庫內(nèi)相關(guān)指南交叉印證。系統(tǒng)設(shè)計面試與真實(shí)架構(gòu)評審中最常被問到的三個核心目標(biāo)是高可用High Availability、高吞吐High Throughput、高擴(kuò)展High Scalability。讀完本文你將掌握三者的精確定義與度量方式、達(dá)成每個目標(biāo)的成熟架構(gòu)方案冗余模式、緩存策略、擴(kuò)展路徑并能依據(jù)響應(yīng)時間與可用性指標(biāo)做出可落地的架構(gòu)取舍。一、速查表講的是什么三個常被混用的設(shè)計目標(biāo)在系統(tǒng)設(shè)計場景里我們經(jīng)常被要求為高可用、高擴(kuò)展、高吞吐而設(shè)計。這三個詞看似相近實(shí)則對應(yīng)完全不同的關(guān)注點(diǎn)與衡量指標(biāo)設(shè)計目標(biāo)核心關(guān)注點(diǎn)常用度量高可用系統(tǒng)在約定水平上的持續(xù)在線能力uptime可用性百分比3 nines / 4 nines高吞吐單位時間內(nèi)能處理多少請求QPSquery per second、TPStransaction per second高擴(kuò)展能否快速、低成本地擴(kuò)容以容納更多流量或功能響應(yīng)時間、擴(kuò)容成本曲線三者在架構(gòu)上互相配合但并不等同可用性靠冗余吞吐靠緩存與并發(fā)擴(kuò)展靠架構(gòu)的可伸縮設(shè)計。下面分別展開。二、高可用High Availability用幾個九說話2.1 什么是可用性目標(biāo)高可用意味著確保系統(tǒng)達(dá)到約定級別的高在線時間uptime。我們通常用幾個九來描述設(shè)計目標(biāo)3 nines99.9% 在線時間意味著每天最多約 86.4 秒不可用每年約 8.76 小時。4 nines99.99% 在線時間意味著每天只能停機(jī) 8.64 秒每年約 52.6 分鐘。倉庫內(nèi)配套指南 data/guides/how-do-we-design-for-high-availability.md 給出了同樣的口徑當(dāng)設(shè)計目標(biāo)是 4 nines 時服務(wù)一年只能停擺約 52.5 分鐘。同時該文檔強(qiáng)調(diào)了一個容易忽略的邊界——可用性只保證能收到響應(yīng)并不保證返回的數(shù)據(jù)是最新的這為后面討論最終一致性埋下了伏筆。2.2 達(dá)成高可用的四類冗余模式要實(shí)現(xiàn)高可用核心手段是在系統(tǒng)中設(shè)計冗余redundancy。速查表給出了四種經(jīng)典模式1. Hot-hot熱-熱雙活兩個實(shí)例接收相同的輸入并把輸出同時發(fā)給下游服務(wù)。當(dāng)一側(cè)宕機(jī)時另一側(cè)可立即接管無需切換時間。關(guān)鍵代價由于兩側(cè)都在向下游發(fā)送輸出下游系統(tǒng)必須做去重dedupe否則會產(chǎn)生重復(fù)數(shù)據(jù)或重復(fù)副作用。2. Hot-warm熱-溫主備兩個實(shí)例接收相同輸入但只有**熱hot**一側(cè)向下游發(fā)送輸出當(dāng)熱側(cè)宕機(jī)時溫warm側(cè)接管并開始發(fā)送輸出。與 hot-hot 相比下游無需去重但存在切換延遲窗口。3. Single-leader cluster單主集群一個 leader 實(shí)例從上游接收數(shù)據(jù)并復(fù)制replicate到其他副本replica。這是數(shù)據(jù)庫主從復(fù)制read replica的經(jīng)典形態(tài)寫集中在 leader副本可分擔(dān)讀流量。倉庫中的 data/guides/read-replica-pattern.md 與 data/guides/how-to-implement-read-replica-pattern.md 對此有更細(xì)化的說明。4. Leaderless cluster無主集群集群中沒有 leader任何寫入都會復(fù)制到其他實(shí)例。只要寫入實(shí)例數(shù) 讀取實(shí)例數(shù) 總實(shí)例數(shù)就總能讀到有效數(shù)據(jù)。這正是 Dynamo 風(fēng)格架構(gòu)與分布式一致性 Quorum 的思想用多數(shù)派約束保證讀寫交集非空?？蓞⒖?data/guides/top-eventual-consistency-patterns-you-must-know.md 理解由此帶來的最終一致性問題。2.3 冗余之外故障容錯的配套措施速查表只給了冗余模式但要讓4 nines真正成立還必須配套故障容錯手段。data/guides/a-cheat-sheet-for-designing-fault-tolerant-systems.md 歸納了六項(xiàng)原則與速查表互為補(bǔ)充Replication復(fù)制在不同節(jié)點(diǎn)/位置保存數(shù)據(jù)或服務(wù)的多份拷貝Redundancy冗余為故障預(yù)留可隨時頂替的額外組件Load Balancing負(fù)載均衡讓流量分散到多臺服務(wù)器避免單點(diǎn)成為故障源Failover Mechanisms故障切換主組件故障時自動切換到備用組件Graceful Degradation優(yōu)雅降級部分組件失效時系統(tǒng)降級運(yùn)行而非整體崩潰Monitoring and Alerting監(jiān)控告警持續(xù)觀測健康度與性能對異常及時告警。另外data/guides/how-do-we-design-for-high-availability.md 從節(jié)點(diǎn)拓?fù)浣嵌妊a(bǔ)充了三種架構(gòu)變體Primary-Backup主備備份節(jié)點(diǎn)只待命主節(jié)點(diǎn)故障需手動切換硬件利用率低Primary-Secondary主從從節(jié)點(diǎn)可承接讀請求分擔(dān)讀負(fù)載但復(fù)制延遲會導(dǎo)致讀到不一致數(shù)據(jù)Primary-Primary雙主兩節(jié)點(diǎn)都支持讀寫并互相復(fù)制吞吐更高但適用場景有限——若兩側(cè)同時更新同一商品最終狀態(tài)可能不可預(yù)測需謹(jǐn)慎使用。該文檔還給出了一個直觀的量化例子單節(jié)點(diǎn)部署在可用性約 90% 的環(huán)境如 EC2 單機(jī)時改成雙節(jié)點(diǎn)架構(gòu)后可用性可提升至約 99%。三、高吞吐High ThroughputQPS/TPS 與三把板斧3.1 度量與含義高吞吐指在給定時間段內(nèi)處理大量請求的能力常用指標(biāo)是QPSQueries Per Second每秒查詢數(shù)TPSTransactions Per Second每秒事務(wù)數(shù)。吞吐與延遲相互影響單個請求的延遲越低、并發(fā)能力越強(qiáng)單位時間能處理的總請求數(shù)就越高。3.2 達(dá)成高吞吐的常用手段速查表給出三條路徑1. 加緩存Cache在架構(gòu)中加入緩存層讓請求直接返回避免打到數(shù)據(jù)庫、磁盤等較慢的 I/O 設(shè)備。倉庫中圍繞緩存的縱深資料非常豐富data/guides/learn-cache.md 與 data/guides/cache-systems-every-developer-should-know.md 給出緩存體系全景data/guides/top-5-caching-strategies.md 與 data/guides/what-are-the-top-caching-strategies.md 介紹緩存讀寫策略data/guides/top-8-cache-eviction-strategies.md 與 data/guides/most-popular-cache-eviction.md 覆蓋淘汰策略。2. 增加線程數(shù)并發(fā)對于計算密集型任務(wù)增加線程數(shù)量可以提升并行度。但注意線程并非越多越好過多線程會因上下文切換、鎖競爭而反而惡化性能。正確做法是先定位瓶頸再有節(jié)制地擴(kuò)容并發(fā)。3. 異步處理Async Processing用異步處理把重負(fù)載組件從主請求鏈路中隔離出來是隔離重活的有效手段。典型形態(tài)包括消息隊(duì)列與后臺 Workerdata/guides/types-of-message-queue.md 與 data/guides/explaining-the-4-most-commonly-used-types-of-queues-in-a-single-diagram.md 介紹隊(duì)列選型data/guides/how-do-message-queue-architectures-evolve.md 梳理消息隊(duì)列架構(gòu)的演進(jìn)脈絡(luò)data/guides/top-5-kafka-use-cases.md 與 data/guides/the-ultimate-kafka-101-you-cannot-miss.md 給出以 Kafka 為代表的異步解耦實(shí)戰(zhàn)。3.3 吞吐優(yōu)化的配套細(xì)節(jié)高吞吐場景下還需要配套關(guān)注負(fù)載均衡將請求分散到多臺服務(wù)器避免單機(jī)成為瓶頸。負(fù)載均衡器從實(shí)現(xiàn)上可分為硬件、軟件、云廠商托管如 AWS ELB、Google Cloud Load Balancing、Azure Load Balancer從協(xié)議層次上分為 L4按 IP/TCP/UDP 端口轉(zhuǎn)發(fā)與 L7應(yīng)用層轉(zhuǎn)發(fā)詳見 data/guides/what-is-a-load-balancer.md、data/guides/cloud-load-balancer-cheat-sheet.md。重試策略分布式與網(wǎng)絡(luò)環(huán)境下瞬態(tài)錯誤不可避免data/guides/how-do-we-retry-on-failures.md 總結(jié)了線性退避、線性抖動退避、指數(shù)退避、指數(shù)抖動退避四種策略其中指數(shù)抖動退避能最大程度避免重試風(fēng)暴retry storm導(dǎo)致的高并發(fā)下資源爭用。四、高擴(kuò)展High Scalability橫向與縱向以及何時擴(kuò)容4.1 定義能快速且容易地擴(kuò)展高擴(kuò)展意味著系統(tǒng)可以快速、輕松地擴(kuò)展以容納更多流量橫向擴(kuò)展 horizontal scalability或更多功能縱向擴(kuò)展 vertical scalability。橫向擴(kuò)展增加更多服務(wù)器節(jié)點(diǎn)把負(fù)載分?jǐn)傞_縱向擴(kuò)展單點(diǎn)能力或功能的增強(qiáng)。判斷是否需要擴(kuò)容通常觀察響應(yīng)時間response time當(dāng)響應(yīng)時間開始劣化說明現(xiàn)有容量接近上限需要觸發(fā)擴(kuò)容。4.2 擴(kuò)展的三個瓶頸data/guides/a-crash-course-on-architectural-scalability.md 進(jìn)一步剖析了阻礙擴(kuò)展的三個典型瓶頸與速查表直接呼應(yīng)集中式組件Centralized components成為單點(diǎn)故障SPOF難以水平擴(kuò)展高延遲組件High latency components執(zhí)行耗時的操作拖慢整體吞吐緊耦合Tight coupling組件相互依賴過強(qiáng)無法獨(dú)立伸縮。因此構(gòu)建可擴(kuò)展系統(tǒng)應(yīng)遵循三條原則無狀態(tài)statelessness、松耦合loose coupling、異步處理asynchronous processing。4.3 八種必知擴(kuò)展策略data/guides/8-must-know-scalability-strategies.md 把擴(kuò)展策略系統(tǒng)化為八條與速查表形成完整配套無狀態(tài)服務(wù)Stateless Services服務(wù)不依賴服務(wù)器本地狀態(tài)數(shù)據(jù)最易擴(kuò)展橫向擴(kuò)展Horizontal Scaling增加服務(wù)器分?jǐn)偣ぷ髫?fù)載負(fù)載均衡Load Balancing用負(fù)載均衡器把請求均勻分到多臺服務(wù)器自動伸縮Auto Scaling按實(shí)時流量調(diào)整資源實(shí)施擴(kuò)縮容策略緩存Caching降低數(shù)據(jù)庫壓力規(guī)?；瘧?yīng)對重復(fù)請求數(shù)據(jù)庫復(fù)制Database Replication跨多節(jié)點(diǎn)復(fù)制數(shù)據(jù)擴(kuò)展讀操作并提升冗余數(shù)據(jù)庫分片Database Sharding把數(shù)據(jù)分布到多個實(shí)例同時擴(kuò)展讀寫異步處理Async Processing把耗時、資源密集的任務(wù)轉(zhuǎn)移到后臺 Worker為新增請求騰出能力。其中分片與復(fù)制相關(guān)主題可繼續(xù)閱讀 data/guides/a-crash-course-in-database-sharding.md、data/guides/key-concepts-to-understand-database-sharding.md、data/guides/top-4-data-sharding-algorithms-explained.md 與 data/guides/consistent-hashing.md。五、三者的權(quán)衡可用性、一致性與吞吐的邊界速查表的三節(jié)內(nèi)容彼此獨(dú)立但真實(shí)架構(gòu)中它們經(jīng)?；ハ酄恐朴袃蓚€關(guān)鍵邊界必須記住可用性 ≠ 數(shù)據(jù)新鮮度高可用只承諾有響應(yīng)不承諾數(shù)據(jù)最新。冗余復(fù)制引入的復(fù)制延遲正是 data/guides/top-eventual-consistency-patterns-you-must-know.md 中四類最終一致性模式事件驅(qū)動、后臺同步、Saga、CQRS要解決的問題。線程數(shù) ≠ 吞吐盲目加線程反而劣化性能吞吐優(yōu)化的正確姿勢是先找瓶頸再定向擴(kuò)容并用異步處理把重活移出主鏈路。此外倉庫還提供了更宏觀的權(quán)衡視角data/guides/10-system-design-tradeoffs-you-cannot-ignore.md、data/guides/top-5-trade-offs-in-system-designs.md以及面試向的 data/guides/algorithms-you-should-know-before-taking-system-design-interviews.md可作為繼續(xù)深挖的入口。六、速查表使用方式與倉庫定位本篇速查表在倉庫中歸屬Cloud Distributed Systems分類見 data/categories/cloud-distributed-systems.md其定位是一頁圖看懂三大設(shè)計目標(biāo)適合在系統(tǒng)設(shè)計面試前做快速復(fù)習(xí)、在架構(gòu)評審時做方案對齊。倉庫通過 scripts/readme.ts依賴 gray-matter 解析每篇指南的 front matter按分類與創(chuàng)建時間排序自動生成 README 目錄每篇指南文件均以title、description、categories、tags等元信息開頭如本文件data/guides/system-design-cheat-sheet.md的 front matter保證了分類與檢索的一致性——這也是搜索引擎與 Agent 能夠高效定位本文的前提。一句話使用建議面試或評審前先用本文把三個九 / QPS / 響應(yīng)時間這三組口徑說清楚再按需切入上文的對應(yīng)專題文檔展開細(xì)節(jié)。這比一上來就堆砌組件更能體現(xiàn)對系統(tǒng)設(shè)計的本質(zhì)理解。贊分享后端文檔教程【免費(fèi)下載鏈接】system-design-101Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.項(xiàng)目地址https://gitcode.com/GitHub_Trending/sy/system-design-101點(diǎn)擊查看免費(fèi)下載相關(guān)推薦EnergyBar深度評測為什么它是Mac Touch Bar的最佳替代方案EnergyBar深度評測為什么它是Mac Touch Bar的最佳替代方案 EnergyBar是一款能夠?yàn)镸ac Touch Bar帶來全新生命力的實(shí)用工具system-design-101 可擴(kuò)展性指南8 大必備擴(kuò)展策略與系統(tǒng)設(shè)計實(shí)踐system design 101 可擴(kuò)展性指南8 大必備擴(kuò)展策略與系統(tǒng)設(shè)計實(shí)踐 本篇指南以倉庫 8 must know scalability strate后端文檔教程System Design 101從零構(gòu)建高性能報表系統(tǒng)架構(gòu)的完整指南System Design 101從零構(gòu)建高性能報表系統(tǒng)架構(gòu)的完整指南 在當(dāng)今數(shù)據(jù)驅(qū)動的時代報表系統(tǒng)作為業(yè)務(wù)決策的核心工具其架構(gòu)設(shè)計直接影響企業(yè)的數(shù)據(jù)分析后端文檔教程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考