一、高可用概述：为什么需要高可用、CAP理论与BASE理论、常见高可用架构模式
各位同学，咱们今天聊聊高可用。说实话，这个词在云上数据库的圈子里，几乎天天被挂在嘴边。但你真的理解它吗？
我记得刚入行那会儿，带我的老大哥跟我说过一句话：「数据库挂了，公司就挂了。」当时我还觉得夸张，直到后来自己亲手经历了一次生产事故——凌晨三点，核心库宕机，整个支付链路断了四十分钟。那四十分钟，我坐在机房里，看着监控面板上红色的告警，后背全是冷汗。嗯，从那以后，我对「高可用」这三个字，再也不敢有半点马虎。
1.1 为什么需要高可用？
说白了，高可用就是为了让系统在面对各种故障时，依然能对外提供服务。你想想看，现在的业务几乎都是7×24小时在线，用户可不管你是不是在维护、是不是硬盘坏了、是不是网络波动。他们只关心一件事：能不能用。
我在项目中遇到过最典型的场景：某次双十一大促，流量峰值是平时的20倍。如果数据库扛不住，那前端页面再花哨也没用。高可用不是锦上添花，它是雪中送炭。
具体来说，高可用要解决这几类问题：
- 硬件故障：磁盘坏了、内存坏了、网卡松了。这些事虽然概率低，但一旦发生就是灾难。
- 软件崩溃：数据库进程挂了、操作系统OOM了、驱动有bug。我见过最离谱的一次，是某个版本的MySQL在特定条件下自己把自己搞死了。
- 网络分区：机房光缆被挖断了、交换机挂了。云上环境虽然网络冗余做得不错，但也不是100%可靠。
- 人为误操作：这个最要命。我曾经手滑执行过一条
DROP TABLE，还好有备份，不然就真的凉了。
核心观点：高可用不是「不出故障」，而是「出了故障还能用」。衡量标准就是SLA，比如99.99%可用性，意味着一年宕机时间不能超过52.56分钟。
1.2 CAP理论与BASE理论
聊高可用，绕不开CAP。这个理论是分布式系统的基石，也是很多架构决策的出发点。
CAP说的是：一个分布式系统，在一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）这三者中，最多只能同时满足两个。
你可能会问：为什么不能三个都要？我打个比方你就明白了。假设你有两个数据库节点A和B，它们之间网络断了（分区发生了）。这时候客户端写了一条数据到A，但B不知道。如果客户端去读B，B该不该返回数据？
- 如果返回，那就是可用，但数据不一致（牺牲了C）。
- 如果不返回，那就是一致，但服务不可用（牺牲了A）。
你看，鱼和熊掌不可兼得。在实际的云上数据库架构中，我们通常选择AP或CP。比如MySQL主从复制，默认是AP模式——主库挂了，从库可能丢数据，但服务不会断。
| 组合 | 典型场景 | 代表产品 |
|---|---|---|
| CA | 单机数据库（无分区） | 单机MySQL |
| CP | 强一致性要求 | ZooKeeper、Etcd |
| AP | 高可用优先 | MySQL主从、Redis哨兵 |
再说说BASE理论。这个理论是对CAP的一种妥协和补充。BASE是Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）的缩写。
我个人习惯把BASE理解为「别太较真」。你不需要每时每刻都保证数据完全一致，只要最终能对上就行。比如你在淘宝下单，扣库存和生成订单这两个操作，不一定同时完成，但只要最终库存扣了、订单生成了，用户就满意了。
避坑指南：我曾经在一个金融项目中，试图用最终一致性来做账户余额扣减。结果发现不行——用户转完账，余额半天没变，投诉电话打爆了。所以，BASE不是万能的，对一致性要求高的场景，还是得走CP路线。
1.3 常见高可用架构模式
理论讲完了，咱们看看实战中怎么搭。常见的架构模式就那么几种，我一个个说。
1.3.1 主从复制模式
这是最基础的模式。一个主库负责写，多个从库负责读。主库挂了，手动或自动切一个从库上来。
优点：简单、成熟、成本低。
缺点：切换有延迟，可能丢数据。
我在项目中遇到过最头疼的事：主库突然宕机，从库的复制延迟还有几秒。这几秒的数据，就永远丢了。所以后来我养成了一个习惯——不管用哪种模式，一定要做数据备份。
1.3.2 双主互备模式
两个节点互为主从，都可以读写。这种模式的好处是，任何一个节点挂了，另一个还能继续服务。
但坑也不少。最常见的问题是数据冲突——两个节点同时修改同一条记录，怎么办？解决办法通常是让业务层做路由，或者用分布式ID生成器保证主键不冲突。
1.3.3 集群模式（如MySQL InnoDB Cluster、Galera）
多节点组成一个集群，数据实时同步。任何一个节点挂了，集群自动剔除它，客户端无感知。
这种模式的好处是高可用性极强，坏处是网络要求高。如果节点之间延迟太大，整个集群的性能会急剧下降。
1.3.4 云原生高可用（如RDS、PolarDB）
现在云上数据库基本都自带高可用方案。比如阿里云的PolarDB，底层是共享存储，计算节点挂了，存储层数据还在，秒级切换。
我个人建议：如果你不是特别有经验，直接用云上的托管服务。省心、稳定、出了问题有人背锅。当然，前提是你得理解它的原理，不然出了问题你连怎么排查都不知道。
警告：不管用哪种架构模式，一定要做故障演练。我曾经见过一个团队，架构搭得漂漂亮亮，结果真出故障了，切换脚本跑不通。演练不是走过场，是救命。
知识体系结构图
下面这张图，是我自己总结的高可用知识体系。你可以把它当作本章的思维导图。
好了，这一章的内容就到这里。高可用不是一蹴而就的事，它需要你在架构设计、运维流程、故障演练等多个维度持续投入。下一章咱们会深入聊聊具体的架构搭建细节，到时候见。
公众号:蓝海资料掘金营，微信deep3321