数据库性能瓶颈是每个高并发系统都绕不开的问题。当单库扛不住的时候，读写分离就是最常用的优化手段之一。

什么是读写分离？

简单说，就是把数据库的读操作和写操作分开。通常一个主库负责写，多个从库负责读。

为什么要这么做？因为数据库的"写"和"读"性能差异太大了。

写1万条数据可能要3分钟，读1万条数据只要5秒。如果读写都挤在一个库上，写操作慢就会拖慢读操作，用户体验就差了。

特别是读多写少的场景，比如电商网站、新闻资讯，大部分请求都是查询，这个时候做读写分离效果最明显。

怎么实现？基于主从复制

读写分离的基础是主从复制架构。

搞一个主库，挂几个从库。所有写操作都往主库发，主库会自动把数据同步到从库。

具体怎么同步？

主库每次执行insert、update、delete，都会把操作记录到binlog日志里。binlog就像一个账本，记着所有数据变更。

从库有个IO线程，会连接到主库，把binlog拷贝到自己本地，存成一个叫relay log的中间日志。

从库还有个SQL线程，从relay log里读取操作记录，然后在本地再执行一遍同样的SQL。这样从库的数据就和主库保持一致了。

两个躲不开的坑

听起来很完美，但实际用起来有两个问题必须面对。

问题一：数据延迟

从库同步主库数据是异步的。主库上并行执行的操作，到了从库会串行执行。高并发场景下，从库数据会比主库慢几十毫秒甚至几百毫秒。

这就会出现：刚写入的数据，从从库读不到。

问题二：主库宕机数据丢失

如果主库突然挂了，恰好有些数据还没同步到从库，这些数据就丢了。

怎么解决这些坑？

MySQL提供了两个机制。

机制一：半同步复制——解决数据丢失

半同步复制要求：主库写完binlog后，必须等至少一个从库把日志写入自己的relay log，并且返回确认信号，主库才会认为写入成功。

这样即使主库宕机，至少有一个从库保存了最新数据，不会丢。

机制二：并行复制——缓解同步延迟

并行复制允许从库用多个线程同时读取relay log，并行执行SQL。

但要注意：并行复制是库级别的。同一个库里面的操作，还是串行执行。所以如果你的数据都在一个库上，并行复制的效果有限。

结束语

读写分离是数据库性能优化的常用手段，适合读多写少的场景。原理不难，但落地要注意细节。

数据延迟和一致性问题，是实施读写分离必须面对的挑战。当你发现数据库查询变慢，优化索引、优化SQL都没用的时候，就可以考虑了。

阅读原文：点击这里