如何解决如果没有像paxos这样的共识算法，HBase如何能够高度一致
许多文章都提到HBase是一个高度一致的系统，因为读/写操作只对主区域服务器进行。
但是我正在考虑一种无法保持一致性的情况
（1）写入操作无法复制到某些HDFS副本（afaik，HBase复制依赖于HDFS），但在其他一些副本上却成功，并且主服务器对客户端做出响应。
（2），那么主失败和新的领导者得到了当选，刚巧在步骤（1）的成功写操作。
客户端将获得未提交的数据，这会破坏强一致性保证。
解决方法
您说得对，HBase 不是真正的“强一致性”。他们声称这是“强一致性”，因为主/从复制，其中客户端只能从主服务器读/写，这保证了最新的写入。所以 HBase 的人将其归类为强大的。其实这种类型的一致性还是弱一致性（失败的例子之一就是你描述的场景）
来自 Google 的 Ryan Barret 有 a talk back in 2009 来解释差异，M/S 是最终一致性模型，请在此处引用图表
及更多详情 in this book chapter
您对HBase的写一致性保证有误。首先，您构成的场景是耐久性问题，而不是一致性问题。即使所谓的 uncommitted 写入变为可见，它也将同时对所有客户端可见；因此，这里没有一致性问题。
换句话说；写入确认只是尽力而为，真正的一致性保证是写入后读取一致性。 HBase将写入成功写入WAL之后，任何尝试读取的客户端都将看到相同的数据状态。
为解决耐久性问题，让我提出与您建议的方案不同的方案。让我们对任何数据库（不仅仅是HBase）采取以下步骤顺序：
- 客户端发送写操作。
- 服务器接收到op，成功地将其应用并向客户端发送确认。
- 发生网络故障，并且确认永远不会到达客户端。
- 由于网络故障，客户端认为请求超时。它还认为服务器连接不健康。因此，它尝试创建一个新的连接。
- 网络已恢复，但是由于客户端现在使用其他套接字连接，因此服务器的确认丢失。
发生这种情况的原因是由于大多数分布式系统的性质所致，即在客户端-服务器情况下，始终将服务器视为真相的来源。可能会出现据说失败的写操作，因为由于服务器无法控制的原因，这些写操作可能对客户端可见为失败。
大多数数据库仅保证成功向客户端确认的写入的持久性（即，一旦被确认，除非发生灾难情况，否则这些写入不会丢失），而不是可能失败的写入的非持久性从客户的角度来看。
确保所有未成功确认给客户端的写入都不会写入数据库的唯一方法是等待客户端确认来自服务器的写入确认。对于服务器而言，这是一个致命的依赖关系，因为一个客户端的行为异常，缓慢或死机，服务器可能会阻止来自所有客户端的写入。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。