空間式架構風格

前言

網路應用程式在面對高並發使用者負載時所會遇到的問題，以及如何使用「空間式架構風格」來解決這些問題。

網路應用程式的傳統流程：

• 網路應用程式通常會經歷一個固定的請求流程：瀏覽器 → Web 伺服器 → 應用伺服器 → 資料庫伺服器。

• 雖然這個模式對於少量用戶來說表現不錯，但隨著用戶負載的增加，瓶頸會逐漸出現。 首先在 網站伺服器層，然後在應用伺服器層，最後在資料庫伺服器層。

負載和擴展的問題：

• 當用戶負載增加時，常見的應對方式是擴展網頁伺服器。這相對容易且不費太多成本，有時可以解決瓶頸問題。

• 然而，在高用戶負載的情況下，擴展網頁伺服器只會將瓶頸移至應用伺服器。擴展應用伺服器可能比擴展網頁伺服器更複雜且昂貴，並且通常會將瓶頸移至資料庫伺服器。

極限擴展和三角形拓撲：

• 即使能夠擴展資料庫，最終會形成三角形拓撲，其中最寬的部分是網頁伺服器（最容易擴展），而最小的部分是資料庫（最難擴展）

(越往後面擴展，難度與成本越高昂)

高負載情況下的資料庫限制：

• 在高交易量的應用程式中，資料庫通常是限制同時處理交易數的最終因素。

• 儘管各種快取技術和資料庫擴展產品有助於解決這些問題，但對於極端負載的應用程式進行擴展是一個非常困難的。

空間式架構風格的解決方案：

• 空間式架構風格專門設計用於解決高擴展性、彈性和高並發問題。

• 這種架構風格也適用於具有變化和不可預測的同時使用者數量的應用程式。

• 從架構上解決極端和變化的擴展性問題通常比試圖對資料庫進行擴展或將快取技術融入不可擴展的架構更好。

一般性拓墣結構

概念：

空間式架構是運用複製內存資料網格，解決大規模應用的可擴展性和性能問題，通過非同步處理實現高效資料同步。

• 空間型架構以「元組空間(Tuple space)」概念為基礎。使用多個平行處理器透過共享記憶體進行通訊。

• 通過移除中央資料庫作為同步約束，採用複製的內存資料網格實現高擴展性、高彈性和高性能。

• 應用程式資料保存在內存中，並在所有活躍的處理單元之間進行複製。

• 處理單元以異步方式將資料發送到資料庫，通常透過帶有持久隊列的消息傳遞。

• 隨著使用者負載的增減，處理單元動態啟動和關閉，因此實現了可變的擴展性需求。

• 由於標準交易處理中沒有中央資料庫的參與，因此解決了資料庫瓶頸問題，在應用程式內實現了幾乎無限的擴展性。

空間式架構組件:

• 處理單元（Processing Units）：包含應用程式邏輯（或應用程式邏輯的一部分）。

• 虛擬化中介軟體（Virtualized Middleware）：用於管理和協調處理單元。

• 資料幫補（Data Pumps）：用異步方式將更新的資料發送到資料庫。

• 資料讀取器（Data Readers）：啟動時讀取資料庫資料並傳送給處理單元。

• 資料寫入器（Data Writers）：從資料幫補接收更新的資料，將其寫入資料庫。

空間式架構組件介紹：

處理單元 (Processing Unit)

應用邏輯容器，包含邏輯、資料網格和複製引擎，用於處理不同功能的應用程式。

• 「處理單元」包含應用程式邏輯，可能是整個應用程式邏輯或部分應用程式邏輯。
• 其內容通常包括基於網頁的組件和後端業務邏輯。
• 根據應用程式的類型，處理單元的內容可能會有所不同。
• 較小的應用程式可能部署在單個處理單元中。
• 較大的應用程式可能根據功能區域將應用功能分成多個處理單元。
• 處理單元還可以包含小型的、單一用途的服務，類似於微服務的概念。
• 除了應用程式邏輯外，處理單元還包含內存資料網格和複製引擎。
• 內存資料網格和複製引擎通常通過產品如 Hazelcast、Apache Ignite 和 Oracle Coherence 來實現。

虛擬化中介軟體 (Virtualized Middleware)

• 虛擬化中介軟體是空間式架構中的一個關鍵組成部分，負責處理架構內控制資料同步和請求處理等基礎事務。

• 虛擬化中介軟體包括:

  • 傳訊網格(Messaging Grid)
  • 資料網格(Data Grid)
  • 處理網格(Processing Grid)
  • 部署管理器(Deployment Manager)

• 這些組件可以自行開發，也可以購買現成的第三方產品。

傳訊網格 (Messaging Grid)

• 負責管理輸入請求和會話狀態。

• 當請求進入虛擬化中間件時，傳訊網格會確定哪些處理元件可以接收請求，並將請求轉發給其中一個處理單元。

• 傳訊網格的判斷傳遞給哪一個處理單元的演算法：

  • 輪詢演算法(round-robin)
  • 下個可用演算法(next-available)：追蹤哪個請求正在被哪一個單元處理。

• 使用具有負載平衡功能的典型 Web 伺服器實現，如 HA Proxy 和 Nginx。

資料網格(Data Grid)

資料網格在空間式架構中扮演著極重要和關鍵的角色。它的主要功能是確保所有的處理單元都有相同的資料內容，這樣不論在哪個處理單元進行資料操作，其他處理單元也能即時同步更新。

資料網格是什麼

• 資料網格是一個特殊的儲存空間，用來儲存和分享資料。

• 在現代實現中，通常以複製的快取形式存在處理單元內。

複製快取實現

• 複製快取在處理單元內以及虛擬中間件的資料網格組件中都可能存在。

• 當需要外部控制器的複製快取實現或使用分佈式快取時，功能也會存在於這些組件中。

資料同步的重要性

• 傳訊網格可以將請求轉發至任何可用的處理單元，因此每個處理單元的內存資料網格都需要包含相同的資料。

• 保證資料同步對於確保資料的一致性至關重要。

資料同步運作方式

• 圖中顯示的處理單元之間的資料同步是異步和高效的，通常在不到 100 毫秒的時間內完成。

命名資料網格的同步

• 以 Java 和 Hazelcast 為例，內部創建一個複製的資料網格，用於儲存客戶檔案信息等。

• 處理單元間對於名為 CustomerProfile 的快取所做的更改會被複製到所有相同名稱快取的處理單元中。

處理單元間協作

• 每個處理單元通過成員清單（含 IP 地址和端口）來了解其他處理單元的存在。

• 這種協作方式確保了不同處理單元之間的資料同步，即使其中一些處理單元因關閉或故障而變得不可用。

處理網格（Processing grid）

處理網格是虛擬化中介軟體中的一個可選組件，其主要功能是管理當單一業務請求涉及多個處理單元時的協調處理。

部署管理器

部署管理器是虛擬中介軟體中的一個重要組成部分，負責根據負載情況動態啟動和關閉處理單元實例。

• 管理動態處理單元的啟動和關閉。

• 持續監控響應時間和用戶負載。

• 根據負載增減啟動和關閉處理單元。

• 實現應用程式的可變擴展性（彈性）需求。

資料幫補 (Data Pumps)

資料幫補是一種將資料傳送到另一個處理器，然後再更新資料庫的方法。

當某處理單元收到請求並更新快取，處理單元便擁有該項更新，所以得負責透過資料幫補傳送該項更新，使資料庫最終也得到更新。

• 用於將資料傳送到處理器(資料寫入器)，然後更新資料庫中的資料。

• 在空間式架構中，資料幫補是必要的組件。

• 資料幫補始終是異步的，實現處理元件裡內存快取和資料庫的最終一致性。

• 處理單元不直接從資料庫讀取和寫入資料。

• 資料幫補通常使用傳訊方式實作，因為傳訊支援非同步通信，保證送達，並透過先進先出(FIFO)保持訊息的順序。

• 空間式架構中通常有好幾個資料幫補：

  1. 專用於特定領域或子領域的處理單元(客戶或庫存)。
  2. 專門服務某種快取(CustomerProfile, CustomerWishlist...)
  3. 專屬於一個擁有更大且通用之快取的處理單元領域(客戶)

• 資料幫補的合約包括與合約資料相關的操作（添加、刪除或更新）。

• 合約可能是 JSON、XML、Object，甚至是由值驅動的訊息(key-value)

• 資料幫補的訊息通常僅包含新的資料值(更新客戶的電話號碼，只傳送客戶 id、新的電話號碼，以及更新資料的動作)。

資料寫入器（Data Writers）

資料寫入器（Data Writers）接受資料幫補（Data Pumps）的訊息，然後使用資料幫補訊息中的資訊更新資料庫

• 資料寫入器接受來自資料幫補的訊息，將其中的資訊用於更新資料庫。

• 資料寫入器可以實作為服務、應用程式或資料中樞(Ab Initio)。

• 基於領域的資料寫入器包含處理特定領域（如客戶）內所有更新所需的資料庫邏輯。

• 基於領域的資料寫入器可以同時接收多個資料幫補的訊息，並用於更新相關的資料庫資料。 或者，每個處理元件類別可以有自己的專用資料寫入器，專門處理該處理元件的資料庫處理邏輯。

• 雖然可能會產生過多的資料寫入器，但由於處理元件、資料幫補和資料寫入器的協調一致，所以能提供更好的可擴展性和靈活性。

基於領域的資料寫入器包含處理特定領域（如客戶）內所有更新所需的資料庫邏輯。

每個處理元件類別可以有自己的專用資料寫入器，專門處理該處理元件的資料庫處理邏輯。

資料讀取器

資料讀取器（Data Readers）負責從資料庫讀取資料，並透過反向資料幫補（Reverse Data Pump）將資料傳送給處理元件。

• 資料讀取器負責從資料庫讀取資料，並透過反向資料幫補將資料傳送給處理元件。

• 資料讀取器主要在三種情況下被呼叫：

  1. 所有相同名稱快取的處理元件實例崩潰
  2. 重新部署所有擁有相同名稱快取的處理元件
  3. 提取不在複製快取內的封存資料

• 當所有處理單元的實例都關閉時（系統全面崩潰或所有實例的重新部署），必須從資料庫讀取資料（通常在空間基礎架構中避免這麼做）。

• 當某個處理單元類別的實例開始啟動時，每個實例都嘗試鎖定快取。第一個獲得鎖定的實例成為臨時快取擁有者，其他實例進入等待狀態，直到鎖定被釋放（根據使用的快取實作類型可能有所不同）。

• 以域為基礎的資料讀取器包含處理特定域（如客戶）內所有更新所需的資料庫邏輯，。

• 資料讀取元件和資料寫入元件基本上形成資料抽象層(或在某些情況下稱為資料存取層）的結構。

• 資料抽象層和資料存取層之間的差異在於處理元件對資料庫中表格（或架構）結構的詳細知識的程度。

• 空間式架構通常依賴於資料抽象層模型，以便處理元件中的複製快取模式可以不同於底層資料庫表格結構。

• 資料寫入器和資料讀取器包含轉換邏輯，以便在資料庫進行更改時可以暫時保留變更，直到處理單元快取可以進行必要的更改。

資料衝突

資料衝突是當多個服務同時更新快取，因複製延遲造成資料不一致的情況。可用公式估算衝突機會，決定是否使用複製快取。

• 資料衝突是在使用複製快取的空間基礎架構中可能發生的情況，當多個實例中的快取更新時可能出現。

• 資料衝突是由於複製延遲導致的，即在更新到快取 B 的過程中，快取 A 同時進行了更新，造成資料不一致。

• 在複製快取的情況下，需要考慮複製延遲、更新率、快取大小等因素，以確定資料衝突的可能性。

• 使用以下公式可以估計基於不同因素的潛在資料衝突數量：

  • CollisionRate = N x (UR^2 / S) x RL
  • N：使用相同名稱快取的服務實例數量
  • UR：更新率（毫秒的平方）
  • S：快取大小（列數）
  • RL：複製延遲

• 不同因素的變化可以影響資料衝突的數量，例如複製延遲、服務實例數量和快取大小。

• 計算資料衝突數量可以幫助確定使用複製快取的可行性，並確保資料一致性。

• 實際應用中，通常會根據最大的更新率進行計算，以確保資料衝突不會對系統造成過大的影響。

範例：

假設有兩個服務實例，分別是服務 A 和服務 B，都有一個複製的商品庫存快取。當同時有兩個更新動作發生時，由於複製的時間差，可能導致資料不一致，造成衝突。

1. 當前藍色小部件的庫存為 500 個。
2. 服務 A 將藍色小部件的庫存更新為 490 個（賣出 10 個）。
3. 在複製過程中，服務 B 將藍色小部件的庫存更新為 495 個（賣出 5 個）。
4. 服務 B 的庫存在複製時被更新為 490 個，因為服務 A 的更新。
5. 服務 A 的庫存在複製時被更新為 495 個，因為服務 B 的更新。
6. 最終，服務 A 和服務 B 的庫存都是不正確的，並且不同步（實際上應該是 485 個）。

這種情況可能受到多個因素影響，例如快取更新頻率、快取大小和複製延遲時間。通過估算碰撞率，可以評估是否適合使用複製快取

雲端 vs. 預置實作

空間式架構在部署環境方面提供了一些獨特的選擇，可以在雲端或本地部署，也可混合部署，允許雲端處理和本地資料管理的獨特組合，有效同步資料，實現最終一致性。

• 空間基礎架構在部署環境上有多種選擇，包括雲端和本地部署。
• 這種架構風格可以將應用程序部署在雲端，同時保留實際資料庫在本地，從而形成混合部署。
• 拓撲支援雲端資料同步，並保持最終一致性模型。
• 交易處理可以在雲端進行，同時保留本地的資料管理和分析。

範例：

想像一家電子商務公司，他們使用空間基礎架構來管理商品庫存、訂單處理和付款。這個架構可以在雲端和本地部署，以實現最佳的效能和彈性。以下是一個簡單案例：

1. 部署場景： 這家電子商務公司將其網站和應用部署在雲端，包括處理訂單、購物車和付款的處理單元。同時，他們的商品庫存和客戶資料則保存在本地的資料庫中。

2. 空間基礎架構應用： 在空間基礎架構下，每個處理單元負責不同的功能，比如訂單處理、購物車管理和付款驗證。這些處理單元可以在雲端動態啟動和關閉，以應對不同的訪問量。

3. 庫存管理： 商品庫存信息被保存在本地的資料庫中，但在處理單元中也有一個同步的快取。當有人下訂單時，訂單處理單元會從快取中檢查商品數量，確保庫存充足。

4. 訂單處理： 訂單處理單元接收到訂單後，將訂單詳細信息保存在其內部的快取中，同時使用資料泵將訂單信息發送到本地資料庫中。

5. 付款驗證： 付款處理單元接收到付款請求，通過處理卡支付等操作，將付款結果寫入快取和本地資料庫中。

6. 最終一致性： 即使存在雲端和本地部署的組合，空間基礎架構通過異步的資料泵確保了資料的最終一致性。訂單和付款等資料在處理單元和本地資料庫之間同步，保證資料的一致性。

7. 優勢： 這種結合雲端和本地的架構，讓公司能夠充分利用雲端的靈活性和彈性，同時保留本地資料的控制和安全性。

這個案例展示了如何利用空間基礎架構在混合部署中有效管理電子商務操作，實現最終一致性和靈活性。

複製 vs. 分散式快取

在空間基礎架構中，複製式和分散式快取是關鍵元素。根據資料需求，選擇適當的快取模型，平衡一致性、性能和容錯性。兩者均有其優勢，並應根據應用情境靈活選用。

決策準則	複製快取	分散式快取
最佳化	效能	一致性
快取大小	小( < 100 MB )	大 ( > 500 MB )
資料型態	相對靜態	高度動態
更新頻率	相對低	高更新頻率
容錯	高	低

複製式快取（Replicated Caching）：

複製式快取是空間基礎架構中一種最主要的快取模型，其中每個處理單元都具有一個自己的內存資料網格，該網格在相同命名的快取中的所有處理單元之間同步資料。當在一個處理單元中的快取進行更新時，其他處理單元將自動更新為新的信息。複製式快取通常用於要求高性能和高容錯性的應用場景，並且能夠支持快速的資料查詢和變更。

• 每個處理單元擁有自己的內存資料網格。
• 快取在所有處理單元之間同步。
• 高速且具有高容錯性。
• 沒有單一故障點。

範例：

假設有一個線上遊戲，其中有多個遊戲伺服器，每個伺服器負責不同的地區或區域。這些伺服器需要快速地查詢玩家的帳戶資訊和遊戲進度。透過複製式快取，每個伺服器都擁有一個自己的內存資料網格，存儲所有玩家的帳戶資訊和遊戲進度。當一個玩家在其中一個伺服器上進行遊戲，另一個伺服器也可以立即查詢到相同的玩家資料，因為資料已經在每個伺服器上複製。這樣，玩家可以在不同伺服器間切換而無需重新加載資料，提供了流暢的遊戲體驗。

分散式快取（Distributed Caching）：

分散式快取是另一種快取模型，其中資料被集中存儲在一個外部伺服器或服務中，而處理單元則通過專有協議從中央快取伺服器中讀取資料。分散式快取通常用於需要強大的資料一致性的應用場景，但由於需要遠程訪問資料，可能會導致性能較低。

• 資料集中存儲在外部伺服器或服務中。
• 處理單元從中央快取伺服器中讀取資料。
• 資料一致性較高，但性能可能較低。
• 容錯性較差，若伺服器故障，處理單元可能無法訪問資料。

範例：

考慮一個電子商務網站，該網站在全球多個地區運營，並且每個地區有不同的產品庫存資料。這些地區之間的資料需要保持高度一致性，以確保在任何地區查詢產品庫存時都能獲得正確的資料。這時可以使用分散式快取，將所有地區的庫存資料集中存儲在一個中央的快取伺服器中。每次需要查詢庫存資料時，各地區的伺服器可以通過專有協議從中央快取伺服器中獲取資料，確保所有地區都使用相同的資料。這樣，即使在高負載情況下，不同地區的庫存資料也能保持一致，提供可靠的購物體驗。

總結：

選擇何種模型取決於資料的一致性需求、性能和容錯性。 例如，對於維護當前庫存的處理單元，可以選擇分散式快取以實現資料一致性；而對於維護客戶檔案的處理單元，可以選擇複製式快取以實現性能和容錯性。

複製式快取和分散式快取是兩種不同的快取模型，適用於不同的應用場景。複製式快取通常用於要求高性能和高容錯性的場景，並可以快速地將資料複製到多個處理單元中。而分散式快取則通常用於需要高一致性的場景，並將資料集中存儲在中央伺服器中，以確保各地區使用相同的資料。在實際應用中，根據不同的需求和情境，選擇適合的快取模型能夠最大程度地優化系統性能和資料一致性。

考慮使用近端快取

近端快取是一種混合型快取模型，結合了內存資料網格和分散式快取的優點。然而，由於前端快取在不同處理單元之間存在不一致性，可能會導致性能和響應時間的問題，因此在空間型架構中不推薦使用近端快取模型。在選擇快取模型時，應根據系統需求和性能考慮，選擇最適合的快取策略。

• 近端快取是一種融合了內存資料網格和分散式快取的混合型快取模型。

• 結構：

  • 部分前端快取： 存儲部分的全備份快取的資料子集，使用淘汰策略（如 MRU、MFU、RR）管理資料。
    • MRU: 最近使用
    • MFU: 最頻繁使用
    • RR: 隨機替換
    • LRU: 最近最少使用算法
  • 全備份快取： 包含完整資料，保障資料完整性和持久性。

• 操作流程：

  1. 用戶訪問資料時，首先檢查前端快取是否存在所需資料。
  2. 如果前端快取有資料，則返回該資料。
  3. 如果前端快取缺少資料，則從全備份快取中獲取，同時將該資料添加到前端快取中。

• 一致性問題： 不同處理單元之間的前端快取可能存在不一致性，因為它們存儲的資料有可能不同。

• 選擇考量： 選擇使用近端快取需要考慮資料一致性和性能之間的平衡。

• 用途： 近端快取適用於需要提升查詢性能並減輕資料庫壓力的場景？？？？？？。

• 範例應用： 在電子商務網站中，使用近端快取來存儲經常訪問的產品信息，以提升用戶的查詢速度，同時減少對資料庫的訪問頻率？？？？？。

範例：

假設我們有一個電子商務網站，其中有許多用戶經常訪問並查詢產品信息。在這個情境下，我們考慮使用近端快取來提升用戶的查詢性能。

場景描述：

我們的網站有許多不同的產品頁面，每個產品頁面都包含詳細的產品信息，例如產品名稱、價格、庫存量等。

由於大量的用戶訪問，每當用戶訪問某個產品頁面，系統都需要從資料庫中讀取該產品的信息，這可能會導致資料庫讀取壓力過大，影響性能。

解決方案：

我們可以採用近端快取來解決上述性能問題。具體步驟如下：

1. 在每個處理單元（服務器）上設置一個前端快取，其中存儲最常被訪問的產品信息，例如最受歡迎的產品、最新的產品等。

2. 同時，我們在分散式快取中設置一個完整的後端快取，其中包含所有產品的信息。

3. 當用戶訪問某個產品頁面時，首先檢查前端快取是否包含所需的產品信息。如果有，則直接從前端快取中返回該信息，避免了對資料庫的讀取。

4. 如果前端快取中不存在所需信息，則從後端分散式快取中獲取該信息，同時將該信息添加到前端快取中，以供後續訪問使用。

通過使用近端快取，我們可以在處理單元的內存中保留最常訪問的產品信息，從而大大提升了用戶的查詢性能，同時減少了對資料庫的壓力。儘管前端快取可能在不同處理單元之間存在一些不一致性，但對於提升性能而言，這是一個值得考慮的折衷方案。

實作範例

空間式架構非常適用於那些可能會突然出現高用戶或請求量的應用，以及擁有超過 10,000 個同時使用者的高吞吐量應用。空間型架構的範例包括線上音樂會售票系統和線上拍賣系統等。這兩個範例都需要高性能、高擴展性和高度的彈性。

音樂會票務系統

特點：

• 用戶數量相對較低，直到宣布熱門音樂會。
• 售票開始後，用戶數量急劇上升，可能達數千至數萬人，追求音樂會門票。
• 門票迅速銷售，需要高性能、高擴展性和高彈性的架構

挑戰:

• 門票有限，但需即時更新座位數量和可用性。
• 需要處理大量同時請求，同步訪問中央數據庫可能難以應對。

適用空間型架構：

• 彈性要求高，能隨即增加處理單元以應對大量請求。
• 部署管理器可提前準備處理單元，應對用戶量增加。

線上拍賣系統

特點：

• 在拍賣開始時無法預測參與人數和競標次數。
• 需要高性能、高擴展性，並具備處理用戶和請求量高峰的能力。

挑戰：

• 不確定競標人數和競標次數。
• 競標數據需要即時傳輸，並確保競標一致性。

適用空間型架構：

• 可隨著負載增加啟動多個處理單元，提高性能和彈性。

• 各個處理單元專注於不同的拍賣，確保數據一致性。

• 資料幫補的非同步特性，出價資料可以被傳送到其他處理單元（如競標歷史、競標分析和審計等），利用少少的延遲，提高競標過程的整體性能。

音樂會售票系統和線上拍賣系統是兩個適用空間式架構的實例，因為它們都需要應對高峰用戶或請求量、具備高性能、高擴展性和彈性的特點。透過空間式架構，這些系統能夠在需求增加時快速擴展，並確保資料的即時傳輸和一致性。

架構特性的等級

空間型架構極大化了彈性、擴展性和性能（全部五星評分）。

• 分割型態：

  • 空間型架構難以明確辨識其分割型態，因此被認定為領域分割型態以及技術分割型態。

• 量子數目：

  • 空間型架構中的量子數目取決於用戶界面的設計和處理單元之間的通信方式。
  • 處理單元不與數據庫同步通信，因此數據庫本身不參與量子方程。
  • 量子通常是由各種用戶界面和處理單元之間的關聯來劃分。

• 可部署性：

  • 空間型架構能夠在需要時立即增加處理單元的數量，以應對不同的用戶負載。
  • 部署管理器可以根據用戶負載的增加而啟動更多的處理單元。

• 彈性：

  • 空間型架構最大化了彈性，能夠迅速調整處理單元的數量以適應不同的用戶需求。
  • 部署管理器能夠在需要時快速啟動處理單元，以處理大量的並發請求。

• 演進式：

  • 空間型架構具有高度的彈性和可擴展性，使其能夠在需求變化時進行調整。
  • 能夠根據用戶負載的變化動態調整處理單元的數量。

• 容錯：

  • 沒有明確提到容錯特性的評分。

• 模組化：

  • 空間型架構通過處理單元的靈活性實現模組化，處理單元能夠像領域服務一樣運作。
  • 處理單元能夠以模組化方式處理特定的功能或服務。

• 整體花費：

  • 空間型架構相對較昂貴，主要是由於緩存產品的許可費以及高資源利用率。

• 效能：

  • 空間型架構能夠最大化性能，通過內存數據緩存實現高性能。

• 可靠性：

  • 沒有明確提到可靠性特性的評分。

• 可擴展性：

  • 空間型架構最大化了可擴展性，能夠處理數百萬的並發用戶。

• 簡單性：

  • 空間型架構相對複雜，需要小心處理緩存和數據一致性的問題（當有一個部件當機時，避免資料遺失）。

• 可測試性：

  • 測試得到一星評分，因為模擬高擴展性和彈性的測試非常複雜和昂貴。
  • 大多數高負載測試在實際生產環境中進行，對正常運營產生風險。