MySQL 读写分离相关原理知识体系

1.读写分离简介


1.1.常见高并发场景


随着一个网站的业务不断扩展，数据不断增加，数据库的压力也会越来越大，对数据库或者SQL的基本优化可能达不到最终的效果，此时可以考虑通过添加数据库节点来使其达到提升性能的目的通常有以下常见几种方案。
读写分离
打开一个帖子内容页，需要select帖子表，和帖子评论表，每个耗时10ms的话。每秒1000次查询就是这个数据库的极限了。也就是说，这个论坛只能承载每秒500次访问。那么我们就可以对这个数据库做读写分离，来成倍提高数据库的读性能。


水平分表
交易历史，这种表。因为很少查询1年前的信息。所以，我们可以按年份来进行水平分表。将今年的表优先对待。就减少了要查询的表的大小。


分库
如果我们的系统非常大了，功能非常多，就会有很多类型的数据库表，例如营销活动的表，和用户账号的表是没有关联的，那么我们就可以将他们分到两个数据库中，然后放到不同的独立的数据库服务器，就能使数据库吞吐量成倍增加。


垂直分表
典型的应用场景是在文章列表这样的场景，一般来讲，我们的文章表会有title、userId、Content等字段，其中的Content字段一般是Text或者LongText类型，而其它的字段都是固定长度的数据类型。我们知道一个数据库优化规则是：


如果一个表的所有字段都是固定长度类型的，那么它就是定长表，定长表比动态长度表查询性能要高
那么，我们就可以使用垂直分表来将文章表分成文章表和文章内容表。于是文章列表页面所需的查询，就只需要查询一张定长表了。
引入Cache
通常来说即使前者的数据库架构做得再好，对于定时抢购/抽奖/等，这种类似高密度密集访问的场景也是力不从心，最好的方法还是在服务层和数据库层添加一个缓存层用，使其让请求命中至缓存层，数据层只持久化变更的数据即可。


1.2.读写分离原理


MySQL的主从复制和MySQL的读写分离两者有着紧密联系，首先部署主从复制，只有主从复制完了，才能在此基础上进行数据的读写分离。简单来说，读写分离就是只在主服务器上写，只在从服务器上读，基本的原理是让主数据库处理事务性查询，而从数据库处理select查询。当业务量非常大时，一台服务器的性能无法满足需求，就可以通过配置主从复制实现写分离来分摊负载，避免因负载太高而造成无法及时响应请求。


1.3.读写分离类型


基于程序代码内部实现
在代码中根据select,insert进行路由分类，这类方法也是目前生产环境应用最广泛的，优点是性能好，因为在程序代码中已经将读写的数据源拆分至两个，所以不需要额外的MySQL proxy解析SQL报文，在进行路由至不同数据库节点。缺点是通常该架构较复杂，运维成本相对较高。


基于中间代理层实现
代理层一般位于客户端和服务器之间，代理服务器接到客户端请求后通过解析SQL文本再将SQL路由至可用的数据库节点中。优点是程序不需要改造可以实现无缝迁移，可移植性较好。缺点是性能相对前者略微逊色一些，并且并不是所有的读操作都能够被路由至从节点中。