RD：单个数据库的数据量太大，数据库处理不了，所以想申请一个读写分离的数据库从库。DBA：有多少数据？RD：约5000w。DBA：读写吞吐量如何？RD：阅读QPS在200左右，写作QPS在30左右。上周在公司听到两个技术同学在讨论。感觉没搞清楚读写分离要解决什么问题，有点落魄。另外，对于网上的一些业务场景，我不是很喜欢数据库读写分离的架构。文章末尾有一些简单的见解。一、读写分离什么是数据库读写分离？答：一主多从，读写分离，主动同步，是一种常见的数据库架构。一般来说：主库提供数据库写服务，从库提供数据库读服务。master和slave通过一定的机制同步一组数据，比如mysql的binlog，从一个同步的集群中通常被称为“组”。分组架构解决什么问题？答：大部分互联网服务读多写少，数据库读往往成为性能瓶颈。如果你想：线性提高数据库读性能通过消除读写锁冲突提高数据库写性能这时候可以使用分组架构。总之，分组主要是解决“数据库读取性能瓶颈”的问题。当数据库无法处理读取时，通常会进行读写分离，通过添加从库来线性提升系统的读取性能。2.水平切分什么是数据库水平切分？答：水平切分也是一种常见的数据库架构。一般来说：各个数据库之间没有数据重叠，也没有类似binlog同步的所有数据的组合。在组合所有数据时，将使用算法来完成数据分割。例如，“取模”水平分片集群中的每个数据库，通常称为“分片”。水平切分架构解决什么问题？答：大多数互联网服务的数据量都很大，单个数据库的容量很可能成为瓶颈。如果你想：线性降低单个数据库的数据容量线性提升数据库写入性能此时，可以使用水平切分架构。一句话，水平切分主要解决“数据库数据量大”的问题。当数据库容量无法承受时，通常采用水平切分。3、为什么不喜欢读写分离？对于互联网大数据量，高并发，对高可用性要求高，一致性要求高，前端面向用户的业务场景，如果数据库读写分离：需要区分数据库连接池：读连接池，如果要在写连接池中保证读的高可用，在读连接池中实现自动故障转移，主从库之间存在潜在的一致性问题。如果你正面临“读取性能瓶颈”的问题，增加缓存可能更直接、更容易。关于成本，从库的成本要比缓存高很多。对于云上的架构，以阿里云为例，主库提供高可用服务，从库不提供高可用服务。因此，在以上业务场景中，宿主推荐使用缓存架构来提升系统的读取性能，替代数据库主从分离架构。当然，使用缓存架构的潜在问题：如果缓存宕机，所有的流量都会压在数据库上，数据库就会雪崩。幸运的是，云端的缓存一般都提供高可用的服务。4.总结读写分离，解决“数据库读取性能瓶颈”水平切分，解决“大数据库数据量”问题针对互联网大数据量、高并发、高可用性要求、高一致性要求，前端面向用户的业务场景，微服务缓存架构可能比数据库读写分离架构更适合
