HBase 默认强一致，为什么副本读可能读到旧值？Timeline 读怎么选？
面试怎么回答
HBase默认STRONG读走主Region副本，Timeline模式在配置Region副本后允许从跟随副本返回，因此可能看到旧值。它提高部分故障和慢响应下的读可用性，但不保证连续读绝不回退。isStale标记能提示是否来自次副本，不代表精确落后多久。选择时按业务是否容忍旧值分级，也不能把单行强一致理解成整个Scan的事务快照。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
刚把某个用户标签更新，随后查询却偶尔返回旧标签。大家都记得“HBase是强一致”，于是怀疑写入没有成功。但如果这次读明确允许Timeline副本，问题就要换一种解释。
STRONG与TIMELINE的读保证不同；允许副本旧值要有业务依据，单行保证也不能扩大为全表快照。
先确认讨论的是哪一种副本
HBase的Region副本与HDFS的数据块副本不是一回事。文件有多个副本，并不等于应用自动获得多个可按任意一致性访问的Region服务端。
Region读副本机制中，主副本负责接收写入，次副本跟随更新并服务允许的读取。传播存在时间差，因此某个次副本可能暂时没有最新变更。
本文依据HBase官方参考手册讨论机制，具体客户端、服务端版本和连接层封装需要核对部署环境，不能仅根据一段查询SQL推断实际读模式。
默认强一致与允许旧值读取不同
STRONG是默认读一致性模式，读取主Region副本。不能因为表配置了Region副本，就认为所有读都会自动切成Timeline。
TIMELINE允许客户端在相应机制下读取次副本，提高部分主副本响应慢或不可用时的读取机会，但结果可能落后。
这是明确的语义取舍，而不是HBase随机违反承诺。排查时应检查请求设置、客户端包装和表副本配置，不要只凭产品名称判断一致性。
“可能旧”还包括连续读取的变化
次副本之间进度不一定相同。如果前一次读到较新的副本，后一次读到落后的副本，应用可能观察到值回退，不能自动假设读序列始终单调向前。
Result.isStale可以帮助判断返回是否来自次副本，但它不是“这份数据落后了三秒”的证明，也不代表该值必然与当前主副本不同。
若业务需要量化新鲜度，应结合业务版本或更新时间等可验证信息，同时注意时间戳本身的可靠性。不能拿一个布尔来源标志替代完整延迟监控。
一个典型场景：写成功后页面短暂显示旧标签
假设用户标签更新成功，展示接口偶尔返回旧标签。第一反应是写入丢失，团队反复重试写入，页面却仍有短时波动。
排查将写入结果与读取来源对应，发现展示接口为了降低尾延迟启用了Timeline，部分请求命中进度较慢的次副本。旧检查只验证写入成功，没有记录读取一致性和返回来源。
修正先明确产品是否容忍短暂旧值。对于要求读己之写的路径，可以按需要使用强一致读取或设计明确的版本核验与回退策略；其他展示路径仍可保留容忍旧值的选择。
这不是让所有请求一律改成某一种模式，而是把不同场景的承诺拆开，避免同一个接口名称隐藏两套语义。
关键决策不能只看平均延迟收益
推荐展示、非关键画像预览可能容忍有限旧值，但权限变更、余额判断或其他关键操作需要更严格分析，不能为了毫秒级收益默认放宽读取保证。
即使用STRONG读，如果外部缓存仍保存旧值，最终用户看到的也可能旧。端到端新鲜度还取决于缓存、数据加工和应用逻辑，不能只改HBase参数就宣布问题消失。
读副本主要改善读可用性，不代表写入变成多主写或自动跨节点任意写。主副本写路径仍然需要独立考虑故障与恢复。
强一致也不是全表同一时刻快照
单行读取或操作的保证，不能无条件扩大为跨多行扫描的事务快照。长时间Scan期间其他行可以发生变化，业务一致性要求需要额外设计版本或快照边界。
验收应分别覆盖正常写后读、主副本慢响应、次副本落后、连续读和外部缓存路径。对允许旧值的接口，要明示适用范围并观察实际版本差异。
面试回答的关键，是让一致性描述对应具体操作与配置，而不是笼统说某个系统“强一致”后就跳过所有边界。