From e9dcced03ca66bae4428b06c5105724faf9bc308 Mon Sep 17 00:00:00 2001 From: <> Date: Tue, 27 Aug 2024 02:18:33 +0000 Subject: [PATCH] Deployed 34dece2b with MkDocs version: 1.6.0 --- .../distributed-ft/index.html | 249 +++++++++++++----- feedback/index.html | 14 +- search/search_index.json | 2 +- 3 files changed, 185 insertions(+), 80 deletions(-) diff --git a/feedback/designing-data-intensive-applications/distributed-ft/index.html b/feedback/designing-data-intensive-applications/distributed-ft/index.html index 492c601f..3c1fdfa7 100644 --- a/feedback/designing-data-intensive-applications/distributed-ft/index.html +++ b/feedback/designing-data-intensive-applications/distributed-ft/index.html @@ -1205,9 +1205,13 @@

分散式資料庫的容錯HackMD 報告

簡介

-

我們從處理競賽狀況時就提起:分散式資料庫沒辦法有效容錯。這次,我們終於要來談談分散式資料庫要怎麼容錯了!我們先來談談單台機器的容錯機制,再來帶出分散式系統的容錯機制。

+

我們從處理競賽狀況時就提起:分散式資料庫沒辦法有效容錯。 +這次,我們終於要來談談分散式資料庫要怎麼容錯了!我們先來談談單台機器的容錯機制,再來帶出分散式系統的容錯機制。

資料庫透過抽象的「交易」來滿足容錯
資料庫透過抽象的「交易」來滿足容錯

-

對應用程式開發人員來說,他可以很簡單的在異動前告知資料庫我要使用「交易」的機制,以此來滿足資料的一致性和容錯性。但是我們前面提了「複製延遲」很輕易就可以破壞這一系列的保證。同時,我們也要問問自己,如何讓開發人員使用和「交易」相似的方式來讓開發人員不需要在寫程式的時候還要思考分散式叢集會有的邊際狀況?

+

對應用程式開發人員來說,他可以很簡單的在異動前告知資料庫我要使用「交易」的機制, +以此來滿足資料的一致性和容錯性。但是我們前面提了「複製延遲」很輕易就可以破壞這一系列的保證。 +同時,我們也要問問自己, +如何讓開發人員使用和「交易」相似的方式來讓開發人員不需要在寫程式的時候還要思考分散式叢集會有的邊際狀況?

分散式資料庫的抽象邏輯是什麼?
分散式資料庫的抽象邏輯是什麼?

那分散式資料庫又該做什麼?在開始前,我們先前情提要一下。

環境

@@ -1226,16 +1230,24 @@

環境

執行緒延宕

-

即使單台機器也會受到執行序的延宕,但是單台機器的延宕代表所有程序都會被延宕,所以他並不會認知到自己被延宕了(除非檢查時間)。

-

但是到了分散式系統時,執行序的延宕就代表有一節點突然無法運作,這時其他節點仍能正常運作。隔了三十秒之後,該節點恢復正常了,這時就可能造成不同節點的錯誤認知,例如複權(split brain)。

+

即使單台機器也會受到執行序的延宕,但是單台機器的延宕代表所有程序都會被延宕, +所以他並不會認知到自己被延宕了(除非檢查時間)。

+

但是到了分散式系統時,執行序的延宕就代表有一節點突然無法運作,這時其他節點仍能正常運作。 +隔了三十秒之後,該節點恢復正常了,這時就可能造成不同節點的錯誤認知,例如複權(split brain)。

暫時的錯誤狀態會成為永久

-

我們有提到很多 NoSQL 宣稱最終一致性是必然的,然而最終一致性雖然可以讓狀態達到最終的一致性,但是當你從(暫時的)錯誤狀態作出任何判斷並執行異動時,相對應的錯誤異動就成為「正確的」異動,並永久的影響資料庫的狀態。

-

例如帳號註冊時,檢查帳號是否註冊過:因為應用程式從資料庫得到的資訊是帳號沒被註冊過,所以允許註冊,這時就會讓這種暫時的錯誤狀態成為永久的錯誤狀態。

-

因爲這異於一般的開發環境(通常我們存取程式碼中的變數時,都期望得到的值是最新的狀態),所以這會增加應用程式開發的負擔,每此設計時都要仔細設想各種狀況。而且這種東西很難得到保證:我這樣做就一定沒錯。

+

我們有提到很多 NoSQL 宣稱最終一致性是必然的,然而最終一致性雖然可以讓狀態達到最終的一致性, +但是當你從(暫時的)錯誤狀態作出任何判斷並執行異動時,相對應的錯誤異動就成為「正確的」異動, +並永久的影響資料庫的狀態。

+

例如帳號註冊時,檢查帳號是否註冊過:因為應用程式從資料庫得到的資訊是帳號沒被註冊過,所以允許註冊, +這時就會讓這種暫時的錯誤狀態成為永久的錯誤狀態。

+

因爲這異於一般的開發環境(通常我們存取程式碼中的變數時,都期望得到的值是最新的狀態), +所以這會增加應用程式開發的負擔,每此設計時都要仔細設想各種狀況。而且這種東西很難得到保證:我這樣做就一定沒錯。

一致性和效能的權衡

-

當我們讓分散式資料庫擁有高一致性,就會犧牲高可用性和高效能,所以在開始講分散式的容錯系統前,需要先有個認知: 我不一定需要這些東西

-

在衍生資料的系列中(本系列叫做分散式系統),我們會提一個資料庫叢集的架構,這個架構就是試著鬆弛這個權衡:同時擁有高一致性和高可用性。

+

當我們讓分散式資料庫擁有高一致性,就會犧牲高可用性和高效能,所以在開始講分散式的容錯系統前, +需要先有個認知: 我不一定需要高一致性

+

在衍生資料的系列中(本系列叫做分散式系統),我們會提一個資料庫叢集的架構, +這個架構就是試著鬆弛這個權衡:同時擁有高一致性和高可用性。

什麼是一致性?

最後,我們重新確認一下名詞的定義。