<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>System Design on Intellectual Guides</title><link>https://ckw19810413.github.io/tags/system-design/</link><description>Recent content in System Design on Intellectual Guides</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><lastBuildDate>Thu, 17 Sep 2026 08:00:00 +0800</lastBuildDate><atom:link href="https://ckw19810413.github.io/tags/system-design/index.xml" rel="self" type="application/rss+xml"/><item><title>每日研究生知識寓言故事：雙子島的神秘魔法帳本</title><link>https://ckw19810413.github.io/blog/cap-theorem-fable/</link><pubDate>Thu, 17 Sep 2026 08:00:00 +0800</pubDate><guid>https://ckw19810413.github.io/blog/cap-theorem-fable/</guid><description>&lt;p&gt;在蔚藍之海中，有兩座繁華的島嶼——「日出島」與「月落島」。兩座島嶼的商會會長決定共同開設一家名為「雙子星」的跨島錢莊。&lt;/p&gt;
&lt;p&gt;為了讓商人們在兩座島上都能隨時存取金幣，錢莊在兩島各設了一個分部，並對外宣告了一個極高的服務標準：
第一：客人無論在哪一座島查詢餘額，看到的數字必須完全一致（這叫「帳目一致」）。
第二：只要錢莊開門營業，客人隨時來辦理存取款，櫃檯都必須立刻受理，不能拒絕或讓客人無盡地等待（這叫「絕對服務」）。&lt;/p&gt;
&lt;p&gt;為了達成這兩個標準，兩座島的錢莊經理雇用了世界上飛得最快的傳信鴿。每當日出島有客人存入一筆錢，經理就會立刻飛鴿傳書給月落島；直到月落島回信說「帳本已同步修改」，這筆交易才算完成。反之亦然。在平靜的日子裡，這個系統運作得非常完美。&lt;/p&gt;
&lt;p&gt;然而，到了狂風暴雨的颱風季，問題發生了。
一場可怕的風暴席捲了兩島之間的海域，所有的傳信鴿都無法穿越風暴，兩島之間徹底失去了聯繫（這稱為「通訊斷裂」）。&lt;/p&gt;
&lt;p&gt;這時候，日出島的錢莊走進了一位客人，要求存入一千枚金幣。
日出島的經理陷入了前所未有的兩難。他發現自己面臨一個無法破解的死局。&lt;/p&gt;
&lt;p&gt;如果他選擇&lt;strong&gt;收下金幣&lt;/strong&gt;（遵守「絕對服務」），他的帳本餘額就會增加，但他無法通知月落島。結果就是，兩座島的帳本數字變得不一樣了，他違背了「帳目一致」的承諾。
如果他選擇&lt;strong&gt;維持帳目一致&lt;/strong&gt;，他就必須對客人說：「抱歉，因為我們無法聯絡另一座島，所以現在暫停所有交易。」這樣一來，雖然兩邊帳本還是相同的（都沒有變動），但他違背了「絕對服務」的承諾。&lt;/p&gt;
&lt;p&gt;風暴期間，錢莊無法同時做到「帳目一致」和「絕對服務」。經理最終明白了一個殘酷的真理：在兩地通訊可能中斷的現實世界裡，錢莊的兩大完美承諾，註定只能選擇其中一個。&lt;/p&gt;
&lt;hr&gt;
&lt;h3 id="揭曉與解釋"&gt;揭曉與解釋
&lt;/h3&gt;&lt;p&gt;這則寓言講述的是分散式系統（Distributed Systems）中著名的 &lt;strong&gt;CAP定理（CAP Theorem）&lt;/strong&gt;，也稱為布魯爾定理（Brewer&amp;rsquo;s Theorem）。&lt;/p&gt;
&lt;p&gt;CAP定理指出，在一個分散式計算系統中，最多只能同時滿足以下三項特性中的兩項：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;一致性（Consistency）&lt;/strong&gt;：在分散式系統中的所有資料節點，在同一時間具有相同的資料。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;可用性（Availability）&lt;/strong&gt;：每個請求都能收到一個（非錯誤的）回應，無論成功或失敗。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;分區容錯性（Partition tolerance）&lt;/strong&gt;：系統在節點之間的網路通訊丟失或延遲（即產生了網路分區）時，仍能繼續運作。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;寓言中的隱喻對應如下：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;雙子星錢莊的兩座島嶼分部&lt;/strong&gt;：分散式系統中的多個資料節點（Nodes）。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;帳目一致&lt;/strong&gt;：對應 &lt;strong&gt;一致性 (Consistency, C)&lt;/strong&gt;。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;絕對服務&lt;/strong&gt;：對應 &lt;strong&gt;可用性 (Availability, A)&lt;/strong&gt;。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;風暴阻斷飛鴿傳書&lt;/strong&gt;：對應 &lt;strong&gt;分區容錯性 (Partition Tolerance, P)&lt;/strong&gt; 中的網路分區（通訊斷裂）情況。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;CAP定理的核心洞見在於：在現實的網路環境中，網路故障（風暴）是無可避免的，因此系統必須具備「分區容錯性 (P)」。既然 P 是必備的，當網路斷裂發生時，系統設計師就只能在 C 和 A 之間做出取捨：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;選擇 CP (一致性 + 分區容錯)&lt;/strong&gt;：暫停服務直到網路恢復（拒絕客人的存款），確保資料絕不出錯。這常見於銀行或金融交易系統，因為帳目錯誤的代價極高。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;選擇 AP (可用性 + 分區容錯)&lt;/strong&gt;：繼續提供服務，接受資料可能暫時不一致（收下客人的存款，事後再同步）。這常見於社群網站的按讚數或大型電商的購物車，確保使用者體驗不中斷。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;世上沒有完美的雲端錢莊，所有的架構設計，都是在風暴來臨前，先決定好你要犧牲哪一個承諾。&lt;/p&gt;</description></item></channel></rss>