MySQL是大型架构的核心，下面我重点详解MySQL主从模式@mikechen
MySQL主从
MySQL 主从复制（Replication）用于在多台数据库实例间复制数据，以实现高可用、读写分离与备份。
根据确认从库接收并应用事务的方式，复制可分为异步、半同步与全同步三种主要模式。
MySQL异步复制
异步复制是 MySQL 传统默认的复制方式。
主库在事务提交后立即返回客户端，而不等待从库接收或应用该事务。
从库通过 I/O 线程从主库的二进制日志（binlog）读取事件，并由 SQL 线程在本地执行。
优点：
延迟最小：主库提交速度快，不受从库影响。
实现简单、性能开销小，适合写密集型场景。
缺点：
数据丢失风险：主库故障时，已提交但尚未复制到从库的事务会丢失。
无法保证强一致性。
适用场景：对延迟敏感、可容忍一定数据丢失的系统，如大多数 OLTP 应用的读扩展。
MySQL半同步复制
半同步复制：主库在提交后，至少等待一个从库确认已接收到 binlog（即写入从库的中继日志或内存缓冲）。
然后才向客户端返回，但不等待从库执行完成。
优点：
降低数据丢失风险：至少保证 binlog 到达某个从库，主库崩溃时可从该从库恢复大部分数据。
在可接受范围内提高一致性保证，仍较异步复制延迟低。
缺点：
增加主库提交延迟：受网络与从库响应影响。
如果配置不当（如同步从库失败），可能导致主库阻塞或性能下降。
适用场景：对数据可靠性有一定要求、但不能完全接受全同步开销的场合，如金融类次级系统或对关键写操作需更高保障的业务。
MySQL全同步复制
全同步复制：要求主库在事务提交前。
等待所有或指定数量的从库确认已接收并应用该事务，从而在多个节点间实现严格的同步提交。
优点：
强一致性：多个节点间数据保持同步，主节点故障时较少或无数据丢失。
自动故障切换与群集管理（视具体实现）。
缺点：
性能开销大：同步等待导致写操作延迟显著增加，网络拓扑影响更明显。
实现复杂：需要额外组件、配置与运维成本，且在高延迟网络环境下扩展性受限。
适用场景：对数据一致性与零丢失有强烈要求的关键业务，如金融交易系统、核心账务系统或需要严格主备一致性的应用。
