没有像paxos这样的共识算法，HBase如何强一致答案

【问题标题】：How can HBase strongly consistent without consensus algorithm like paxos没有像paxos这样的共识算法，HBase如何强一致
【发布时间】：2020-08-26 04:08:44
【问题描述】：

很多文章提到 HBase 是一个强一致性系统，因为读/写只去主区域服务器。

但我在想一个无法保持一致性的场景

(1) 写入未能复制到某些 HDFS 副本（afaik，HBase 复制依赖于 HDFS）但在其他一些副本上成功，并且主节点向客户端响应失败。

(2) 然后主节点失败，选出了一个新的领导者，这恰好在步骤 (1) 中写入成功。

客户端会得到未提交的数据，破坏了强一致性保证。

【问题讨论】：

标签： hbase consistency eventual-consistency

【解决方案1】：

你说得对，HBase 不是真正的“强一致性”。他们声称这是“强一致性”，因为在主/从复制中，客户端只能从主服务器读取/写入，这保证了最新的写入。所以 HBase 的人把它归类为强。其实这种类型的一致性还是弱一致性（失败的例子之一就是你描述的场景）

来自 Google 的 Ryan Barret 有 a talk back in 2009 解释差异，M/S 是最终一致性模型，请在此处引用图表和更多细节in this book chapter

【讨论】：

【解决方案2】：

您对 HBase 写入一致性保证有误。首先，您提出的方案是耐用性 问题，而不是一致性问题。即使在所谓的未提交写入变得可见之后，它也会同时对所有客户端可见；因此，这里没有一致性问题。

换句话说；写确认只是尽力而为，真正的一致性保证是写后读一致性。在 HBase 成功写入 WAL 后，任何尝试读取的客户端都会看到相同的数据状态。

为了解决持久性问题，让我提出一个与您建议的不同的方案。让我们对任何数据库（不仅仅是 HBase）采取以下步骤顺序：

客户端发送一个写操作。
服务器收到操作，成功应用它并向客户端发送确认。
发生网络故障，确认永远不会到达客户端。
由于网络故障，客户端认为请求超时。它还认为服务器连接不健康。因此它会尝试创建一个新连接。
网络已恢复，但来自服务器的确认丢失了，因为客户端现在使用不同的套接字进行连接。

这种情况发生的原因是由于大多数分布式系统的性质，即在客户端-服务器场景中，服务器总是被认为是事实的来源。 Supposedly failed 可能会出现写入，因为由于服务器无法控制的原因，这些写入可能对客户端显示为失败。

大多数数据库只保证向客户端成功确认的写入的持久性（即一旦确认，这些写入不会丢失，除非发生灾难场景），而不是可能失败的写入的非持久性从客户的角度来看。

确保任何未成功向客户端确认的写入不会写入数据库的唯一方法是等待客户端确认来自服务器的写入确认。对于服务器来说，这是一种致命的依赖，它可能会由于一个行为不端、缓慢或死机的客户端而阻止来自所有客户端的写入。

【讨论】：

根据 hbase 官方文档，“强一致性”是指“强一致性是 HBase 中默认的一致性模型，其中读取和写入通过单个服务器对更新进行序列化，并返回所有写入的数据并确认。”。所以可序列化是“强有力的保证”的一部分。你所说的“不是一致性问题”，我的理解是它的线性化保证而不是序列化。
同样，您提出的场景与可序列化读取无关，我建议您为此创建一个不同的 SO 线程。在此之前，您应该阅读有关 HBase 中 ACID 语义的官方文档（hbase.apache.org/acid-semantics.html 和 hadoop-hbase.blogspot.com/2012/03/acid-in-hbase.html），并了解 mvcc 如何在此过程中提供帮助。