没有paxos这样的共识算法，HBase如何实现强一致性
How can HBase strongly consistent without consensus algorithm like paxos
很多文章都提到HBase是一个强一致性系统，因为read/write只去主区域服务器。
但是我在想一个一致性不行的场景
(1) 无法将写入复制到某些 HDFS 副本（afaik，HBase 复制依赖于 HDFS），但在其他一些副本上成功，主服务器向客户端响应失败。
(2) 然后 primary 失败，新的 leader 被选举出来，这恰好在步骤 (1) 中成功写入。
客户端会得到未提交的数据，破坏了强一致性保证。
您对 HBase 写入一致性保证的理解有误。首先，您提出的场景是 耐久性 问题，而不是一致性问题。即使在所谓的 未提交 写入变得可见之后，它也会同时对所有客户端可见；因此，这里没有一致性问题。
换句话说；写确认只是Best effort，真正的一致性保证是read-after-write一致性。 HBase 成功写入 WAL 后，任何尝试读取的客户端都将看到相同的数据状态。
为了解决持久性问题，让我提出一个与您建议的场景不同的场景。让我们对任何数据库（不仅仅是 HBase）执行以下步骤序列：
- 客户端发送写操作。
- 服务器收到操作，成功应用并向客户端发送确认。
- 发生网络故障，确认从未到达客户端。
- 由于网络故障，客户端认为请求超时。它还认为服务器连接不健康。所以它会尝试创建一个新连接。
- 网络恢复，但服务器的确认丢失，因为客户端现在使用不同的套接字连接。
这种情况发生的原因是大多数分布式系统的性质，即在 client-server 情况下，服务器始终被认为是事实的来源。 假定失败 写入可能会出现，因为这些写入可能由于服务器无法控制的原因而被客户端视为失败。
大多数数据库只保证客户端成功确认的写入的持久性（即一旦确认，这些写入不会丢失，除非发生灾难场景），而不是non-durability 从客户端角度来看可能失败的写入。
确保未成功向客户端确认的任何写入不会写入数据库的唯一方法是等待客户端确认来自服务器的写入确认。对于服务器来说，这是一种致命的依赖性，它可能会由于一个行为不当、缓慢或死机的客户端而阻止所有客户端的写入。
你说得对，HBase并不是真正的“强一致性”。他们声称这是“强一致性”，因为 master/slave 复制，客户端只能从主服务器 read/write 复制，这保证了最新的写入。所以 HBase 的人把它归类为强。其实这种一致性还是弱一致性（其中一个失败的例子就是你描述的场景）
Google 的 Ryan Barret a talk back in 2009 解释了差异，M/S 是最终一致性模型，请在此处引用图表
and more details in this book chapter
很多文章都提到HBase是一个强一致性系统，因为read/write只去主区域服务器。
但是我在想一个一致性不行的场景
(1) 无法将写入复制到某些 HDFS 副本（afaik，HBase 复制依赖于 HDFS），但在其他一些副本上成功，主服务器向客户端响应失败。
(2) 然后 primary 失败，新的 leader 被选举出来，这恰好在步骤 (1) 中成功写入。
客户端会得到未提交的数据，破坏了强一致性保证。
您对 HBase 写入一致性保证的理解有误。首先，您提出的场景是 耐久性 问题，而不是一致性问题。即使在所谓的 未提交 写入变得可见之后，它也会同时对所有客户端可见；因此，这里没有一致性问题。
换句话说；写确认只是Best effort，真正的一致性保证是read-after-write一致性。 HBase 成功写入 WAL 后，任何尝试读取的客户端都将看到相同的数据状态。
为了解决持久性问题，让我提出一个与您建议的场景不同的场景。让我们对任何数据库（不仅仅是 HBase）执行以下步骤序列：
- 客户端发送写操作。
- 服务器收到操作，成功应用并向客户端发送确认。
- 发生网络故障，确认从未到达客户端。
- 由于网络故障，客户端认为请求超时。它还认为服务器连接不健康。所以它会尝试创建一个新连接。
- 网络恢复，但服务器的确认丢失，因为客户端现在使用不同的套接字连接。
这种情况发生的原因是大多数分布式系统的性质，即在 client-server 情况下，服务器始终被认为是事实的来源。 假定失败 写入可能会出现，因为这些写入可能由于服务器无法控制的原因而被客户端视为失败。
大多数数据库只保证客户端成功确认的写入的持久性（即一旦确认，这些写入不会丢失，除非发生灾难场景），而不是non-durability 从客户端角度来看可能失败的写入。
确保未成功向客户端确认的任何写入不会写入数据库的唯一方法是等待客户端确认来自服务器的写入确认。对于服务器来说，这是一种致命的依赖性，它可能会由于一个行为不当、缓慢或死机的客户端而阻止所有客户端的写入。
你说得对，HBase并不是真正的“强一致性”。他们声称这是“强一致性”，因为 master/slave 复制，客户端只能从主服务器 read/write 复制，这保证了最新的写入。所以 HBase 的人把它归类为强。其实这种一致性还是弱一致性（其中一个失败的例子就是你描述的场景）
Google 的 Ryan Barret a talk back in 2009 解释了差异，M/S 是最终一致性模型，请在此处引用图表