数据库读写分离详解( 二 ) _数据库

如何优雅使用读写分离我们现在使用了数据库读写分离的机制，但是我们代码该怎么去友好的去访问数据库呢？以前我们一个数据源配置就可以了，现在有好多个数据源了，代码里既要区分哪个地方使用写数据库的数据源，哪个地方需要使用读数据的数据源。当然，肯定是有办法的，业界大佬们都早于我们遇到了这些问题，下面我会分享出两种方案：
1，程序代码嵌入
代码嵌入，是指通过在我们的代码中开发出数据库访问中间层，由这个数据库访问中间层去访问不同的数据源，以实现读写分离和数据源的管理。现在推荐使用淘宝开源的TDDL（Taobao Distributed Data Layer），使用方便，直接集成到我们代码就可以了，它自己管理读写分离和数据库配置。

文章插图

特点是：

实现简单，可以根据自己业务进行定制化开发

语言不同，就得开发不同语言版本的数据库访问层

2，部署独立代理层
部署代理层是指，在我们的业务服务器和数据库直接引入数据访问代理层，并不用自己写代码。现在为代表的开源中间件有阿里的MyCat、360的Atlas、美团的DBProxy等。这些都是使用标准的MySql通信协议。

文章插图

特点：

不用自己编写多余代码，使用方便。

支持对语言

sql语句会跨两层网络，性能稍微低一点。

建议，在自己公司没有比较成熟的中间件团队的话就用程序代码封装的方案，虽然写代码麻烦点，但是自己可以把控；要是公司有成熟中间件团队，就尽量考虑代理层部署的方案，因为需要有个团队要研究和长期维护这个代理层，才能确保业务正常发展，现在我们公司大部分都用的是代理层方案，是有个专门团队来维护。
总结，今天讲到了当我们读多写少的场景下，采取数据库读写分离的方式来分摊大流量。
二、大量并发写入所带来的性能问题优化
随着运营部门的同事在不停的做出各种促销或者拉新活动，我们注册用户越来越多，同时订单量以及用户行为数据等持续的增加，导致我们的系统现在出现了下面这些问题。

订单量剧增，单表数据量已经达到了千万的级别了，这个时候的索引查询已经很慢了，所以现在我们的类似这些大数据表的查询性能很差
数据量持续增加，现在我们的磁盘大部分空间都被使用，导致数据库的复制备份操作很缓慢，所以，目前数据库系统已不能满足现在的数据量级。
我们整个系统的所有业务，订单，用户，优惠券、政策等等都在一个数据库系统，耦合性太高，数据不隔离。
像每天大量的用户关注、行为数据以及订单数据的写入，导致系统的写入性能持续下降。

以上这些问题均是由于大并发的写入操作导致目前的系统读写性能下降，并且系统可用性也在降低，这些都是现在阶段需要解决的，需要将这些数据进行分片，也就是分散开，栏均摊我们整个数据库的数据压力，同时也是解决单机数据容量以及性能的解决方案，我们业界现在比较流行的方法就是“分库分表”的方案。
提到分库分表，大家应该都不陌生，但是怎么在自己项目中合理的使用分库分表却不是一件容易的事情，从今天开始，我们从分库分表的策略到怎么部署上线以及怎么避坑等内容开始切入，帮助大家更好的掌握并使用分库分表的技术
怎么做数据库垂直拆分垂直拆分是分库分表方案中最为常见的一种方式，大的核心思想就是，将一堆的统一数据放到其他节点数据库中或者表中进行存储，不同于我们前面主从复制，主从复制是所有节点数据都是一样，而垂直拆分后，是每个节点存储一部分数据，就像Hadoop里面的一个个的Block一样。
垂直拆分好处：