維護較小的集群可提供更強的一致性,以允許大型數據集群協調服務器活動,而無需實現基于 quorum 的算法。

問題

線性化是最強的一致性保證,可以保證所有客戶端都能看到最新提交的數據更新。提供線性化以及容錯功能需要在服務器上實現共識算法,例如 Raft,Zab 或Paxos。

盡管共識算法是實現 Consistent Core 的基本要求,但客戶端交互的各個方面(例如客戶端如何找到leader,重復請求的處理方式等)都是重要的實現決策。關于安全性和活躍性,還有一些重要的實現注意事項。Paxos 僅定義共識算法,但是 Paxos 文獻中沒有很好地記錄其他實現方面的內容。Raft非常清楚地記錄了各種實現方面以及參考實現,因此是當今使用最廣泛的算法。

當集群需要處理大量數據時,它需要越來越多的服務器。對于服務器集群,存在一些共同的要求,例如選擇特定的服務器作為特定任務的 master ,管理組成員信息,將數據分區映射到服務器等。這些要求需要強大的一致性保證,即線性化 。實現也必須是容錯的。一種常見的方法是使用基于 Quorum 的容錯共識算法。但是在基于 Quorum 的系統中,吞吐量會隨著集群的大小而降低。

解決方案

實現一個較小的3到5個節點的集群,該集群可提供線性化保證和容錯能力。單獨的數據集群可以使用小型一致性集群來管理元數據,并使用諸如 Lease 之類的機制來進行集群范圍的決策。這樣,數據集群可以擴展大量的服務器,但是仍然可以使用較小的元數據集群執行某些需要強一致性保證的操作。

Figure 1: Consistent Core
一個典型的consistent core接口是這樣的:

public interface ConsistentCore {
   CompletableFuture put(String key, String value);
   List

Consistent Core至少提供了一種簡單的鍵值存儲機制。它用于存儲元數據。

元數據存儲

使用諸如Raft之類的共識算法來實現存儲。它是“Replicated Write Ahead Log”實現的示例,其中復制由Leader and Followers處理,High-Water Mark用于跟蹤通過Quorum進行的成功復制。

支持分層存儲

Consistent Core通常用于存儲數據,例如:組成員身份或跨服務器的任務分配。一種常見的使用模式是使用前綴來限制元數據的類型。例如 對于組成員身份,keys 將全部存儲為/servers/ 1,server/2等。對于分配給服務器的任務,keys可以為/tasks/task1,/tasks/task2。通常使用特定前綴讀取所有鍵數據。例如,要獲取有關集群中所有服務器的信息,將讀取所有帶有前綴/servers 的 keys。

用法示例如下:
服務器可以通過使用前綴/servers 創建自己的 key 來向 Consistent Core 注冊自己。

client1．setValue("/servers/1", "{address:192．168．199．10, port:8000}");
client2．setValue("/servers/2", "{address:192．168．199．11, port:8000}");
client3．setValue("/servers/3", "{address:192．168．199．12, port:8000}");

然后,客戶端可以通過讀取key前綴 /servers 來了解集群中的所有服務器,如下所示:

assertEquals(client1．getValue("/servers"), Arrays．asList("{address:192．168．199．12, port:8000}",
                                                           "{address:192．168．199．11, port:8000}",
                                                           "{address:192．168．199．10, port:8000}"));

由于數據存儲的這種分層性質,[zookeeper],[chubby]之類的產品提供了類似于接口的文件系統,用戶可以在其中創建具有父節點和子節點概念的目錄、文件或節點。[etcd3]具有扁平化的鍵空間,可以獲取一系列鍵。

處理客戶端交互

Consistent Core功能的關鍵要求之一是客戶端如何與 Consistent Core 交互。以下方面對于客戶端使用 Consistent Core至關重要。