HBase時間軸一致性（Timeline Consistency）

時間軸一致性（Timeline Consistency）

HBase引入了一致性定義，可以根據(jù)讀取操作（獲取或掃描）提供一致性定義。

public enum Consistency {
    STRONG,
    TIMELINE
}

Consistency.STRONG是HBase提供的默認一致性模型。如果表的區(qū)域復制為1，或者在具有區(qū)域副本的表中，但是讀取是以此一致性完成的，則讀取總是由主區(qū)域執(zhí)行，以便與先前的行為不會發(fā)生任何變化，并且客戶端總是觀察最新的數(shù)據(jù)。

如果執(zhí)行讀取操作Consistency.TIMELINE，則讀取的RPC將首先發(fā)送到主要區(qū)域服務(wù)器。在很短的時間間隔（hbase.client.primaryCallTimeout.get默認為10ms）之后，如果主服務(wù)器沒有響應(yīng)，則也會發(fā)送用于輔助區(qū)域副本的并行RPC。在此之后，結(jié)果將從首先完成的RPC中返回。如果響應(yīng)從主區(qū)域副本返回，則我們始終可以知道數(shù)據(jù)是最新的。為此，Result.isStale（）API已被添加到檢查失效。如果結(jié)果來自輔助區(qū)域，則Result.isStale（）將被設(shè)置為true。然后用戶可以檢查該字段，以便了解有關(guān)數(shù)據(jù)的可能原因。

就語義而言，HBase實現(xiàn)的TIMELINE一致性與這些方面的純粹最終一致性不同：

• 單宿主和有序更新：區(qū)域復制與否，在寫入端，仍然只有1個定義的副本（主）可以接受寫入。此副本負責命令編輯并防止沖突。這保證了兩個不同的寫入不會被不同的副本同時提交，并且數(shù)據(jù)發(fā)散。有了這個，就不需要進行read-repair或last-timestamp-wins兩種中的沖突解決。
• 輔助還按照主要承諾的順序應(yīng)用編輯。通過這種方式，輔助數(shù)據(jù)將在任何時間點包含初選數(shù)據(jù)的快照。這與RDBMS復制相似，甚至與HBase自己的多數(shù)據(jù)中心復制類似，但在單個集群中也是如此。
• 在讀取端，客戶端可以檢測讀取是來自最新數(shù)據(jù)還是舊數(shù)據(jù)。另外，客戶端可以在每個操作的基礎(chǔ)上發(fā)布具有不同一致性要求的讀取，以確保其自身的語義保證。
• 客戶端仍然可以觀察到無序編輯，并且如果它觀察到首先從一個輔助副本讀取，然后觀察到另一個輔助副本的讀取，則可以及時返回。對區(qū)域副本或基于交易ID的擔保沒有粘性。如果需要，這可以稍后實施。

為了更好地理解TIMELINE語義，讓我們看看上面的圖。假設(shè)有兩個客戶端，第一個客戶端首先寫入x=1，然后x=2和x=3。如上所述，所有寫入都由主區(qū)域副本處理。寫入保存在預寫日志（WAL）中，并異步復制到其他副本。在上圖中，請注意replica_id=1收到2次更新，其數(shù)據(jù)顯示x=2，而replica_id=2只收到一次更新，其數(shù)據(jù)顯示x=1。

如果client1以STRONG一致性讀取，它只會與replica_id=0進行通信，因此保證觀察x=3的最新值。如果客戶端發(fā)出TIMELINE一致性讀取，則RPC將轉(zhuǎn)到所有副本（在主超時之后），并且第一個響應(yīng)的結(jié)果將返回。因此，客戶端可以將1，2或3看作x的值。假設(shè)主區(qū)域發(fā)生故障并且日志復制無法持續(xù)一段時間。如果客戶端使用TIMELINE一致性進行多次讀取，則它可以先觀察x=2，然后觀察x=1，依此類推。