有许多文章解释了HBase的事务。我不能在这里重复一遍。每个人都应该知道它是通过MVCC实现的。但是今天本文的背景是由同事和我讨论一个问题引起的。这个问题使我重新解决了此内容，并与您分享作为记录。
让我们首先看一下这个问题：
HBase的查询过程是：第一个查询模拟，如果找不到它，请查询BlockCache，并在找不到它之前查询HFILE，然后将查询数据放入BlockCache中。
存在这样的情况吗？如果有数据ID = 1，name ='Zhang san'，当查询是查询时，则将数据放入blockCache中。后来，数据存储在Memstore中，它已达到写作机制并将其写入HFILE。用户查询此数据并发现BlockCache中有此数据，但是数据旧，名称='Zhang San'。所以我得到了旧数据
实际上，这是一个非常普遍的场景。那时，我的第一个反应绝对找不到肮脏的数据，但是它是如何实现的，我真的无法得到一段时间。作为我最熟悉的组件，仍然需要此问题。
实际上，如果仔细分析了上述问题，则可以分解为以下问题：
让我们从这些问题开始，回答上述问题。
这个问题不是当今这个问题的核心内容，但可以说是准备知识。
阅读了BlockCache的动作后，让我们看一下BlockCache保存到底是什么？
实际上，答案很简单，都称为blockcache，其中必须有块。在这里，我们必须区分两个概念。由于HBase的底层使用HDFS存储，并且HDFS也具有块的概念，因此应区分这两个块概念。
从大小比较来看，两者之间的差异可以看到。如果使用HDFS的块大小用于缓存，则无法捕获后缓存，并且BlockCache已满，这显然是不合适的。默认的HBase块的64K大小是两个基于HBase的查询操作扫描并获得的折扣效率。如果GET操作大多是块的大小，则可以适当调整块的大小；否则，如果扫描操作大部分是扫描操作，则可以对块的大小进行适当调整。如果两者的数量相似，则可以使用适当的默认值。
那么HBase中有哪些块？主要分为以下四个：
简而言之，当前的HBASE主流BlockCache用途是使用BucketCache和lroublockcache（称为CombinedBlockCache），即cbc.s cbc.t bucketCache和lroublockcache，您可以具体地检查一下。有很多在线。在这里，我将简要谈论两者的特征：
首先更正上述问题的读取数据过程。上述数据实际上是错误的。那么正确的过程是什么样的？实际上，HBase的查询操作分为两种类型的GET和扫描操作（尽管GET操作也被视为扫描以进行扫描），如下所示：
以上是避免阅读肮脏的手段。乍一看，信息量有点大。每个人都可能有些尴尬。读数是多少，写作号码，两者之间的关系是什么？这涉及HBase交易实现机制MVCC的一些细节。以下是详细的。
以上是关于HBASE如何避免肮脏阅读的。让我们看一下上述专有术语，以及HBASE如何保持查询和一致的数据。
首先，MVCC的基本知识不会在这里详细介绍。您可以在线检查。有很多信息。我主要谈论MVCC组件在HBASE中的工作方式，以及如何关联和更新读数和写作号。然后，您可以回答上述问题。首先查看以下图：
首先，MVCC有三个主要组成部分：
MVCC的每个区域都有一个示例。这三个属性通过规则链接。HBase从此处读取并编写区域数据，然后执行相关操作。
让我们看一下这三个属性的链接规则：
1.当客户端写入数据中时，首先，锁定与MVCC控制中心写入一样，将其插入新条目中，并给出以前的写入点+1 writenumber（WritePoint+1也同步），。表示新的transaction.com目前是错误的。手表名称当前尚未完成，数据仍在写作过程中。WriteClient1和图中的Client3在此阶段。
2.步骤2客户将数据写入Memstore和WAL。目前，数据被认为是耐用的，可以结束交易。在这里应该指出，这只是交易的终结，但没有成功地写给客户，而且还需要拥有以下MVCC相关操作。
3.客户端调用MVCC控制中心的完整（WriteEntry WriteEntry）方法。该方法使用同步关键字到WriteQueue将访问设置为对应于NUM到TRUE的条目对应的访问，这表明该条目相应的交易已完成。我们的最终目的是允许扫描查看最新的书面数据，即需要更新读取点。
4.更新readpoint：它也以完整（WriteEntry WriteEntry）方法完成。在每个客户设置相应的条目已完成为true之后，它将按队列的顺序进行旅行。True将更新读取点到此位置，直到当您遇到完整的位置为false时停止它编写每个客户端后，它将尝试将读取点更新为最大的连续事务点（因为可以在上一个交易之前启动交易）。
看到这个，您可能会想到。如果交易a在交易C之前，则未完成事务A，但是交易C已完成，并且交易C仅能将读取点更新为交易A.C返回之前的位置，以成功写入。原则上，扫描应该能够找到交易C的数据。但是，由于读取点未更新为c，它将导致现象：事务C清楚地提示成功执行，但是当查询是QueriedInstead时。
因此，上面提到的第四步实际上还没有结束。客户端执行完整（写入writeentry）之后，如果该方法返回的值为false，它也将执行waitforread（writentry e）方法。内容，源代码逻辑以下：
当读取点大于条目的写入时，将返回此方法，该条目保证交易以有序的方式完成。这次，客户最终将返回写作，也就是说，最新数据将是下次查询。以下是源代码逻辑：
回到上面的图片，当前写端客户2正在等待写端3写后要赶上3个写作客户3，所以写作客户端2在舞台上，当写作成功等待readpoint赶上。时间，读取点为6。查询时，您只能查询写入点<= 6的数据，然后返回写入点的最大数据。尽管已成功编写了写入点= 8的数据，但客户端未接收状态成功的写作，数据是看不见的，并且与一般认知一致。
以上是我编写HBase时MVCC的工作流程。扫描最好理解。每个扫描请求将申请一个读取点，以确保不会检索读取点后的交易。
此外，上述HBASE查询机制基于HBASE的默认交易级别，即读取社区级别。在同一时间，HBase还支持读取的不承认级别，也就是说，我们将扫描的MVCC值设置为在此期间的大值查询，大于所有应用程序的当前MVCC值。
最终回到首要问题，您查询的客户端将查询Zhang san和li si数据，但是由于Li Si在ReadPoint的所有数据中都不等于WritPoint的最大数据，因此最终返回给客户端的数据是李si。结果，结果是李si。因此，满足期望，没有问题，上述问题就是这样。
回顾全文，可以看出，在HBase查询API之后执行的业务逻辑非常复杂。如果您可以将API称为初级人员，那么剩下的事情HBase将帮助您做到这一点。要晋升到HBase的高级阶段，需要理解和掌握这些原则。只有掌握这些原则，您才能在HBase的问题定位和性能优化中发挥出色。
最后，如果您想一起成为一个大数据，请喜欢转发并注意。下次我们不会迷路。我们将在大数据的道路上一起前进！
原始：https：//juejin.cn/post/7098232975623946247