《HBase的Write Ahead Log (WAL)整体架构 线程模型 - 数据库服务器.docx》由会员分享，可在线阅读，更多相关《HBase的Write Ahead Log (WAL)整体架构 线程模型 - 数据库服务器.docx（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、HBase的WriteAheadLog(WAL)整体架构线程模型-数据库服务器-最新IT资讯_电脑知识大全_网络安全教程-次元立方网解决的问题HBase的WriteAheadLog(WAL)提供了一种高并发、持久化的日志保存与回放机制。每一个业务数据的写入操作PUT/DELETE执行前，都会记账在WAL中。假如出现HBase服务器宕机，则能够从WAL中回放执行之前没有完成的操作。本文主要讨论HBase的WAL机制，怎样从线程模型、消息机制的层面上，解决这些问题：1.由于多个HBase客户端能够对某一台HBaseRegionServer发起并发的业务数据写入请求，因而WAL也要支持并发的多线程日
2、志写入。确保日志写入的线程安全、高并发。2.对于单个HBase客户端，它在WAL中的日志顺序，应该与这个客户端发起的业务数据写入请求的顺序一致。对于以上两点要求，大家很容易想到，用一个队列就搞定了。见下文的架构图。3.为了保证高可靠，日志不仅要写入文件系统的内存缓存，而且应该尽快、强迫刷到磁盘上即WAL的Sync操作。但是Sync太频繁，性能会变差。所以：(1)Sync应当在多个后台线程中异步执行(2)频繁的多个Sync，能够合并为一次Sync适当放松对可靠性的要求，提高性能。架构图线程模型、消息机制下面是我画的HBaseWAL架构图。我在图上加了不少注解，所以这张图应该是自解释的：Regio
3、nServerRPC服务线程这些线程处理HBase客户端通过RPC服务调用实际上是GoogleProtobuf服务调用发出的业务数据写入请求。在上图的例子中，RegionServerRPC服务线程1做了3个Row的Append操作，和一个强迫刷磁盘的Sync操作。Sync操作是为了确保之前的Append操作包括涉及的业务数据一定可靠地记录到了磁盘上的日志中，然后HBase才能做后续相对不可靠的复杂操作，比方写入MemStore。这就是WriteAhead的语义。从架构图中可见，并发的Append操作只是往队列中增加了Append请求对象。这里的队列是一个LMAXDisrutporRingBuf
4、fer我的这篇文章作了介绍，你能够简单理解为是一个无锁高并发队列。Append的详细代码如下：对于Sync操作：(1)往队列里放一个SyncFuture对象，代表一次Sync操作请求。每一个SyncFuture都有一个自增的SequenceID这是全局唯一的，由LMAXDisrutpor队列创立。后来的SyncFuture的SequenceID更高。(2)调用SyncFuture.get()阻塞等待，直到后台线程架构图中的SyncRunner通知SyncFuture退出阻塞，表明WAL日志已经保存在了磁盘上。WAL日志消费线程WAL机制中，只要一个WAL日志消费线程，从队列中获取Append和
5、Sync操作。这样一个多生产者，单消费者的形式，决定了WAL日志并发写入时日志的全局唯一顺序。1.对于获取到的Append操作，直接调用HadoopSequenceFileWriter将这个Append操作包括元数据和rowkey,family,qualifier,timestamp,value等业务数据写入文件。因而WAL日志文件使用的是HadoopSequence文件格式。当然，它可以以替换成其他存储格式，如Avro。HadoopSequence文件格式不再这里累述，其主要特点是：(1)二进制格式。rowkey,family,qualifier,timestamp,value等HBaseb
6、yte数据，都原封不动地顺序写入文件。(2)Sequence文件中，每隔若干行，会插入一个16字节的魔数作为分隔符。这样假如文件损坏，导致某一行残缺不全，能够通过这个魔数分隔符跳过这一行，继续读取下一个完好的行。(3)支持压缩。能够按行压缩。可以以按块压缩将多行打成一个块2.对于获取到的Sync操作，会提交给后台SyncRunner的线程池见上文架构图异步执行。以上的this.syncRunners就是SyncRunner线程池。能够看到，通过计算syncRunnerIndex，采用了简单的轮循提交算法。另外，WAL日志消费线程，会尝试采集一批SyncFuture对象即sync操作，一次提交给
7、SyncRunner。所以，在以上代码中，能够看到传入offer()方法的，是this.syncFutures这一SyncFutures数组，而不是单个SyncFuture对象。采集一批次再提交，性能比拟好。但是单个批次需要积累的SyncFuture对象越多，则Sync的及时性越差，会导致前台RegionServerRPC服务线程阻塞在SyncFuture.get()上的时间就越长。因而，这里存在吞吐量和及时性之间的平衡。HBase为了支持海量数据的写入，在这里更倾向于高吞吐量，体如今了下面注释中。详细多少个SyncFuture构成一个批次，有一定的策略，在此不再累述。SyncRunner线程
8、1.从队列中获取一个由WAL日志消费线程提交的SyncFuture下列图红框中的代码。2.调用文件系统API，执行sync()操作下列图蓝框中的代码合并屡次频繁的sync()操作，提高性能。上文提到，WAL日志消费线程一次会提交多个SyncFuture。对此，SyncRunner线程只会落实执行其中最新的SyncFuture(也就是SequenceID最大的那个)所代表的Sync操作。而忽略之前的SyncFuture。这就是下列图绿框中的代码。3.假如sync()完成，或者由于上面提到的合并忽略了某一个SyncFuture，那么会调用releaseSyncFuture()=Object.notify()来通知SyncFuture阻塞退出。之前阻塞在SyncFuture.get()上的RegionServerRPC服务线程就能够继续往下执行了。至此，整个WAL写入流程完成。我觉得对线程并发写入文件时，用队列来协调，保证日志写入的顺序，这还是比拟容易想到的。但是，提供Sync()API确保日志写入的可靠性，同时避免频繁的Sync()操作影响性能。这是HBaseWAL实现的一大亮点。后续我再研究研究WAL的checkpoint和读取WAL回放机制，再和大家共享。