HBase多Region副本：用主从分离换取读高可用，代价是从副本可能读到脏数据

在HBase以前的实现里，一个Region只由一台RegionServer管理，一旦这台RegionServer不可用，需要数十秒甚至数分钟才能完成故障发现和Region接管，在这段时间窗口内，这个Region上的数据完全不可读写。HBase 1.0引入的多Region副本机制解决了这个可用性问题：一个Region可以有多个副本，分布在多台不同的RegionServer上，其中一个是主Region、其余是从Region——只有主Region接收写请求、并把数据持久化到HDFS上；从Region则从HDFS里读取数据来对外提供读服务，读操作既可以只读主Region，也可以配置成主从都可以读。这个设计换来的直接好处是：一旦主Region所在的RegionServer不可用，用户依然可以立刻转向读取从Region上的数据，不用再等待数十秒到数分钟的故障发现和接管过程。但这份高可用能力是有明确代价的：从Region读到的数据可能是脏数据（stale data）——因为从Region是从HDFS异步同步数据的，主Region内存中最新的写入结果，未必已经同步到从Region所依赖的HDFS存储上，所以只有读主Region才能保证拿到真正最新的数据；一旦选择读从Region来换取可用性，就必须同时接受读到的数据可能滞后于真实最新状态这个代价——这两者是绑定在一起、不能兼得的：只读从Region并不能”顺便”避免脏读问题，因为从Region的数据定义上就是过时的，脏读问题的根源不在”读哪个副本”，而在于从Region本身天然滞后于主Region这个事实。这个案例是CAP权衡的一个具体、直观的例子：面对RegionServer故障这类不可避免的场景，系统只能在”始终读到最新数据但可能因为主节点故障而暂时不可用”和”始终能读到数据但可能不是最新的”之间二选一，HBase的多Region副本机制把这个选择权交给了使用方（可配置只读主还是主从都可读），而不是替业务单方面决定该如何取舍。