5.4 分布式数据库架构
内容提要
文章介绍分布式数据库架构：MySQL主从/主主复制可分摊读负载、提高可用性，但不增加写并发与存储能力，主主复制不能并发写，修改表结构易导致同步延迟。数据分片需额外代码，跨分片查询和事务难以实现。CAP原理指网络分区下一致性与可用性只能二选一。文中还涉及Cobar中间件、扩容部署、最终一致性冲突处理、HBase与Zookeeper，以及ACID与BASE的对比。
延伸解读
复制与分片解决的是不同层面的问题
文章把 MySQL 复制和数据分片放在同一章，但两者能力边界不同。主从复制主要分摊读负载、便于冷备并提升可用性，文中明确说它不增加写并发和存储能力；主主复制也不能并发写入。分片则试图突破单库存储与写入瓶颈，代价是需要大量额外代码，跨分片联合查询和数据库事务都难以执行。读者应先判断瓶颈在读、写还是存储，再选择手段。
CAP 的准确表述常被简化误读
文中强调，CAP 并不是三者永远只能选两个，而是在分布式系统必须保证分区耐受性的前提下，可用性和一致性无法同时满足。网络分区发生时，选择一致性可能返回错误或超时，选择可用性则可能返回过期数据。这一区分对理解后续最终一致性很关键：系统可用并不等于数据最新，冲突处理策略因此成为设计的一部分。
扩容路径体现先分库后分片的思路
文章给出的部署演进从单一服务与单一数据库，到主从复制实现伸缩，再到两个 Web 服务及两个数据库的业务分库，最后走向综合部署，并明确建议先业务分库、后做数据分片。这一顺序说明分片复杂度最高，不宜作为第一步。文中还讨论 Cobar 中间件、集群伸缩与扩容策略，提示扩容不只是加机器，还涉及路由与部署调整。
ACID 与 BASE 代表不同的取舍
文章将 ACID 与 BASE 对照：ACID 强调事务原子性、隔离性、持久性和一致性，隔离性主要依靠锁实现；BASE 则允许基本可用、弱状态和最终一致，接受副本同步存在延时。结合前文 CAP 与最终一致性冲突处理，可以看出分布式数据库往往在强一致与可用性之间做权衡，读者应结合业务对数据新鲜度的要求理解这些概念，而非简单判断优劣。
Q&A
MySQL主从复制能提升写并发能力吗？
不能。主从复制只是增加了数据的读并发处理能力，没有增加写并发能力和存储能力。
为什么主主复制不能同时写入两个数据库？
主主复制的两个数据库不能并发写入，否则会导致数据冲突或不一致。
数据分片有哪些主要挑战？
数据分片需要大量的额外代码，处理逻辑变得更复杂；无法执行多分片的联合查询；无法使用数据库的事务；随着数据增长，如何增加更多服务器也是挑战。
CAP原理中，为什么分区耐受性必须保证？
对于分布式系统而言，网络失效一定会发生，因此分区耐受性是必须要保证的。在必须满足分区耐受性的前提下，可用性和一致性无法同时满足，只能二选一。
最终一致性常见的写冲突处理策略有哪些？
简单冲突处理策略包括根据时间戳，最后写入覆盖；还有客户端冲突解决和投票解决冲突（如Cassandra）。
ACID和BASE的主要区别是什么？
ACID强调原子性、隔离性、持久性和一致性，要求强一致性；BASE则包括基本可用、软状态和最终一致性，允许系统在故障时损失部分可用性，并允许数据存在中间状态，但最终达到一致。
