HBase读写分离：把离线任务的压力隔离在从库，避免拖慢线上响应

主题推荐结果表要满足两个存储特性——按用户ID做KV查询、并且要保留一定时间内的历史推荐版本，这两个特点让HBase的KV和多版本能力恰好对上，成为了合适的选型。但选定存储引擎只是第一步，真正影响生产稳定性的是围绕这个选型做的架构设计：团队采用了HBase主从方式做读写分离，背后有两个明确的理由。第一个理由和CAP理论直接相关：HBase在CAP权衡中选择了牺牲可用性来保证强一致性，flush、split、compaction这些内部维护操作，以及检测Region Server宕机、恢复Region这些故障处理过程，都会造成对应数据在这段时间内不可用——这是HBase架构本身带来的固有代价，读写分离不能消除这个代价，但可以把它的影响范围限定在特定副本上，而不让所有流量都暴露在这个风险窗口里。第二个理由是负载隔离：批处理层（离线任务）往往涉及大量读写，这类操作会给Region Server带来显著的GC、网络、flush、compaction压力，如果离线任务和线上实时查询共用同一批Region Server，离线任务的压力会直接拖慢前端的响应速度——用主从分离把离线任务的读写压力隔离在从库，主库专注服务对延迟敏感的线上查询，两者互不干扰。这个案例给出了一条存储架构设计的通用原则：选定一个存储引擎之后，还要主动识别这个引擎在CAP权衡上做出的取舍会在什么场景下暴露出问题（这里是可用性窗口），以及不同类型的负载（离线批量 vs 在线实时）会不会互相争抢同一份资源；针对这两类问题，读写分离/主从分离是一个常见但需要主动设计才能落地的应对手段，不会因为选对了存储引擎就自动获得。