AerospikeC客戶端手冊———事務級一致性保證



事務級一致性保證

作為分布式數據庫，Aerospike支持自動的數據復制。最常見的，數據庫被配置成每條記錄維護兩個完全相同的拷貝。即所說的“復制因子為2。 服務器也支持其它復制因子，以namespace為基礎進行配置。
（關於數據復制的更多細節，請參見Aerospike架構主題【數據分布】）
自動數據復制提供了高性能和容錯的系統優勢，但增加了事務延遲的（潛在的）耗用。讀取事務的延遲耗用一般發生在集群重配置階段，這時副本可能還未被同步到最新拷貝。寫事務延遲受復制因子影響，因為提交修改到主副本服務器以外節點上的備副本增加了集群內部通訊。
每次事務都操作所有副本能夠保證完全的數據一致性。但是，經常可取的是，選擇運行在降低的一致性保證水平下，意味著事務處理不一定訪問一個記錄所有的副本。
Aerospike服務器/客戶端結合的默認行為是提供一致性保證的最常見選擇：

讀事務默認只查閱單一副本，即使在集群重配置期間。

寫事務（包括刪除與UDF應用）默認同步提交所有副本後再返回事務成功。

單一副本讀和同步所有副本寫，這個選項組合工作得很好，提供給Aerospike低延遲的即時一致性。

然而，應用開發人員在自己的應用中，有時想要改變一下系統默認的副本相關行為。

注意：即使使用低於最高水平的一致性保證，數據讀寫仍然很有可能被視為是一致的。為了速度，使用較低的一致性保證水平，只是打開了一個短暫時間窗口，在這個窗口內，一個事務涉及到的數據從整個集群范圍看，可能暫時是不完全一致的。這種取捨權衡是否可接受，完全取決於應用設計者。

在讀取場景下，使用較低的一致性保證，後面的讀可能返回記錄以前的值。（這是可能發生的，例如，由於集群正在進行重配置並且主副本還不是最新拷貝。）

在寫入場景下，使用較低的一致性保證，在主副本已經提交、備副本還未提交期間，可能會讀到記錄以前的值（“髒讀”）。

為了應用的最大靈活性，Aerospike提供可選擇的事務級一致性保證。使用副本相關的策略，允許應用在所需的性能與一致性保證間取捨。

副本與一致性保證相關策略

Aerospike C客戶端提供三種副本與一致性保證相關的策略選擇：1）讀副本選擇 （read replica）；2） 讀一致性水平（read consistency level）；3）寫提交水平（write commit level）。

應用開發人員可指定期望的副本選擇和一致性保證水平策略，通過在客戶端配置中設定連接級全局策略，或在單獨的C客戶端API函數調用時指定事務級策略。應用未更改的策略將使用默認值。在內部，C客戶端使用這些策略設置，來發送恰當的線路協議命令給服務器。

讀副本選擇策略

讀副本選擇策略，由read.replica設定，應用於讀操作，指定客戶端讀取數據時訪問哪一個副本。

默認讀取主副本（master)。

另一個選擇是讀取副本之一(any)。（實際上是隨機選擇一個來讀）

讀一致性水平策略

讀一致性水平策略，由read.consistency_level設定，應用於讀相關操作。指定服務器內部查閱多少個副本來確定最近的記錄值，並將它返回客戶端。

默認值是讀一個(one)。

另一個選擇是讀所有(all)。

寫提交水平策略

寫提交保證，由write.commit_level設定，應用於任何寫相關操作。指定服務器在返回客戶端成功之前必須成功提交修改到多少個副本。

默認值是在返回前提交到所有（all)，副本。

另一個選擇是在只提交主副本(master)就返回，異步復制到各備副本。

服務器一致性保證水平覆蓋原則

客戶端選擇的事務級一致性保證，覆蓋服務器端namespace級可動態配置的相關參數。（注意：讀副本選擇策略僅限於客戶端，因此沒有服務器端覆蓋的說法）

請參見【配置參考手冊】中服務器主題中有關一致性覆蓋參數部分，以了解詳細內容。

事務級一致性保證策略使用代碼示例

為使用任何副本選擇或一致性保證相關策略，首先需創建並初始化一個客戶端連接：

as_config config;
as_config_init(&config);

// [(A): Non-default policies may be set on 'config.policies' here.]

aerospike client;
aerospike_init(&client, &config);

as_policies *p_policies = &client.config.policies;

// [(B): Non-default policies may be set via 'p_policies' here.]

配置對象config裡的policies將被初始化成默認策略值，並用來初始化客戶端對象client。

可在【A】點通過config.policies來設置非默認策略，在初始化客戶端對象之前。

在客戶端對象初始化之後（例如：【B】點），仍然可改變客戶端連接的策略設置，通過取出polices的指針（p_policies）並使用指針獲取和設置個別策略。

設置客戶端連接級策略

下面三小節展示應用如何選擇客戶端連接級的非默認策略行為。

選擇讀取任意副本

默認情況下，所有客戶端讀取將被引導到主副本（策略值：AS_POLICY_REPLICA_MASTER）。然而在某些場景，可能需要把讀分散到所有可用副本上。（例如：降低讀取熱鍵的性能影響，可以被降低約復制因子倍）。在此場景中，應用可選擇讀取任意一個副本（“隨機”），通過設置read.replica策略為AS_POLICY_REPLICA_ANY：

p_policies->read.replica = AS_POLICY_REPLICA_ANY;

選擇較高讀一致性保證

默認的客戶端記錄讀取行為（包括讀取和操作API函數）是只讀取一個副本（策略值：AS_POLICY_CONSISTENCY_LEVEL_ONE，由read.replica指定）。然而在集群重配置期間，只讀取一個副本會返回非最新版本的值。在要求最高讀取一致性水平的場景中，設置策略read.consistency_level為AS_POLICY_CONSISTENCY_LEVEL_ALL：

p_policies->read.consistency_level = AS_POLICY_CONSISTENCY_LEVEL_ALL;

注意：讀取所有副本的潛在性能影響只有在集群重配置期間才會顯著。

選擇較低寫一致性保證

默認的客戶端記錄修改行為（如：寫、移除、操作和應用UDF的API函數）是在成功提交修改到所有副本後才返回AEROSPIKE_OK。此默認策略（AS_POLICY_COMMIT_LEVEL_ALL）保證最高水平寫一致性。

若需要較低的寫延遲，而且應用能容忍較低的寫一致性保證（有“髒讀”的可能，如：從一個未被提交的非主副本中讀取記錄的值，可能會讀回一個舊值），設置write.comit_level策略為AS_POLICY_COMMIT_LEVEL_MASTER：

p_policies->write.commit_level = AS_POLICY_COMMIT_LEVEL_MASTER;

使用事務級一致性保證

上面的示例代碼定義了客戶連接級別使用的全局策略。為設置事務級策略，可把所需策略的設置當參數傳遞給單個API調用。例如：用主副本提交（master）保證水平來執行寫入記錄，按如下步驟做：

as_policy_write my_write_policy;
as_policy_write_init(&my_write_policy);

my_write_policy.commit_level = AS_POLICY_COMMIT_LEVEL_MASTER;

// [...Define other variables, etc...]

as_status status = aerospike_key_put(&as, &err, &my_write_policy, &key, &rec);

在單個API調用上指定的策略，若是非空（NULL），則會覆蓋客戶端連接級別上的相應策略設置。（注意：若設置了相應的服務器設置，則會覆蓋客戶端策略設置）。