blogjava-凯发k8网页登录

sstable的定义

sstable作为存储使用

sstable在compaction过程中的使用

sstable的locality和in memory

sstable压缩

sstable的读缓存

bloom filter

sstable设计成immutable的好处

转自：http://www.cnblogs.com/fanzhidongyzby/p/4098546.html

服务器端编程经常需要构造高性能的io模型，常见的io模型有四种：

（1）同步阻塞io（blocking io）：即传统的io模型。

（2）同步非阻塞io（non-blocking io）：默认创建的socket都是阻塞的，非阻塞io要求socket被设置为nonblock。注意这里所说的nio并非java的nio（new io）库。

（3）io多路复用（io multiplexing）：即经典的reactor设计模式，有时也称为异步阻塞io，java中的selector和linux中的epoll都是这种模型。

（4）异步io（asynchronous io）：即经典的proactor设计模式，也称为异步非阻塞io。

同步和异步的概念描述的是用户线程与内核的交互方式：同步是指用户线程发起io请求后需要等待或者轮询内核io操作完成后才能继续执行；而异步是指用户线程发起io请求后仍继续执行，当内核io操作完成后会通知用户线程，或者调用用户线程注册的回调函数。

阻塞和非阻塞的概念描述的是用户线程调用内核io操作的方式：阻塞是指io操作需要彻底完成后才返回到用户空间；而非阻塞是指io操作被调用后立即返回给用户一个状态值，无需等到io操作彻底完成。

另外，richard stevens 在《unix 网络编程》卷1中提到的基于信号驱动的io（signal driven io）模型，由于该模型并不常用，本文不作涉及。接下来，我们详细分析四种常见的io模型的实现原理。为了方便描述，我们统一使用io的读操作作为示例。

一、同步阻塞io

同步阻塞io模型是最简单的io模型，用户线程在内核进行io操作时被阻塞。

图1 同步阻塞io

如图1所示，用户线程通过系统调用read发起io读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。

用户线程使用同步阻塞io模型的伪代码描述为：

即用户需要等待read将socket中的数据读取到buffer后，才继续处理接收的数据。整个io请求的过程中，用户线程是被阻塞的，这导致用户在发起io请求时，不能做任何事情，对cpu的资源利用率不够。

二、同步非阻塞io

同步非阻塞io是在同步阻塞io的基础上，将socket设置为nonblock。这样做用户线程可以在发起io请求后可以立即返回。

图2 同步非阻塞io

如图2所示，由于socket是非阻塞的方式，因此用户线程发起io请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起io请求，直到数据到达后，才真正读取到数据，继续执行。

用户线程使用同步非阻塞io模型的伪代码描述为：

即 用户需要不断地调用read，尝试读取socket中的数据，直到读取成功后，才继续处理接收的数据。整个io请求的过程中，虽然用户线程每次发起io请 求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的cpu的资源。一般很少直接使用这种模型，而是在其他io模型中使用非阻 塞io这一特性。

三、io多路复用

io多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞io模型中轮询等待的问题。

图3 多路分离函数select

如图3所示，用户首先将需要进行io操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。

从 流程上来看，使用select函数进行io请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效 率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的io请求。用户可以注册多个socket，然后不断地调 用select读取被激活的socket，即可达到在同一个线程内同时处理多个io请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。

用户线程使用select函数的伪代码描述为：

其中while循环前将socket添加到select监视中，然后在while内一直调用select获取被激活的socket，一旦socket可读，便调用read函数将socket中的数据读取出来。

然 而，使用select函数的优点并不仅限于此。虽然上述方式允许单线程内处理多个io请求，但是每个io请求的过程还是阻塞的（在select函数上阻 塞），平均时间甚至比同步阻塞io模型还要长。如果用户线程只注册自己感兴趣的socket或者io请求，然后去做自己的事情，等到数据到来时再进行处 理，则可以提高cpu的利用率。

io多路复用模型使用了reactor设计模式实现了这一机制。

图4 reactor设计模式

如 图4所示，eventhandler抽象类表示io事件处理器，它拥有io文件句柄handle（通过get_handle获取），以及对handle的 操作handle_event（读/写等）。继承于eventhandler的子类可以对事件处理器的行为进行定制。reactor类用于管理 eventhandler（注册、删除等），并使用handle_events实现事件循环，不断调用同步事件多路分离器（一般是内核）的多路分离函数 select，只要某个文件句柄被激活（可读/写等），select就返回（阻塞），handle_events就会调用与文件句柄关联的事件处理器的 handle_event进行相关操作。

图5 io多路复用

如 图5所示，通过reactor的方式，可以将用户线程轮询io操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理 器之后可以继续执行做其他的工作（异步），而reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知 相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路io复用 模型也被称为异步阻塞io模型。注意，这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用io多路复用模型 时，socket都是设置为nonblock的，不过这并不会产生影响，因为用户发起io请求时，数据已经到达了，用户线程一定不会被阻塞。

用户线程使用io多路复用模型的伪代码描述为：

用户需要重写eventhandler的handle_event函数进行读取数据、处理数据的工作，用户线程只需要将自己的eventhandler注册到reactor即可。reactor中handle_events事件循环的伪代码大致如下。

事件循环不断地调用select获取被激活的socket，然后根据获取socket对应的eventhandler，执行器handle_event函数即可。

io多路复用是最常使用的io模型，但是其异步程度还不够“彻底”，因为它使用了会阻塞线程的select系统调用。因此io多路复用只能称为异步阻塞io，而非真正的异步io。

四、异步io

“真 正”的异步io需要操作系统更强的支持。在io多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异 步io模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在io完成后通知用户线程直接使用即可。

异步io模型使用了proactor设计模式实现了这一机制。

图6 proactor设计模式

如 图6，proactor模式和reactor模式在结构上比较相似，不过在用户（client）使用方式上差别较大。reactor模式中，用户线程通过 向reactor对象注册感兴趣的事件监听，然后事件触发时调用事件处理函数。而proactor模式中，用户线程将 asynchronousoperation（读/写等）、proactor以及操作完成时的completionhandler注册到 asynchronousoperationprocessor。asynchronousoperationprocessor使用facade模式提 供了一组异步操作api（读/写等）供用户使用，当用户线程调用异步api后，便继续执行自己的任务。 asynchronousoperationprocessor 会开启独立的内核线程执行异步操作，实现真正的异步。当异步io操作完成 时，asynchronousoperationprocessor将用户线程与asynchronousoperation一起注册的proactor 和completionhandler取出，然后将completionhandler与io操作的结果数据一起转发给 proactor，proactor负责回调每一个异步操作的事件完成处理函数handle_event。虽然proactor模式中每个异步操作都可以 绑定一个proactor对象，但是一般在操作系统中，proactor被实现为singleton模式，以便于集中化分发操作完成事件。

图7 异步io

如 图7所示，异步io模型中，用户线程直接使用内核提供的异步io api发起read请求，且发起后立即返回，继续执行用户线程代码。不过此时用户线程已 经将调用的asynchronousoperation和completionhandler注册到内核，然后操作系统开启独立的内核线程去处理io操 作。当read请求的数据到达时，由内核负责读取socket中的数据，并写入用户指定的缓冲区中。最后内核将read的数据和用户线程注册的 completionhandler分发给内部proactor，proactor将io完成的信息通知给用户线程（一般通过调用用户线程注册的完成事件 处理函数），完成异步io。

用户线程使用异步io模型的伪代码描述为：

用户需要重写completionhandler的handle_event函数进行处理数据的工作，参数buffer表示proactor已经准备好的数据，用户线程直接调用内核提供的异步io api，并将重写的completionhandler注册即可。

相 比于io多路复用模型，异步io并不十分常用，不少高性能并发服务程序使用io多路复用模型 多线程任务处理的架构基本可以满足需求。况且目前操作系统对 异步io的支持并非特别完善，更多的是采用io多路复用模型模拟异步io的方式（io事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定的 缓冲区中）。java7之后已经支持了异步io，感兴趣的读者可以尝试使用。

本文从基本概念、工作流程和代码示 例三个层次简要描述了常见的四种高性能io模型的结构和原理，理清了同步、异步、阻塞、非阻塞这些容易混淆的概念。通过对高性能io模型的理解，可以在服 务端程序的开发中选择更符合实际业务特点的io模型，提高服务质量。希望本文对你有所帮助。

相似的：
http://www.cnblogs.com/nufangrensheng/p/3588690.html
http://www.ibm.com/developerworks/cn/linux/l-async/

netty3中的reactor模式

netty3中的intercepting filter模式

参考：

1. 纪录每个client的每次访问信息。
2. 对client进行认证和授权检查（authentication and authorization）。
3. 检查当前session是否合法。
4. 检查client的ip地址是否可信赖或不可信赖（ip地址白名单、黑名单）。
5. 请求数据是否先要解压或解码。
6. 是否支持client请求的类型、browser版本等。
7. 添加性能监控信息。
8. 添加调试信息。
9. 保证所有异常都被正确捕获到，对未预料到的异常做通用处理，防止给client看到内部堆栈信息。
   

在响应返回给客户端之前，有时候也需要做一些预处理再返回：

1. 对响应消息编码或压缩。
2. 为所有响应添加公共头、尾等消息。
3. 进一步enrich响应消息，如添加公共字段、session信息、cookie信息，甚至完全改变响应消息等。

问题解决

intercepting filter模式

1. 在存储上，可以使用数组来存储所有的processor，processor在数组中的位置表示这个processor在链条中的位置；也可以用链表来存储所有的processor，此时processor在这个链表中的位置即是在链中的位置。
2. 在抽象上，可以所有的逻辑都封装在processor中，也可以将核心逻辑使用processor抽象，而外围逻辑使用filter抽象。
3. 在流程控制上，一般通过在processor实现方法中直接使用processorchain实例(通过参数掺入)来控制流程，利用方法调用的进栈出栈的特性实现preprocess()和postprocess()处理。

intercepting filter模式在servlet的filter中的实现（jetty版本）

intercepting filter模式在netty3中的实现

intercepting filter模式的缺点

参考

什么是reactor模式

reactor模式结构

，一个selectionkey表达一个有事件发生的channel以及该channel上的事件类型。上图的“synchronous event demultiplexer ---notifies--> handle”的流程如果是对的，那内部实现应该是select()方法在事件到来后会先设置handle的状态，然后返回。不了解内部实现机制，因而保留原图。
initiation dispatcher：用于管理event handler，即eventhandler的容器，用以注册、移除eventhandler等；另外，它还作为reactor模式的入口调用synchronous event demultiplexer的select方法以阻塞等待事件返回，当阻塞等待返回时，根据事件发生的handle将其分发给对应的event handler处理，即回调eventhandler中的handle_event()方法。
event handler：定义事件处理方法：handle_event()，以供initiationdispatcher回调使用。
concrete event handler：事件eventhandler接口，实现特定事件处理逻辑。

reactor模式模块之间的交互

简单描述一下reactor各个模块之间的交互流程，先从序列图开始：

1. 初始化initiationdispatcher，并初始化一个handle到eventhandler的map。
2. 注册eventhandler到initiationdispatcher中，每个eventhandler包含对相应handle的引用，从而建立handle到eventhandler的映射（map）。
3. 调用initiationdispatcher的handle_events()方法以启动event loop。在event loop中，调用select()方法（synchronous event demultiplexer）阻塞等待event发生。
4. 当某个或某些handle的event发生后，select()方法返回，initiationdispatcher根据返回的handle找到注册的eventhandler，并回调该eventhandler的handle_events()方法。
5. 在eventhandler的handle_events()方法中还可以向initiationdispatcher中注册新的eventhandler，比如对acceptoreventhandler来，当有新的client连接时，它会产生新的eventhandler以处理新的连接，并注册到initiationdispatcher中。

reactor模式实现

在中，一直以logging server来分析reactor模式，这个logging server的实现完全遵循这里对reactor描述，因而放在这里以做参考。logging server中的reactor模式实现分两个部分：client连接到logging server和client向logging server写log。因而对它的描述分成这两个步骤。
client连接到logging server

1. logging server注册loggingacceptor到initiationdispatcher。
2. logging server调用initiationdispatcher的handle_events()方法启动。
3. initiationdispatcher内部调用select()方法（synchronous event demultiplexer），阻塞等待client连接。
4. client连接到logging server。
5. initiationdisptcher中的select()方法返回，并通知loggingacceptor有新的连接到来。
6. loggingacceptor调用accept方法accept这个新连接。
7. loggingacceptor创建新的logginghandler。
8. 新的logginghandler注册到initiationdispatcher中(同时也注册到synchonous event demultiplexer中)，等待client发起写log请求。
client向logging server写log

1. client发送log到logging server。
2. initiationdispatcher监测到相应的handle中有事件发生，返回阻塞等待，根据返回的handle找到logginghandler，并回调logginghandler中的handle_event()方法。
3. logginghandler中的handle_event()方法中读取handle中的log信息。
4. 将接收到的log写入到日志文件、数据库等设备中。
3.4步骤循环直到当前日志处理完成。
5. 返回到initiationdispatcher等待下一次日志写请求。

在有对reactor模式的c 的实现版本，多年不用c ，因而略过。 

java nio对reactor的实现

在java的nio中，对reactor模式有无缝的支持，即使用selector类封装了操作系统提供的synchronous event demultiplexer功能。这个doug lea已经在中有非常深入的解释了，因而不再赘述，另外对doug lea的有一些简单解释，至少它的代码格式比doug lea的ppt要整洁一些。

需要指出的是，不同这里使用initiationdispatcher来管理eventhandler，在doug lea的版本中使用selectionkey中的attachment来存储对应的eventhandler，因而不需要注册eventhandler这个步骤，或者设置attachment就是这里的注册。而且在这篇文章中，doug lea从单线程的reactor、acceptor、handler实现这个模式出发；演化为将handler中的处理逻辑多线程化，实现类似proactor模式，此时所有的io操作还是单线程的，因而再演化出一个main reactor来处理connect事件(acceptor)，而多个sub reactor来处理read、write等事件(handler)，这些sub reactor可以分别再自己的线程中执行，从而io操作也多线程化。这个最后一个模型正是netty中使用的模型。并且在的9.5 determine the number of initiation dispatchers in an application中也有相应的描述。

eventhandler接口定义

对eventhandler的定义有两种设计思路：single-method设计和multi-method设计：
a single-method interface：它将event封装成一个event object，eventhandler只定义一个handle_event(event event)方法。这种设计的好处是有利于扩展，可以后来方便的添加新的event类型，然而在子类的实现中，需要判断不同的event类型而再次扩展成 不同的处理方法，从这个角度上来说，它又不利于扩展。另外在netty3的使用过程中，由于它不停的创建channelevent类，因而会引起gc的不稳定。
a multi-method interface：这种设计是将不同的event类型在 eventhandler中定义相应的方法。这种设计就是netty4中使用的策略，其中一个目的是避免channelevent创建引起的gc不稳定， 另外一个好处是它可以避免在eventhandler实现时判断不同的event类型而有不同的实现，然而这种设计会给扩展新的event类型时带来非常 大的麻烦，因为它需要该接口。

关于netty4对netty3的改进可以参考：

channelhandler with no event object

in 3.x, every i/o operation created a channelevent object. for each read / write, it additionally created a new channelbuffer. it simplified the internals of netty quite a lot because it delegates resource management and buffer pooling to the jvm. however, it often was the root cause of gc pressure and uncertainty which are sometimes observed in a netty-based application under high load.

4.0 removes event object creation almost completely by replacing the event objects with strongly typed method invocations. 3.x had catch-all event handler methods such as handleupstream() and handledownstream(), but this is not the case anymore. every event type has its own handler method now:

为什么使用reactor模式

归功与netty和java nio对reactor的宣传，本文慕名而学习的reactor模式，因而已经默认reactor具有非常优秀的性能，然而慕名归慕名，到这里，我还是要不得不问自己reactor模式的好处在哪里？即为什么要使用这个reactor模式？在中是这么说的：

reactor pattern优点

separation of concerns: the reactor pattern decouples application-independent demultiplexing and dispatching mechanisms from application-specific hook method functionality. the application-independent mechanisms become reusable components that know how to demultiplex events and dispatch the appropriate hook methods defined by event handlers. in contrast, the application-specific functionality in a hook method knows how to perform a particular type of service.

improve modularity, reusability, and configurability of event-driven applications: the pattern decouples application functionality into separate classes. for instance, there are two separate classes in the logging server: one for establishing connections and another for receiving and processing logging records. this decoupling enables the reuse of the connection establishment class for different types of connection-oriented services (such as file transfer, remote login, and video-on-demand). therefore, modifying or extending the functionality of the logging server only affects the implementation of the logging handler class.

improves application portability: the initiation dispatcher’s interface can be reused independently of the os system calls that perform event demultiplexing. these system calls detect and report the occurrence of one or more events that may occur simultaneously on multiple sources of events. common sources of events may in- clude i/o handles, timers, and synchronization objects. on unix platforms, the event demultiplexing system calls are called select and poll [1]. in the win32 api [16], the waitformultipleobjects system call performs event demultiplexing.

provides coarse-grained concurrency control: the reactor pattern serializes the invocation of event handlers at the level of event demultiplexing and dispatching within a process or thread. serialization at the initiation dispatcher level often eliminates the need for more complicated synchronization or locking within an application process.

这些貌似是很多模式的共性：解耦、提升复用性、模块化、可移植性、事件驱动、细力度的并发控制等，因而并不能很好的说明什么，特别是它鼓吹的对性能的提升，这里并没有体现出来。当然在这篇文章的开头有描述过另一种直观的实现：thread-per-connection，即传统的实现，提到了这个传统实现的以下问题：

thread per connection缺点

efficiency: threading may lead to poor performance due to context switching, synchronization, and data movement [2];

programming simplicity: threading may require complex concurrency control schemes;

portability: threading is not available on all os platforms.

对于性能，它其实就是第一点关于efficiency的描述，即线程的切换、同步、数据的移动会引起性能问题。也就是说从性能的角度上，它最大的提升就是减少了性能的使用，即不需要每个client对应一个线程。我的理解，其他业务逻辑处理很多时候也会用到相同的线程，io读写操作相对cpu的操作还是要慢很多，即使reactor机制中每次读写已经能保证非阻塞读写，这里可以减少一些线程的使用，但是这减少的线程使用对性能有那么大的影响吗？答案貌似是肯定的，这篇论文()对随着线程的增长带来性能降低做了一个统计：

在这个统计中，每个线程从磁盘中读8kb数据，每个线程读同一个文件，因而数据本身是缓存在操作系统内部的，即减少io的影响；所有线程是事先分配的，不会有线程启动的影响；所有任务在测试内部产生，因而不会有网络的影响。该统计数据运行环境：linux 2.2.14，2gb内存，4-way 500mhz pentium iii。从图中可以看出，随着线程的增长，吞吐量在线程数为8个左右的时候开始线性下降，并且到64个以后而迅速下降，其相应事件也在线程达到256个后指数上升。即1 1<2，因为线程切换、同步、数据移动会有性能损失，线程数增加到一定数量时，这种性能影响效果会更加明显。

对于这点，还可以参考，用以描述同时有10k个client发起连接的问题，到2010年的时候已经出现10m problem了。

当然也有人说：.在不久的将来可能又会发生不同的变化，或者这个变化正在、已经发生着？没有做过比较仔细的测试，因而不敢随便断言什么，然而本人观点，即使线程变的影响并没有以前那么大，使用reactor模式，甚至时seda模式来减少线程的使用，再加上其他解耦、模块化、提升复用性等优点，还是值得使用的。

reactor模式的缺点

reactor模式的缺点貌似也是显而易见的：
1. 相比传统的简单模型，reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2. reactor模式需要底层的synchronous event demultiplexer支持，比如java中的selector支持，操作系统的select系统调用支持，如果要自己实现synchronous event demultiplexer可能不会有那么高效。
3. reactor模式在io读写数据时还是在同一个线程中实现的，即使使用多个reactor机制的情况下，那些共享一个reactor的channel如果出现一个长时间的数据读写，会影响这个reactor中其他channel的相应时间，比如在大文件传输时，io操作就会影响其他client的相应时间，因而对这种操作，使用传统的thread-per-connection或许是一个更好的选择，或则此时使用proactor模式。

参考

dlevin 2015-09-02 15:14 发表评论

]]>

hbase读的实现

compaction

1. minor compaction是指选取一些小的、相邻的storefile将他们合并成一个更大的storefile，在这个过程中不会处理已经deleted或expired的cell。一次minor compaction的结果是更少并且更大的storefile。（这个是对的吗？bigtable中是这样描述minor compaction的：as write operations execute, the size of the memtable in- creases. when the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an sstable and written to gfs. this minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. incom- ing read and write operations can continue while com- pactions occur. 也就是说它将memtable的数据flush的一个hfile/sstable称为一次minor compaction）
2. major compaction是指将所有的storefile合并成一个storefile，在这个过程中，标记为deleted的cell会被删除，而那些已经expired的cell会被丢弃，那些已经超过最多版本数的cell会被丢弃。一次major compaction的结果是一个hstore只有一个storefile存在。major compaction可以手动或自动触发，然而由于它会引起很多的io操作而引起性能问题，因而它一般会被安排在周末、凌晨等集群比较闲的时间。
   

hregion split

hregion负载均衡

hregionserver recovery

hbase架构简单总结

1. hbase采用强一致性模型，在一个写返回后，保证所有的读都读到相同的数据。
2. 通过hregion动态split和merge实现自动扩展，并使用hdfs提供的多个数据备份功能，实现高可用性。
3. 采用hregionserver和datanode运行在相同的服务器上实现数据的本地化，提升读写性能，并减少网络压力。
4. 内建hregionserver的宕机自动恢复。采用wal来replay还未持久化到hdfs的数据。
5. 可以无缝的和hadoop/mapreduce集成。
   

1. wal的replay过程可能会很慢。
2. 灾难恢复比较复杂，也会比较慢。
3. major compaction会引起io storm。
4. 。。。。
   

参考：

hbase架构组成

1. 管理hregionserver，实现其负载均衡。
2. 管理和分配hregion，比如在hregion split时分配新的hregion；在hregionserver退出时迁移其内的hregion到其他hregionserver上。
3. 实现ddl操作（data definition language，namespace和table的增删改，column familiy的增删改等）。
4. 管理namespace和table的元数据（实际存储在hdfs上）。
5. 权限控制（acl）。

1. 存放和管理本地hregion。
2. 读写hdfs，管理table中的数据。
3. client直接通过hregionserver读写数据（从hmaster中获取元数据，找到rowkey所在的hregion/hregionserver后）。

1. 存放整个 hbase集群的元数据以及集群的状态信息。
2. 实现hmaster主从节点的failover。

hregion

hmaster

1. 协调hregionserver
   1. 启动时hregion的分配，以及负载均衡和修复时hregion的重新分配。
   2. 监控集群中所有hregionserver的状态(通过heartbeat和监听zookeeper中的状态)。
      
2. admin职能
   1. 创建、删除、修改table的定义。
      

zookeeper：协调者

how the components work together

hbase的第一次读写

1. 从zookeeper(/hbase/meta-region-server)中获取hbase:meta的位置（hregionserver的位置），缓存该位置信息。
2. 从hregionserver中查询用户table对应请求的rowkey所在的hregionserver，缓存该位置信息。
3. 从查询到hregionserver中读取row。

hbase:meta表

hregionserver详解

1. wal即write ahead log，在早期版本中称为hlog，它是hdfs上的一个文件，如其名字所表示的，所有写操作都会先保证将数据写入这个log文件后，才会真正更新memstore，最后写入hfile中。采用这种模式，可以保证hregionserver宕机后，我们依然可以从该log文件中读取数据，replay所有的操作，而不至于数据丢失。这个log文件会定期roll出新的文件而删除旧的文件(那些已持久化到hfile中的log可以删除)。wal文件存储在/hbase/wals/${hregionserver_name}的目录中(在0.94之前，存储在/hbase/.logs/目录中)，一般一个hregionserver只有一个wal实例，也就是说一个hregionserver的所有wal写都是串行的(就像log4j的日志写也是串行的)，这当然会引起性能问题，因而在hbase 1.0之后，通过实现了多个wal并行写(multiwal)，该实现采用hdfs的多个管道写，以单个hregion为单位。关于wal可以参考wikipedia的。顺便吐槽一句，英文版的维基百科竟然能毫无压力的正常访问了，这是某个gfw的疏忽还是以后的常态？
2. blockcache是一个读缓存，即“引用局部性”原理（也应用于cpu，，空间局部性是指cpu在某一时刻需要某个数据，那么有很大的概率在一下时刻它需要的数据在其附近；时间局部性是指某个数据在被访问过一次后，它有很大的概率在不久的将来会被再次的访问），将数据预读取到内存中，以提升读的性能。hbase中提供两种blockcache的实现：默认on-heap lrublockcache和bucketcache(通常是off-heap)。通常bucketcache的性能要差于lrublockcache，然而由于gc的影响，lrublockcache的延迟会变的不稳定，而bucketcache由于是自己管理blockcache，而不需要gc，因而它的延迟通常比较稳定，这也是有些时候需要选用bucketcache的原因。这篇文章对on-heap和off-heap的blockcache做了详细的比较。
3. hregion是一个table中的一个region在一个hregionserver中的表达。一个table可以有一个或多个region，他们可以在一个相同的hregionserver上，也可以分布在不同的hregionserver上，一个hregionserver可以有多个hregion，他们分别属于不同的table。hregion由多个store(hstore)构成，每个hstore对应了一个table在这个hregion中的一个column family，即每个column family就是一个集中的存储单元，因而最好将具有相近io特性的column存储在一个column family，以实现高效读取(数据局部性原理，可以提高缓存的命中率)。hstore是hbase中存储的核心，它实现了读写hdfs功能，一个hstore由一个memstore 和0个或多个storefile组成。
   
   1. memstore是一个写缓存(in memory sorted buffer)，所有数据的写在完成wal日志写后，会 写入memstore中，由memstore根据一定的算法将数据flush到地层hdfs文件中(hfile)，通常每个hregion中的每个 column family有一个自己的memstore。
   2. hfile(storefile) 用于存储hbase的数据(cell/keyvalue)。在hfile中的数据是按rowkey、column family、column排序，对相同的cell(即这三个值都一样)，则按timestamp倒序排列。

hregionserver中数据写流程图解

memstore flush

1. 当一个hregion中的所有memstore的大小总和超过了hbase.hregion.memstore.flush.size的大小，默认128mb。此时当前的hregion中所有的memstore会flush到hdfs中。
2. 当全局memstore的大小超过了hbase.regionserver.global.memstore.upperlimit的大小，默认40％的内存使用量。此时当前hregionserver中所有hregion中的memstore都会flush到hdfs中，flush顺序是memstore大小的倒序（一个hregion中所有memstore总和作为该hregion的memstore的大小还是选取最大的memstore作为参考？有待考证），直到总体的memstore使用量低于hbase.regionserver.global.memstore.lowerlimit，默认38%的内存使用量。
3. 当前hregionserver中wal的大小超过了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量，当前hregionserver中所有hregion中的memstore都会flush到hdfs中，flush使用时间顺序，最早的memstore先flush直到wal的数量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs。说这两个相乘的默认大小是2gb，查代码，hbase.regionserver.max.logs默认值是32，而hbase.regionserver.hlog.blocksize是hdfs的默认blocksize，32mb。但不管怎么样，因为这个大小超过限制引起的flush不是一件好事，可能引起长时间的延迟，因而这篇文章给的建议：“hint: keep hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs just a bit above hbase.regionserver.global.memstore.lowerlimit * hbase_heapsize.”。并且需要注意，给的描述是有错的(虽然它是官方的文档)。
   

hfile格式

参考：

问题发现

看似这个是一个规律（套用同事的一句话：一次发生时偶然，两次发生就是科学了）。然而此时我其实依然不太相信log4j是“凶手”，因为我一直觉得log4j是一个简单的日志输出框架，它要是出问题也只是它自己的问题，是局部的，而这个问题的出现明显是全局的，直到我突然脑子一闪而过，日志打印的操作是synchronized，也就是说在日志文件roll的时候，所有其它需要打日志的线程都要等待直到roll完成，如果这个roll过程超过了2分钟，那么就会发生我们看到的stripe lock超时，也就是发生了程序“假死”的状态。重新查看log4j打印日志的方法调用栈，它会在两个地方用synchronized，即同一个category（logger）类实例：

    public void callappenders(loggingevent event) {
        int writes = 0;
        for(category c = this; c != null; c=c.parent) {
            // protected against simultaneous call to addappender, removeappender,
            synchronized(c) {
                if(c.aai != null) {
                    writes  = c.aai.appendlooponappenders(event);
                }
                if(!c.additive) {
                    break;
                }
            }
        }
。。。
    }