HMaster 、 kafka 等无主结构并不是自我实现的选举， 而是基于 ZooKeeper 的选举策略决策出新的 master
HBase 创建表的 Region 极大的影响插入等性能
HFile写入的时候，是分一个块一个块的写入的，每个Block块64KB左右，这样有利于数据的随机访问，不利于连续访问，连续访问需求大的，可以把Block块的大小设置得大一点。
hbase在写入数据之前会先写入MemStore，成功了再写入HLog，
每当 MemStore 写入数据的时候就会 lock() 写成功后 finally{ unlock() } 那么此时数据就无法被访问了吗？ NONONO 事实上是是 会将数据 copy 到快照 中 snapshot。这个时间很短，复制完就可以访问这个 KVset， 实际 flush 时候，是吧 快照中的 KVset 给Flush 掉了。
过程写得比较凌乱了，把之前的总结一下吧：
1、做准备工作，实例化变量
2、检查Put和Delete里面的列族是否和Region持有的列族的定义相同。
3、给Row加锁，先计算hash值做key，如果该key没上过锁，就上一把锁，然后计算出来要写的action有多少个，记录到numReadyToWrite。
4、更新时间戳，把该action里面的所有的kv的时间戳更新为最新的时间戳，它这里也会把之前的没运行的也一起更新。
5、给该region加锁，这个时间点之后，就不允许读了，等待时间需要根据numReadyToWrite的数量来计算。
6、上锁之后，下面就是重头戏了，也就是Put、Delete等的重点。给这些写入memstore的数据创建一个批次号。
7、把kv们写入到memstore当中，然后计算出来一个添加数据之后的新的MemStore的大小addedSize。
8、把kv添加到日志当中，标志状态为成功，如果是用户设置了不写入日志的，它就不写入日志了。
9、先异步添加日志。
10、释放之前创建的锁。
11、同步日志。
12、结束该批次的操作。
Final、同步日志没成功的，最后根据批次回滚MemStore中的操作。
Put和Delete操作就没区别吗，那它怎么删除数据的？
返回在第4步更新时间戳的时候，发现了一些猫腻，Delete的情况执行了prepareDeleteTimestamps方法，看看吧。先判断是否是最新的时间戳，只传了rowkey进去的，它就是最新的，Delete的构造函数：凡是在这个时间点之前的所有版本的所有列，我们都要删除。这里干了一个Get操作，，把列族的多个版本的内容取出来，如果数量不符合预期也会有问题
只有在Compaction之后，hbase的文件才会变小，那在删除之前，我们进行Get或者Scan操作的时候，会不会读到这些没有被删除的数据呢？