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

文章插图

各位志同道合的朋友们大家好，我是一个一直在一线互联网踩坑十余年的编码爱好者，现在将我们的各种经验以及架构实战分享出来，如果大家喜欢，就关注我，一起将技术学深学透，我会每一篇分享结束都会预告下一专题

一般我们业务在读多写少的场景下，遇到的第一个瓶颈就是数据库这块，大量的读请求会来到数据库，这样如果你初期部署的一个数据库就会造成IO大量增加，使得请求变慢，甚至会卡死整个数据库，到了这个阶段，我们一般会将读请求和写请求进行分开数据处理，即采用主从读写分离的方式。
注：这里说的是主从并不是主备，主从中的从服务器是要承担业务的，而主备中备份机器一般只作为备份存在。
我们采用主从读写分离的方式，目的是为了将更多的读请求进行分发来缓解我们的大量读请求。
读写分离架构原理正如上面所说，读写分离是为了将请求流量分散到不同的数据库节点上，将写入数据的请求分发到主数据库，读取数据的请求分发到从数据库，从数据可以有多台，即一主多从。如下图：

文章插图

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

文章插图

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

这样的“一主多从”的主从复制方案做好之后，现在咱们就不怕当前这些大量的读请求了，因为我们把这些大流量读请求都分发到这些从数据库中了，写入数据的请求依然还是写到主数据，一点不影响我们读的业务，互不影响的。同时，从数据库还可以作为备份数据库来使用，万一主库突然故障了，它可以顶上去防止数据丢失。
但是，我们不能一味的加从数据库，加个十七八个的，这样做是无脑的操作啊，你想想看，你加一堆的的从数据库连接到数据库，复制他的数据，太多的IO线程会造成主数据不堪重负的，就会造成你写入数据慢，还会卡死，这就悲剧了。所以，不能这么搞啊，一般生产环境一个主数据库挂三个从数据就行了，最多不能超过5个以上，要是还是不满足肯定就会有其他方案了啊，多级缓存方案啊，是不是，后面会讲的。
主从延时上面说了主从读写分离的那么多好处，主从同步是有延迟的，当然，这个延时一般都在ms级别，但是如果到了秒级别，可能就会对有些业务造成影响，看我们能否接受。比如，我们在支付系统创建支付单后，风控系统会进入查询作出相应的风控操作，如果查不到就会可能终止本次交易了。
主从延迟优化