RD：数据量太大，数据库处理不了。请帮我申请一个从库，实现读写分离。DBA：有多少数据？RD：约5000w。DBA：读写吞吐量如何？RD：读QPS在200左右，写QPS在30左右。嗯，虽然数据库读写分离不难，但是并不是所有“数据库处理不了”的场景都应该使用读写分离。今天花1分钟简单介绍一下这个场景。什么是数据库读写分离？一主多从、读写分离、主动同步是一种常见的数据库架构。一般来说：主库从数据库提供数据库写服务，主从之间提供数据库读服务。通过某种机制来同步数据，比如mysql的binlog，从同步集群出来的一组通常称为“组”。分组架构解决什么问题？大部分互联网业务读多写少，数据库读取往往首先成为性能瓶颈。如果你想：通过消除读写锁冲突来线性提高数据库读性能和提高数据库写性能，此时可以使用分组架构。总之，分组主要是解决“数据库读取性能瓶颈”的问题。当数据库无法处理读取时，通常会进行读写分离，通过添加从库来线性提升系统的读取性能。什么是数据库水平切分？水平切分也是一种常见的数据库架构。一般来说：各个数据库之间没有数据重叠，也没有类似binlog同步的关联。所有的数据被组合起来，算法被用来形成所有的数据。完成数据的拆分，比如“取模”水平拆分集群中的各个数据库，通常称为“分片”。水平分片架构解决了什么问题？互联网业务大多数据量大，单个数据库的容量容易成为瓶颈。如果你想：线性降低单个数据库的数据容量，线性提升数据库写入性能，此时可以使用水平分片架构。一句话，水平切分主要解决“数据库数据量大”的问题。当数据库容量无法承受时，通常采用水平切分。为什么我不喜欢读写分离？针对互联网大数据量、高并发、对高可用、高一致性要求高、前端面向用户的业务场景，如果数据库读写分离：需要区分数据库连接池：读连接池，如果要在写连接池中保证读的高可用，在读连接池中实现自动故障转移，主库和从库之间存在潜在的一致性问题。如果你正面临“读取性能瓶颈”的问题，增加缓存可能更直接、更容易。关于成本，从库的成本要比缓存高很多。对于云端的架构，以阿里云为例，主库提供高可用服务，从库不提供高可用服务。因此，在以上业务场景中，推荐使用缓存架构来提升系统读取性能，替代数据库主从分离架构。当然，使用缓存架构的潜在问题：如果缓存宕机，所有的流量都会压在数据库上，数据库就会雪崩。所以对于缓存，一般都是横向划分的，保证不会同时挂起。总结读写分离，解决“数据库读取性能瓶颈”水平切分问题，解决“大数据库数据量”问题针对互联网大数据量、高并发、高可用性要求、高一致性要求，前端-面向终端用户的业务场景，微服务缓存架构，可能比数据库读写分离架构更适合【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此查看阅读该作者的更多好文章
