读写分离

背景

在一个应用系统中（特别是业务高速发展的业务）数据库由于跟磁盘交互，容易成为阻碍业务发展的瓶颈

1. 数据库连接资源有限
2. 增、删、改操作会对数据库进行上锁，如果应用长时间占用锁会导致其他请求对数据的访问响应慢，甚至发生超时异常

解决方案

介于以上问题，可以通过读写分离的方案进行解决

1. 所有的增、删、改操作只对主库进行
2. 主库数据写入后通过中间件或数据库主从复制将数据同步到从库（只读数据库）
3. 从库只提供读服务

这样可以有效增加数据库连接资源，对于长时间占用事务的写（增、删、改）操作并不会对读请求造成影响

应用场景

读写分离的方案主要是针对读多写少的场景，例如：

1. 微博、抖音、今日头条：一个网红大V编写一条微博，只有一次写操作，但是读这条微博的人数可能有几百万

2. 抢票、秒杀：一件商品库存只有100件，但是同时抢的用户可能有1W人，这些用户每个人都至少发起过一次读请求，但是最后能抢单成功的只有100人

   中间件

3. TDDL，阿里开源的中间件，内部还提供了分库分表解决方案，开源版本只提供了读写分离功能

4. ShardingSephere，当当开源的中间件，目前市场上比较流行。是通过在应用层拦截sql语句来判断是读请求还是写请求，然后动态路由到对应数据库进行操作

1. MyCat，基于代理实现分库分表。MyCat通过在应用服务和数据库服务之间增加代理层，代理层通过发送的sql语句判断改路由到哪个库进行操作

   问题

2. 主从延迟

当我们在主库A中写入了一条数据后，马上要对同一张表进行读操作，由于数据同步由于受网络等因素的影响导致在读从库的时候没有读到数据
对于这种实时性要求较高的读请求，需要将读操作控制在主库

1. 数据量过大

虽然读写分离可以解决数据库连接资源不够及写请求占用锁问题，但是随着业务的发展，数据库中的记录越来越多，导致数据库中记录数量较大，无法正常提供读服务（一般MySQL单表超过1000W记录查询性能开始较差）
数据量过大的问题可以通过分库分表的方案进行解决