数据库读写分离方案，实现高性能数据库集群

一般我们业务在读多写少的场景下，遇到的第一个瓶颈就是数据库这块，大量的读请求会来到数据库，这样如果你初期部署的一个数据库就会造成IO大量增加，使得请求变慢，甚至会卡死整个数据库，到了这个阶段，我们一般会将读请求和写请求进行分开数据处理，即采用主从读写分离的方式。

注：这里说的是主从并不是主备，主从中的从服务器是要承担业务的，而主备中备份机器一般只作为备份存在。

我们采用主从读写分离的方式，目的是为了将更多的读请求进行分发来缓解我们的大量读请求。

01

读写分离架构原理

正如上面所说，读写分离是为了将请求流量分散到不同的数据库节点上，将写入数据的请求分发到主数据库，读取数据的请求分发到从数据库，从数据可以有多台，即一主多从。如下图：

从上图可看出，有个关键技术就是主从复制，每次写入数据的时候，需要将主服务器数据复制到从服务器中，用来确保数据一致性。下面我们来单独看看主从是怎么复制的，以我们互联网中最熟悉的MySql为例。

1. 从服务器连接上主服务器，启动复制的时候，则会自身创建一个IO线程去像主数据库服务器拉取binlog的更新信息。
2. 把拉过来的binlog信息写到自己服务器的一个relay log日志文件中。
3. 从数据库服务器创建一个SQL线程，是为了将relay log的所有日志信息，进行sql回写到自己的数据库中，这样就和主库的数据一模一样了。
4. 当主数据库有数据更新的时候，比如新插入了一条或者update了一条数据，这时候主库会将这些数据更新到binlog二进制文件中，同时，主库会创建一个binlog dump线程，这个线程将更新了的binlog信息发送到从库的IO线程，需要注意的是，这个过程是异步的，如果等着从库接受完成，是不是特别慢，且影响性能。

这样的“一主多从”的主从复制方案做好之后，现在咱们就不怕当前这些大量的读请求了，因为我们把这些大流量读请求都分发到这些从数据库中了，写入数据的请求依然还是写到主数据，一点不影响我们读的业务，互不影响的。同时，从数据库还可以作为备份数据库来使用，万一主库突然故障了，它可以顶上去防止数据丢失。

但是，我们不能一味的加从数据库，加个十七八个的，这样做是无脑的操作啊，你想想看，你加一堆的的从数据库连接到数据库，复制他的数据，太多的IO线程会造成主数据不堪重负的，就会造成你写入数据慢，还会卡死，这就悲剧了。所以，不能这么搞啊，一般生产环境一个主数据库挂三个从数据就行了，最多不能超过5个以上，要是还是不满足肯定就会有其他方案了啊，多级缓存方案啊，是不是，后面会讲的。

02

主从延时

上面说了主从读写分离的那么多好处， 主从同步是有延迟的，当然，这个延时一般都在ms级别，但是如果到了秒级别，可能就会对有些业务造成影响，看我们能否接受。比如，我们在支付系统创建支付单后，风控系统会进入查询作出相应的风控操作，如果查不到就会可能终止本次交易了。

主从延迟优化

1，我们可以在这些立马需要查的业务，让它直接查主数据库，但是这种方案不推荐，因为量大怕会拖垮主数据。

2，当从数据库读取不到，我们回去再读主数据，这样就能读到数据了。但是，这种也是有风险的，量大也会拖垮主库。

3，像我前面文章提到过，分重要性业务和非重要业务，将很核心的几个业务查主数据，其他非核心，读写分离。

4，使用缓存，将新增的数据同时添加一份缓存，然后查缓存数据，这种建议新增的数据使用缓存较好。

5，使用消息队列中间件进行消息冗余，将新的主数据内容，通过消息中间件MQ冗余一份当前数据，然后发到需要查询的系统。

在消息体不大情况下，推荐使用第5种优化方案，需要消息中间件；其次考虑缓存的，因为更新的操作，需要更新缓存，也需要解决一致性问题，所以，新增的数据，就首选缓存优化方案。最后，推荐重要性非重要性隔离方案。最好不要使用都查询主库的操作。

02

如何优雅使用读写分离

我们现在使用了数据库读写分离的机制，但是我们代码该怎么去友好的去访问数据库呢？以前我们一个数据源配置就可以了，现在有好多个数据源了，代码里既要区分哪个地方使用写数据库的数据源，哪个地方需要使用读数据的数据源。当然，肯定是有办法的，业界大佬们都早于我们遇到了这些问题，下面我会分享出两种方案：

1，程序代码嵌入

代码嵌入，是指通过在我们的代码中开发出数据库访问中间层，由这个数据库访问中间层去访问不同的数据源，以实现读写分离和数据源的管理。现在推荐使用淘宝开源的TDDL（Taobao Distributed Data Layer），使用方便，直接集成到我们代码就可以了，它自己管理读写分离和数据库配置。

特点是：

• 实现简单，可以根据自己业务进行定制化开发
• 语言不同，就得开发不同语言版本的数据库访问层

2，部署独立代理层

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

特点：

• 不用自己编写多余代码，使用方便。
• 支持对语言
• sql语句会跨两层网络，性能稍微低一点。

开发建议，在自己公司没有比较成熟的中间件团队的话就用程序代码封装的方案，虽然写代码麻烦点，但是自己可以把控；要是公司有成熟中间件团队，就尽量考虑代理层部署的方案，因为需要有个团队要研究和长期维护这个代理层，才能确保业务正常发展，现在我们公司大部分都用的是代理层方案，是有个专门团队来维护。

总结，今天讲到了当我们读多写少的场景下，采取数据库读写分离的方式来分摊大流量。从而引出了主从复制，并且对主从复制的延迟进行了优化方案的讲解和给出来相应的建议，希望对大家有所帮助。如果大家喜欢就关注我，让我们一起聊公司的各种技术，共同学习共同进步，有什么想说的是想学的可以私信哈，大家都可以给方案，谢谢

下一集预告：说到了读写分离，肯定离不开更多存储数据的分库分表真实解决方案啦，敬请期待。

关于架构师修炼

本号旨在分享一线互联网各种技术架构解决方案，分布式以及高并发等相关专题，同时会将作者的学习总结进行整理并分享。

更多技术专题，敬请期待