可能有的技术同学对“读写分离”不太了解，认为“读写分离”可用于数据库负载问题的解决。这其实是一个很大的误区。如果我们要使用“读写分离”，首先应该了解“读写分离”是用来解决什么样的问题，而不是仅仅使用这种技术。什么是读写分离？实际上，数据库分为主从数据库。一个主库用于写数据，多个从库完成读数据的操作。主从数据库通过一定的机制同步数据。一个通用的数据库架构。从集群中同步出一个组，通常称为“组”。数据库分组架构解决什么问题？大多数互联网企业往往读的多，写的少。这时候数据库读取首先会被称为数据库的瓶颈。这时候，如果我们想线性提升数据库的读性能，消除Lock冲突来提升数据库的写性能，那么就可以采用“分组架构”（读写分离架构）。一句话，就是用读写分离来解决数据库读性能的瓶颈。但是并不是任何读性能瓶颈都需要使用读写分离，我们可以有其他的解决方案。在互联网应用场景中，往往数据量大，并发度高，对高可用的要求很高，对一致性的要求也很高。如果使用“读写分离”，需要注意这些问题：数据库连接池一定要区分，哪些是读连接池，哪些是写连接池，会增加研发难度;为了保证高可用，读连接池必须能够自动故障转移；需要考虑master和slave的一致性。考虑的问题这么多，如果我们只想解决“读数据库的瓶颈问题”，为什么不选择使用缓存呢？为什么要使用缓存？缓存也是互联网中经常使用的一种架构方式。同时“读写分离”不同。读写分离使用多个读库来分担数据库读取的压力，而存储则通过使用缓存来降低数据库读取的压力。他们没有说谁来取代谁，但是如果你在缓存的读写分离之间选择，你还是应该先考虑缓存。为什么？使用缓存的成本远低于从库；缓存的开发比较容易，大部分读操作可以先缓存起来，找不到的可以渗透到数据库中。当然，如果我们已经使用了缓存，但读取仍然是瓶颈，我们可以选择“读写分离”的架构。简单的说，我们可以把读写分离当成缓存解决不了的时候的解决方案。当然，缓存并非没有缺点。对于缓存，我们必须考虑高可用性。否则，如果缓存宕机了，所有流量同时聚集到数据库上，那数据库肯定宕机了。常见的数据库瓶颈是什么？其实就是数据容量的瓶颈。比如订单表，数据量只增不减，必须保留历史数据。很容易成为性能瓶颈。要解决这样的数据库瓶颈问题，“读写分离”和缓存往往是行不通的。最合适的是什么？数据库水平切分什么是数据库水平切分？数据库水平切分也是一种常见的数据库架构，是一种通过算法对数据库进行划分的架构。水平分片集群中的每个数据库通常称为“分片”。每个分片中的数据不重叠，所有分片中的数据组合在一起形成所有数据。水平分片架构解决了什么问题？大多数互联网服务的数据量都很大，单个数据库的容量最有可能成为瓶颈。当单个数据库的容量成为瓶颈时，我们希望提高数据库的写入性能，降低单个数据库的容量。如果是这样，可以使用水平拆分。但是，有一小部分程序员会在没有分析数据库性能瓶颈的情况下就贸然使用“读写分离”，不知道“水平切分”才是正道。
