GBase 8s数据库高可用之—RHAC远程高可用集群详解
《GBase 8s 高可用四部曲》第一部讲了 HAC 同城守护——主备双机，秒级切换。但同城容灾有个致命软肋：火灾、地震、海啸一来，同城机房可能一锅端。这时候你需要一张异地保险单。RHAC 就是 GBase 8s 的千里分身术：主节点在广东，辅节点可以放到江苏、浙江、湖北甚至内蒙——相距几百上千公里，数据照样同步，业务照样接力。
异步为王：对主节点零负担
RHAC 跟 HAC 最大的区别，一言以蔽之：HAC 守同城，RHAC 走千里；HAC 三种同步模式随便选，RHAC 只认异步一条路。
为什么只走异步？因为距离太远，等确认再提交太慢了。RHAC 采用SMX 异步通信框架，对主服务器的影响降到最小——主节点只管发日志，不等待 RHAC 的确认信息，全双工模式下发送线程不等上一个确认就直接发下一个缓冲区，性能损耗极低。
换句话说，主节点几乎感知不到 RHAC 的存在，就像给数据库上了一份"异地自动续保"——保费（性能损耗）极低，保额（容灾能力）极高。
可读可分担：不只是"冷备份"
RHAC 辅节点不是摆设——它可读，能承担部分查询业务，分担主节点读压力。配合连接管理器做负载均衡，查询流量可以分散到辅节点，主节点专心扛写入。
而且 RHAC 对带宽要求低，普通广域网就能跑，不用专门拉光纤，省钱省力。它能扛住的灾备场景相当硬核：服务器软件故障、硬件故障、火灾、地震、海啸——同城机房防不住的，RHAC 顶上。
RHAC 的"规矩"：两个不支持
能力强大，但也有边界。RHAC 有两个"不支持"，用的时候心里要有数：
- 不支持同步模式：只走异步，数据同步有微小延迟，不适合要求强一致性的金融交易场景
- 不支持同步检查点：主节点不会等 RHAC 确认检查点，故障切换时可能有少量数据需手动处理
所以 RHAC 的定位很清晰：异地容灾的最后一道防线，不是实时双活，而是"大难不死"的备份方案。和 HAC 搭配使用——HAC 守同城秒切，RHAC 守异地保命，两者互补才完整。
RHAC 把容灾半径从同城拉到了千里之外，但异地备份只是高可用的一块拼图。如果业务要求多个节点同时读写同一份数据，强一致还不能丢，架构还能怎么进化？