面向HBase的内存key-value缓存的实现

0x01 背景

之所以要实现这个缓存主要原因如下(但是由于不是实际业务场景需求，所以可能不太准确，也可能不存在这个需求):
* 非结构化数据的爆炸式增长
* 处理速度的要求越来越高
* HBase是面向硬盘的
* 内存容量越来越大
* 热点数据可以在内存放下

0x02 设计方案

通常的要实现缓存，主要是在有两个大方向实现，一个是在客户端实现，另一个时在服务端实现
* 客户端实现
- 修改Hbase Client的源码,在Put, Get等关键操作的地方加入缓存机制
- 在client端设计一种缓存服务层,并实现一个分布式的Key-value缓存系统, 对Hbase Client进行重新封装
* 服务端实现
- 修改HBase Server端的源码,在Put, Get等关键操作的地方加入缓存机制
- 在服务端添加一层代理服务,解析所有client的请求,对Put, Get等关键

两种大方向的第一种方案，都是直接修改hbase的源代码，直接修改源码性能可能会更好一些，但是修改源码，会过于依赖Hbase的版本，对于每一个base的版本更新都可能要重新查看源码，重新修改，除此之外1)中的方案一，由于是在本地客户端进行的缓存，所以没有实现分布式的缓存，因此可能存在缓存命中率低，缓存数据不一致的情况。

客户端实现中的方案二，进行重新地封装，不对源码进行修改，同时使用分布式的缓存，既可以提高缓存的命中率，同时又解决的对hbase过度依赖的问题，但是可能会降低性能。

服务端实现中的方案二，通过设计一个缓存代理服务，同样可以解决对hbase的过度依赖，降低了整个系统的耦合性，但是实现一个代理服务并非那么简单，而且需要对hbase的通信机制以及相关协议比较了解。

通过上面的分析比较，考虑到可行性和技术背景，客户端实现的方案二是最合适的方案，而且其性能和可维护性，扩展性相对来说都是比较好的。分布式缓存系统我们使用Redis实现，并且在client本地实现一个LocalCache，尽可能的提高缓存的命中率，减少通信造成的时间延迟（局部性假设，同一个客户端最有可能访问它put的数据）。

0x03 实现

系统的整体架构图如下

按照0x02的方案，要实现的是图中的client，对原生的hbase client进行封装，包括redis主要实现了如下功能

主要包括redis集群的实现，以及redis client的封装和localcache的实现。
* Redis集群部署：可以快速的搭建一个redis集群，用于HydraCache缓存系统的分布式缓存。
* Redis缓存：使用Redis缓存关键数据，提高系统的读取速度。
* LocalCache: 一个本地的缓存系统，此处有一个局部性假设，认为同一个客户端最有可能访问它put的数据，实现常用的LRU和LFU等缓存策略。

HBase集群的搭建

本系统由于处于实验阶段，并且没有真是的分布式环境，所以使用Docker在本机大家一个分布式HBase环境。Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。相比传统的虚拟机，Docker更加的节省资源，在一台普通的机器上启动多个容器，基本上没有压力，因此在单机上使用Docker搭建HBase分布式集群可以比较真实地模拟真实的分布式集群。
本系统实现的基于Docker的分布式集群，具有下面的特性：
* 使用serf和dnsmasq 作为集群节点管理和dns解析
* 可以自定义集群hadoop和hba