读写分离的理解

读写分离解释

读写分离：
基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。
数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

数据库读写分离和数据一致性的冲突

读写分离一致性
读写分离： 为保证数据库数据的一致性，我们要求所有对于数据库的更新操作都是针对主数据库的，但是读操作是可以针对从数据库来进行。大多数站点的数据库读操作比写操作更加密集，而且查询条件相对复杂，数据库的大部分性能消耗在查询操作上了。

主从复制数据是异步完成的，这就导致主从数据库中的数据有一定的延迟，在读写分离的设计中必须要考虑这一点。以博客为例，用户登录后发表了一篇文章，他需要马上看到自己的文章，但是对于其它用户来讲可以允许延迟一段时间（1分钟/5分钟/30分钟），不会造成什么问题。这时对于当前用户就需要读主数据库，对于其他访问量更大的外部用户就可以读从数据库。

适当放弃一致性：在一些实时性要求不高的场合，我们适当放弃一致性要求。这样就可以充分利用多种手段来提高系统吞吐量.
	
	例如页面缓存、分布式数据缓存、数据库读写分离、查询数据搜索索引化。

因此：

要使用读写分离来实现系统吞吐量的提升就要从业务上想办法降低一致性的要求。
对必须要有一致性的功能是无法进行读写分离的，可以采用多库不区分读写以及memcache缓存技术来实现。
所以主从分离后，去从数据库读的话，可能还没同步过来。

读写分离，很像，申报和审批分库。申报的基本上是写入数据库操作，审批基本上是查询数据库操作。
申报和审批分离之后，申报端使用申报数据库，审批端使用审批数据库，这样可以提升性能。
	问：申报和审批分库，为什么能提升性能呢？
	答：如果不分开，所有操作都在一个数据库中（比如zjkgl）进行，如果并发用户有1000个。即zjkgl数据库，得为1000个用户提供查询、写入等数据库服务。
		申报和审批分开之后，zjkgl_shenbao，zjkgl_shenpi。就相当于将1000个并发用户，分流了，一部分用户（如800人）对zjkgl_shenbao数据库进行操作，另一部分用户（如200人）对zjkgl_shenpi数据库进行操作。
		即以前1000个用户的事情，由一个东西来干；分库后，1000个用户的事情，由两个东西来干。

那么为什么要读写分离呢？

因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。
但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。

所以读写分离，解决的是，数据库的写入，影响了查询的效率。

总结：
数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库 主从同步 。可以减少数据库压力，提高性能。当然，数据库也有其它优化方案。memcache 或是 表折分，或是搜索引擎。都是解决方法。