系统架构解析-读写分离，水平切分及缓存架构对比

  最近在研究一些系统架构方案，学习到读写分离的时候，对于读写分离应用场景有了一些自己的理解：

一. 读写分离

1. 什么是数据库读写分离

  首先我们看一个读写分离架构图：

  读写分离就是：一主多从，读写分离，主动同步，是一种常见的数据库架构，一般来说：

• 主库：提供数据库写服务；
• 从库：提供数据库读服务；
• 主从之间：通过某种机制同步数据，比如MySOL的binlog

  一个主从同步的集群通常称为一个“分组”，这也是分组这个概念的含义。

2. 分组架构能够解决的问题

 在大部分互联网业务场景中，读操作的比例远远大于写操作，数据库的读往往最先成为数据库的新能瓶颈，如果想要完成下面的目标：

• 线性提升数据库读性能；
• 通过消除读写锁冲突提升数据库写性能

这两种期望的业务场景都可以使用分组架构来解决问题。总结来说，分组主要解决的就是“数据库读性能瓶颈”问题。在数据库无法胜任当前的读要求时，就可以进行读写分写，通过增加从库线性提升系统读性能。

二. 水平切分

 1. 水平切分

  水平切分，也是一种常见的数据库架构，一般来说：

• 每个数据库之间没有数据重合，没有类似binlog同步的关联；
• 所有数据并集，组成全部数据；
• 会用某些算法，来完成数据分割，例如取模运算

  一个水平切分急群众的每个数据库，通常称为一个分片。

2. 水平分片架构解决的问题

   大部分互联网业务数据量很大，单库容量容易称为瓶颈，如果希望解决下面的问题：

•  线性降低单库数据容量；
• 线性提升数据库写性能

   这两种改进要求时可以采用水平分片架构。一般来说，水平分片主要解决数据库数据量大的问题，在数据库单库容量无法满足系统要求时，我们可以采用水平切分。

三 读写分离的不适用性

   对于互联网，大数据量、高并发量、高可用性、高一致性、前段面向用户的业务场景，如果数据库读写分离：

• 数据库连接池需要区分：读连接池、写连接池；
• 如果要保证高可用性，读连接池要实现故障自动转移；
• 有潜在的主从一致性问题。

四. 缓存架构

    

缓存的架构图如上图，应用场景包括：

• 如果面临的是“读性能瓶颈”问题，增加缓存可能来的更直接，更容易一点；
• 关于成本，从库的成本比缓存高了很多；
• 对于云上的架构，主库提供高可用服务，从库不提供高可用服务

  这几类场景就建议使用缓存架构来加强系统读性能，代替数据库主从分离架构。当然缓存架构的潜在问题：如果缓存挂了，流量全部压到数据库上，数据库会雪崩。同样缓存会有缓存穿透、缓存一致、缓存雪崩、缓存并发等问题

五.小结

1.  读写分离，解决“数据库读性能瓶颈”问题；
2. 水平切分，解决“数据库数据量大”问题；
3. 对于互联网大数据量、高并发量、高可用要求、高一致性、前段面向用户的应用场景，微服务缓存架构，可能比读写分离架构更加合适。