主从复制（Replication）的原理是什么？有哪些复制模式（异步、半同步、同步）？各自的优缺点？

主从复制（Replication）是数据库集群中实现数据同步的核心技术，主要用于读写分离、数据备份、故障恢复等场景。其核心思想是：主库（Master）处理写操作并记录数据变更，从库（Slave）通过复制主库的变更日志，重演这些操作以保持与主库的数据一致。

一、主从复制的基本原理

主从复制的核心流程可分为3个关键步骤（以MySQL为例，其他数据库如PostgreSQL原理类似）：

1. 主库记录变更日志（binlog）
   主库执行写操作（增删改）后，会将操作逻辑记录到二进制日志（binlog）中。binlog是主从复制的“数据源”，包含了所有数据变更的详细信息（如SQL语句或行级变更）。

2. 从库获取主库的binlog
   从库启动后，会创建一个IO线程，连接主库并请求同步binlog。主库则会创建一个binlog dump线程，将binlog的内容（从指定位置开始）发送给从库的IO线程。
   从库的IO线程将收到的binlog数据写入本地的中继日志（relay log）（中继日志是binlog的“副本”，避免直接操作binlog导致冲突）。

3. 从库重演变更
   从库的SQL线程会实时解析中继日志，按照顺序执行其中的操作（与主库执行的逻辑一致），最终使从库的数据与主库保持同步。

二、复制模式及优缺点

根据主库等待从库确认的“同步程度”，主从复制可分为异步复制、半同步复制、同步复制三种模式，核心区别在于“主库完成事务后，是否等待从库同步完成再返回给客户端”。

1. 异步复制（Asynchronous Replication）

原理：
主库执行完事务后，立即向客户端返回成功，无需等待从库接收或处理binlog。binlog的同步完全由从库异步拉取，主库不感知从库的状态。

优点：

• 性能最优：主库无需等待从库，写操作响应速度快，不会被从库的延迟拖累。
• 部署简单：是多数数据库（如MySQL、PostgreSQL）的默认复制模式，无需额外配置。

缺点：

• 数据安全性低：若主库突发宕机，可能存在未同步到从库的binlog（即主库已提交的事务，从库尚未收到），导致数据丢失。
• 从库可能存在较大延迟：若主库写入频繁，从库IO线程或SQL线程处理不及时，会导致主从数据不一致的时间窗口变大。

2. 半同步复制（Semi-synchronous Replication）

原理：
主库执行完事务后，不会立即返回客户端，而是等待至少一个从库的IO线程将binlog写入中继日志（relay log）并返回确认后，才向客户端返回成功。
（注：仅需从库“接收并写入中继日志”，无需等待从库的SQL线程执行完成。）

优点：

• 数据安全性高于异步：主库宕机时，至少有一个从库已收到完整的binlog，大幅降低数据丢失风险。
• 性能损耗可控：仅需等待一个从库的确认（而非全部），相比同步复制延迟更低。

缺点：

• 主库响应延迟增加：需等待从库的确认，写操作耗时比异步更长（取决于主从网络延迟）。
• 存在降级风险：若从库长期未返回确认（如网络故障），主库会自动降级为异步复制，此时可能再次出现数据丢失。
• 从库仍可能有逻辑延迟：从库虽收到binlog，但SQL线程可能未执行，导致主从数据仍有短暂不一致（但binlog已安全保存，无丢失风险）。

3. 同步复制（Synchronous Replication）

原理：
主库执行完事务后，必须等待所有从库的SQL线程执行完该事务并返回确认后，才向客户端返回成功。主从数据实时完全一致。

优点：

• 数据安全性最高：理论上无数据丢失风险，主从数据完全同步。

缺点：

• 性能极差：主库需等待所有从库执行完事务，写操作延迟与从库数量、性能、网络延迟强相关（从库越多/越慢，主库阻塞越久）。
• 可用性低：若任一从库故障（如宕机、网络中断），主库会一直阻塞，无法处理写操作。

适用场景：极少用于生产环境，仅在对数据一致性要求极高（如金融核心交易的最终确认）且并发量极低的场景使用。

总结

复制模式	核心特点	优点	缺点	适用场景
异步复制	主库不等待从库确认	性能最优，部署简单	可能数据丢失	读写分离、非核心业务
半同步复制	主库等待至少一个从库接收binlog	数据安全性较高，性能折中	延迟增加，可能降级	核心业务（如订单、支付）
同步复制	主库等待所有从库执行完事务	数据零丢失	性能极差，可用性低	极高一致性要求（如金融对账）

实际生产中，半同步复制是平衡安全性和性能的主流选择，异步复制常用于非核心场景，同步复制则因性能问题极少使用。