读写分离（Read/Write Splitting）。

1.原理：让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。

2.诞生原因：

2.1 为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，仅仅接收来自第一台服务器的备份数据（注意，不同数据库产品，第一台数据库服务器，向第二台数据库服务器发送备份数据的方式不同）。当第一台数据库崩溃后，第二台数据库服务器，可以立即上线来代替第一台数据库服务器，并且，在第一台数据库服务器崩溃后，宝贵的数据，依然会存在于第二台数据库服务器里（根据目前业界的备份数据发送方式来看，当第一台数据库崩溃后，第一台数据库里的仍然会有少量的新数据，没能来得及被发送到第二台数据库服务器，所以，这部分数据就丢失了）。

2.2 一般来说，为了配置方便，以及稳定性，这两台数据库服务器，都用的是相同的配置（思考一下，如果两台服务器的配置不同，会导致什么结果）。

2.3 从上文的描述中，大家能看到，在实际运行中，第一台数据库服务器的压力，远远大于第二台数据库服务器。因此，很多人希望合理利用第二台数据库服务器的空闲资源。那么，第二台数据库服务器能做些什么事情呢？

2.4 从数据库的基本业务来看，数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作，如果是双机热备的环境中做，一台机器做了这三个操作的某一个之后，需要立即将这个操作，同步到另一台服务器上。单向的同步，不复杂。但如果两台机器都需要向对方进行同步，那逻辑就非常复杂，而且还会大大降低性能。（从保证ACID特性的角度，思考一下为什么双向同步会非常复杂且低性能？而单向同步却不会？）出于这个原因，第二台备用的服务器，就只做了查询操作。进一步，为了降低第一台服务器的压力，干脆就把查询操作全部丢给第二台数据库服务器去做，第一台数据库服务器就只做增删改了。

2.4 到这一步，就实现了所谓的读写分离。这样做，缺点也非常明显了。本来第二台数据库服务器，是用来做热备的，它就应该在一个压力非常小的环境下，保证运行的稳定性。而读写分离，却增加了它的压力，也就增加了不稳定性。因此，读写分离，实质上是一个在资金比较缺乏，但又需要保证数据安全的需求下，在双机热备方案上，做出的一种折中的扩展方案。