复制无法扩展写操作，主-主结构也不行

复制能扩展的只有读操作（多台备库分担读请求），写操作没有对应的扩展 路径——这不是配置或调优能解决的限制，而是复制机制本身的结构性约束： 备库要重放主库上的每一次写，写入吞吐量最终受限于单台备库能把这些变更 串行应用完的速度，加再多备库也不会让”单条变更流能被多快应用”这件事 变快。一个容易想到但实际上不成立的绕开思路是主-主拓扑（两台服务器互为 主备，各自承担一部分写入）：直觉上”每台服务器只处理50%的写入，那复制 需要串行化重放的量也只有50%“，看起来比”一台机器100%并行处理写入、 另一台机器100%串行重放”更均衡。但这个直觉忽略了一个关键点：一台服务器 本身对写入的并行处理能力，天然强于对同一批写入做严格串行的重放能力 （重放必须保证顺序、保证和源头一致），所以”一台服务器100%并行写、 另一台100%串行重放”里，负责重放的那台备库确实是瓶颈，但主库本身仍然 是全速并行的；换成主-主之后，两台服务器都要各自拿出一部分能力用来做 低效的串行重放，整体上”被迫串行化处理的写入总量”并没有减少，只是从 集中在一台机器上分散到了两台机器上——而一台把50%写入串行化处理的 服务器，性能仍然比一台全部写入都能并行处理的服务器差，所以主-主结构 换来的收益，抵不过它带来的双主写入冲突风险和复杂度成本。唯一真正能 扩展写入能力的办法是对数据做分区/分片，把不同的写流量分散到不同的、 彼此独立的服务器上，而不是让同一份数据在多台服务器间来回复制。