ITPub博客

这篇分析一下LeaseRecovery和BlockRecoveryhdfs支持hflush后，需要保证hflush的数据被读到，datanode重启不能简单的丢弃文件的最后一个block，而是需要保留下hflush的数据。同时为了支持append，需要将已经finalized的block重新打开追加

这篇分析一下namenode写editlog的过程。关于namenode日志,集群做了如下配置<property><name>dfs.nameservices</name><value>sync</value><description

HDFS的hflush,hsync和close有啥区别，分别做了什么hflush:语义是保证flush的数据被新的reader读到，但是不保证数据被datanode持久化.hsync:与hflush几乎一样，不同的是hsync保证数据被datanode持久化。close:关闭文件.除了做到以上2点，

上一篇说了datanode端如何处理pipeline写请求的，这里主要看DFSClient。这里以append为例,write差不多。创建一个pipeline用于append操作的流程:FileSystem.get(configuration)返回一个已经初始化完成的DistributedFileS

站在DataNode的视角，看看pipeline写的流程，本文不分析客户端部分，从客户端写数据之前拿到了3个可写的block位置说起。每个datanode会创建一个线程DataXceiverServer，接收上游过来的TCP连接，对于每个新建的TCP连接,都会创建一个叫做DataXceiver的线程

HBaseCompaction策略RegionServer这种类LSM存储引擎需要不断的进行Compaction来减少磁盘上数据文件的个数和删除无用的数据从而保证读性能。RegionServer后台有一组负责flushregion的线程(MemStoreFlusher)，每次从flushQueue中

分裂策略不同的分裂策略的实现需要继承RegionSplitPolicy，主要实现两个方法：shouldSplit()表示是否需要分裂getSplitPoint()得到分裂点rowkey从HBase0.94之后，默认的分裂策略是IncreasingToUpperBoundRegionSplitPoli

HBaseScan流程分析HBase的读流程目前看来比较复杂，主要由于：HBase的表数据分为多个层次,HRegion->HStore->[HFile,HFile,...,MemStore]RegionServer的LSM-Like存储引擎，不断flush产生新的HFile，同时产生新的

HBase从0.95开始引入了Snapshot，可以对table进行Snapshot，也可以Restore到Snapshot。Snapshot可以在线做，也可以离线做。Snapshot的实现不涉及到table实际数据的拷贝，仅仅拷贝一些元数据，比如组成table的regioninfo，表的descr

HBase可以根据当前集群的负载以region为单位进行rebalance。在HMaster中，后台会起一个线程定期检查是否需要进行rebalance，线程叫做BalancerChore。线程每隔hbase.balancer.period会定期执行master.balance()函数，配置项默认30

MVCC是实现高性能数据库的关键技术，主要为了读不影响写。几乎所有数据库系统都用这技术，比如Spanner，看这里。Percolator，看这里。当然还有mysql。本文说HBase的MVCC和0.98引入的新写线程模型。HBaseregionserver的存储模型类LSM，将随机写转换为顺序写，写

本文分析RegionServer宕机后这个regionserver上的region是如何在其他regionserver上恢复的。regionserver宕机后发生了什么HMaster有一个RegionServerTracker对象，监控zk上/hbase/rs目录下的结点，达到监控regionser

Google为了解决网页索引的增量处理，以及维护数据表和索引表的一致性问题，基于BigTable实现了一个支持分布式事务的存储系统。这里重点讨论这个系统的分布式事务实现，不讨论percolator中为了支持增量计算而实现的Notifications机制。该系统基于BigTable，支持snapsho

Spanner要满足的externalconsistency是指：后开始的事务一定可以看到先提交的事务的修改。所有事务的读写都加锁可以解决这个问题，缺点是性能较差。特别是对于一些workload中只读事务占比较大的系统来说不可接受。为了让只读事务不加任何锁，需要引入多版本。在单机系统中，维护一个递增

RedisCluster是Redis的集群实现，内置数据自动分片机制，集群内部将所有的key映射到16384个Slot中，集群中的每个RedisInstance负责其中的一部分的Slot的读写。集群客户端连接集群中任一RedisInstance即可发送命令，当RedisInstance收到自己不负责

twemproxy是twitter开源的redis/memcached代理，数据分片提供取模，一致性哈希等手段，维护和后端server的长连接，自动踢除server,恢复server，提供专门的状态监控端口供外部工具获取状态监控信息。代码写的比较漂亮，学习了一些Nginx的东西，比如每个请求的处理分

一致性问题要求多个process对一个值达成一致。基于消息传递的分布式系统中，在不考虑消息篡改等拜占庭错误的情况下，Paxos可以解决在进程退出，消息延迟，丢失，重复等异常发生的环境中对某个值达成一致的问题。考虑Paxos最基本的形式：两个角色：Proposer和Acceptor，Proposer提

UpdateServer(UPS)是OceanBase的写入单点，一个集群中只有一台UPS服务器，所有的写都写入到这台机器。OceanBase采用基于静动态数据分离的机制，静态数据存储在静态数据服务器ChunkServer(CS)磁盘上，动态数据存储在UPS的内存中，导致一次读请求需要将静态和动态数

线程是内核对外提供的服务，应用程序可以通过系统调用让内核启动线程，由内核来负责线程调度和切换。线程在等待IO操作时线程变为unrunnable状态会触发上下文切换。现代操作系统一般都采用抢占式调度，上下文切换一般发生在时钟中断和系统调用返回前，调度器计算当前线程的时间片，如果需要切换就从运行队列中选

在并发写Btree原理剖析一文中提到，节点内存回收有可能导致内存突增以及影响写性能。本文将阐述最近对内存回收的改进，多线程可并行回收内存。回收策略采用基于版本的机制，Btree全局维护一个版本号V，一个全局数组A，每个线程一个槽位，每个线程读写操作之前获取全局版本号V，记作V0，并且记录到全局数组A