我的职业生涯变化不大，都是在一家公司里辗转。
06年，我加入淘宝交易组。主要负责淘宝网商品，交易，类目属性相关的业务开发工作。当时淘宝只有两个组，一个交易，一个会员。
08年，我从业务团队转岗到了平台架构。然后跟着 bluedavy 和 oasisfeng 一起开发了淘宝网分布式元信息存储中间件，这让我的个人技术能力得到很大的提升。
11年，也就是今年，是我在淘宝满5年。我决定重新回归业务团队，以我5年的经验，去做好一个“产品研发工程师”。并准备好面对将来的各种苦难。
在这里，需要感谢淘宝Java中间件团队，感谢黎叔和老毕多年来的照顾。
Arena Allocation，是一种GC优化技术，它可以有效地减少因内存碎片导致的Full GC，从而提高系统的整体性能。本文介绍Arena Allocation的原理及其在Hbase中的应用-MSLAB。
假设有1G内存，我顺序创建了1百万个对象，每个对象大小1K，Heap会被渐渐充满且每个对象以创建顺序相邻。此时，如果我释放50万个奇数对象，即 1 3 5 7后，剩余空间会多出500M，而这段内存空间就不再连续了。问题出现？
如果我打算new一个2K大小的对象，JVM将无从分配它，因为找不到连续可用的内存空间来容纳这个对象，就算Heap当时还有500M的剩余空间，也无能为力。最终，JVM会选择触发Full GC重新压缩内存使之连续，然后再分配。
结论：触发Full GC，并不只有在内存满或达到触发比例的时候，还有可能是因为内存碎片。
产生内存碎片的主要原因是：
因官方Book Performance Tuning部分章节没有按配置项进行索引，不能达到快速查阅的效果。所以我以配置项驱动，重新整理了原文，并补充一些自己的理解，如有错误，欢迎指正。
zookeeper.session.timeout
默认值：3分钟（180000ms）
说明：RegionServer与Zookeeper间的连接超时时间。当超时时间到后，ReigonServer会被Zookeeper从RS集群清单中移除，HMaster收到移除通知后，会对这台server负责的regions重新balance，让其他存活的RegionServer接管.
调优：
这个timeout决定了RegionServer是否能够及时的failover。设置成1分钟或更低，可以减少因等待超时而被延长的failover时间。
不过需要注意的是，对于一些Online应用，RegionServer从宕机到恢复时间本身就很短的（网络闪断，crash等故障，运维可快速介入），如果调低timeout时间，反而会得不偿失。因为当ReigonServer被正式从RS集群中移除时，HMaster就开始做balance了（让其他RS根据故障机器记录的WAL日志进行恢复）。当故障的RS在人工介入恢复后，这个balance动作是毫无意义的，反而会使负载不均匀，给RS带来更多负担。特别是那些固定分配regions的场景。
二级索引与索引Join是Online业务系统要求存储引擎提供的基本特性。RDBMS支持得比较好，NOSQL阵营也在摸索着符合自身特点的最佳解决方案。
这篇文章会以HBase做为对象来探讨如何基于Hbase构建二级索引与实现索引join。文末同时会列出目前已知的包括0.19.3版secondary index,?ITHbase, Facebook和官方Coprocessor方案的介绍。
理论目标
在HBase中实现二级索引与索引Join需要考虑三个目标：
1，高性能的范围检索。
2，数据的低冗余（存储所占的数据量）。
3，数据的一致性。
性能与数据冗余，一致性是相互制约的关系。
如果想实现了高性能地范围检索，必然需要依赖冗余索引数据来提升性能，而数据冗余会导致更新数据时难以实现一致性，特别是分布式场景下。
如果对范围检索的性能要求不高，那么可以不考虑冗余数据，一致性问题也可以间接避免，毕竟share nothing是公认的最简单有效的解决方案。
理论结合实际，下文会以实例的方式来阐述各个方案是如何选择偏重点。
这些方案是经过笔者资料查阅和同事的不断交流后得出的结论，如有错误，欢迎指正：
| Cassandra | HBase | |
| 一致性 | Quorum NRW策略
通过Gossip协议同步Merkle Tree，维护集群节点间的数据一致性 |
单节点，无复制，强一致性 |
| 可用性 | 1，基于Consistent Hash相邻节点复制数据，数据存在于多个节点，无单点故障。
2，某节点宕机，hash到该节点的新数据自动路由到下一节点做 hinted handoff，源节点恢复后，推送回源节点。 3，通过Gossip协议维护集群所有节点的健康状态，并发送同步请求，维护数据一致性。 4，SSTable，纯文件，单机可靠性一般。 |
1，存在单点故障，Region Server宕机后，短时间内该server维护的region无法访问，等待failover生效。
2，通过Master维护各Region Server健康状况和Region分布。 3，多个Master，Master宕机有zookeeper的paxos投票机制选取下一任Master。Master就算全宕机，也不影响Region读写。Master仅充当一个自动运维角色。 4，HDFS为分布式存储引擎，一备三，高可靠，0数据丢失。 5，HDFS的namenode是一个SPOF。 |
| 伸缩性 | 1，Consistent Hash，快速定位数据所在节点。
2，扩容需在Hash Ring上多个节点间调整数据分布。 |
1，通过Zookeeper定位目标Region Server，最后定位Region。
2，Region Server扩容，通过将自身发布到Master，Master均匀分布。 |
| 负载均
衡 |
请求Zookeeper取得整个集群地址，然后根据Consistent Hash选择合适的节点。client会缓存集群地址。 | 请求Zookeeper取读写数据路由表定位Region Server，Master会修改这个路由表。Client自身也会缓存一部分路由信息。
如果Key的第一部分是时间或者序列数，所有新的Key都会被插入同一个区域,一直到此区域被塞满。此处存在热点问题。 |
| 数据差异比较算法 | Merkle Tree , Bloom Filter | Bloom Filter |
| 锁与事务 | Client Timestap（Dynamo使用vector lock） | Optimistic Concurrency Control |
| 读写性能 | 数据读写定位非常快。 | 数据读写定位可能要通过最多6次的网络RPC，性能较低。 |
| 可维护性 | 架构无中心化，维护成本低。
新增keyspace需要重启整个集群。 |
组件过多，架构复杂，维护成本较高。
删除表非常方便。 |
| 列排序 | 支持 | 不支持 |
| map/reduce | 支持不是很好 | 源生支持 |
| 访问接口 | Thrift | 多种，包括Thrift |
| 点评 | 1，弱一致性，数据可能丢失。
2，可用性高。 3，扩容方便。 4，如果不需要map/reduce的话，维护相当简单。 |
1，强一致性，0数据丢失。
2，可用性低。 3，扩容方便。 4，组件过多，架构复杂，维护成本较高。 |
参考资料
Dynamo: Amazon’s Highly Available Key-value Store
HBase Reference
NoSQL Databases: Why, what and when
解读NoSQL技术代表之作Dynamo
NOSQL数据库笔谈
Dynamo学习
所有包含Heap Profling功能的工具（MAT, Yourkit, JProfiler, TPTP等）都会使用到两个名词，一个是Shallow Size，另一个是 Retained Size.
这是两个在平时不太常见的名词，本文会对这两个名词做一个详细的解释。
Shallow Size
对象自身占用的内存大小，不包括它引用的对象。
针对非数组类型的对象，它的大小就是对象与它所有的成员变量大小的总和。当然这里面还会包括一些java语言特性的数据存储单元。
针对数组类型的对象，它的大小是数组元素对象的大小总和。
Retained Size
Retained Size=当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C, C就是间接引用)
换句话说，Retained Size就是当前对象被GC后，从Heap上总共能释放掉的内存。
不过，释放的时候还要排除被GC Roots直接或间接引用的对象。他们暂时不会被被当做Garbage。
看图理解Retained Size
上图中，GC Roots直接引用了A和B两个对象。
A对象的Retained Size=A对象的Shallow Size
B对象的Retained Size=B对象的Shallow Size + C对象的Shallow Size
这里不包括D对象，因为D对象被GC Roots直接引用。
如果GC Roots不引用D对象呢？
此时,
B对象的Retained Size=B对象的Shallow Size + C对象的Shallow Size + D对象的Shallow Size
