MySQL是大型架构的核心，我重点详解MySQL高可用@mikechen
主从复制
MySQL主从复制，通过 Binlog (二进制日志) 实现数据的同步：
Binlog (主库)： 主库将所有数据更改写入 Binlog。
I/O Thread (从库)： 从库上的 I/O 线程连接到主库，请求并接收 Binlog Event，将其写入从库的 Relay Log（中继日志）。
SQL Thread (从库)： 从库上的 SQL 线程读取 Relay Log，并按顺序执行其中的事件，从而将数据应用到从库。
主库负责写操作，将二进制日志（binlog）复制到一个或多个从库，从库执行重放以保持数据同步。
优势：实现简单、读写分离、易于扩展读能力。
局限：主库单点故障风险；主从延迟可能导致读到旧数据。
主主复制
主主复制，是主从复制的一种变体。
原理：两台、或多台节点互相复制，既能读又能写。
(写/读) <——————> (写/读) [Master A] ↔ [Master B]
优势：提高写入可用性，支持自动切换。
局限：冲突处理复杂（写冲突、自增主键冲突），需严格配置以避免数据不一致。
半同步复制
半同步复制，是主从复制在数据安全上的关键升级，弥补了异步复制数据丢失的缺陷。
在主库提交事务后，至少等待一个从库确认接收（但不一定应用）后才返回成功给客户端。
优势：减少主库提交即丢失数据的风险，提高数据安全性。
局限：增加写延迟，需权衡延迟与安全。
MHA
通过监控与自动切换脚本，检测主库故障，自动选择合适从库提升为主库并执行重定位。
MHA 由两部分组成：
MHA Manager： 运行在独立机器上，负责监控集群状态、发现故障、执行故障切换和协调整个过程。
MHA Node Agent： 运行在每个 MySQL 服务器上，负责收集 Binlog、执行切换时所需的特定命令等。
[ MHA Manager ]
|
---------------------------------
| |
[Master] <——> [Slave1] [Slave2]
优势：切换快速、自动化程度高、兼容主从体系。
局限：对复杂拓扑和延迟场景需谨慎，需额外运维与测试。
mikechen睿哥
10年+一线大厂架构实战专家，就职于阿里、淘宝等一线大厂，操盘多个亿级大厂核心项目。