HBase随机读性能不足以支撑在线缓存服务，应改用专用缓存组件

面对”要给在线服务设计缓存该怎么做”这类问题，一个容易走偏的方向是想当然地依赖已经在用的HBase来承担这个缓存职责——但明确的判断是：HBase的随机读性能不足以支撑在线服务对缓存的性能要求，真正应该用Redis或者Memcache这类专门为低延迟随机访问设计的组件来承担缓存职责，而不是让HBase去兼任这个角色。这个判断背后的原因和HBase自身的架构特点密切相关：HBase基于LSM-tree架构，数据写入时先进内存、再定期刷写到磁盘、还需要经过Compaction等后台整理过程，这类设计更适合支撑高吞吐的写入和范围查询，但单次随机读的延迟特征天然不如专门为纯内存、极简数据结构优化的Redis/Memcache这类组件；而且对于一个繁忙的HBase集群来说，本身的CPU开销就已经比较可观，如果再叠加大量本不属于它擅长范围的缓存类随机读流量，只会进一步加剧资源紧张。这个案例给出了一条技术选型的重要提醒：不能因为某个组件已经在架构里存在、用起来”顺手”，就把它拿来承担一个和它设计初衷不完全匹配的新职责——HBase被设计出来主要是为了解决海量结构化数据的可扩展存储和范围查询问题，而不是为了解决”毫秒级随机访问的高频缓存”这类问题；即使HBase技术上确实能够被用来实现某种缓存效果，这也不代表它是这个职责的合适载体，评估要不要用某个已有组件承担一项新职责时，应该回到这个组件本身的架构设计初衷和性能特征上去判断，而不是单纯因为”反正已经在用了、不用重新引入新组件”这个图省事的理由就草率决定。