系统高并发量优化之数据库读写分离

作者 | 跟鸟叔学编程
来源 | 今日头条

前言：

面对请求的高并发量，优化的方案有很多。例如：使用缓存、负载均衡、系统业务拆分、消息队列等等。

本篇文章主要学习数据库层面的解决方案，通过数据库的发布、订阅功能，实现数据库的读写分离操作。本章案例以SqlServer数据库为例。

读写分离设计原则：

并不是所有的牛奶都叫特仑苏，并不是所有的优化方式，都适用于你的系统!

读写分离操作，原则还是基于读与写操作的比例，如果对于读的需求，要远远大于写入的操作，那么使用读写分离的设计，就是非常对症了!

发布与订阅的规则：

例如：我们有一个数据库名为Test，无论增晒改查操作，都是对Test库的操作。当访问量大幅提升之后，吞吐性能肯定会随之降低。

此时我们将Test库作为写入库，另外建立一个数据库作为查询库。这样用户的操作，从以前针对一个数据库的操作，变成了分流!

通过发布、订阅的实现，写入到Test数据库中的数据，会被同步到查询库中，这样保证了数据库之间数据的一致性。

一个数据库负责用户的写入操作，一个数据库负责对用户的查询操作。这样的设计，无疑对系统性能的提升，有着直接的帮助!

发布操作步骤：

在这里我们首先创建三个数据库，一个是Test，这是主库，负责写入操作。两个一个是TestReadOne，另外一个是TestReadTwo，这两个数据库负责查询操作。

发布者为Test，订阅者为TestReadOne、TestReadTwo，类似于主播与粉丝的关系，主播发布新作品之后，粉丝即可看到。

接下来非常重要的俩个操作，也是决定是否配置成功的俩个关键步骤。

启动代理服务：启动的方式有两种，一种是在管理工具中直接开启，另外一种在系统服务中，找到SqlServer代理服务，然后点击启动。

第二个操作就是设置Sqlserver安装目录，repldata文件夹权限，否则配置好发布、订阅之后，提示无法访问该目录的错误。

接下来我们就可以安逸地配置发布、订阅功能了，选择新建本地发布。

选择发布的数据库，此数据库发布之后，订阅者才可以看到，并且订阅!

在这里我们选择事务的同步方式，虽然性能损耗会大一些，但保持了数据的一致性。

选择发布的内容，这里把需要同步到订阅库中的表，进行选中，这样当发布库中选中表的数据发生变化，订阅库也会随之更新。

发布、订阅的功能还是非常强大的，可以进行筛选设置，可以选择出你所需要的数据，当然不需要的话，我们直接下一步即可。

选择立即创建快照，如果有特殊需求，可以对时间进行精细化把控!

由于我是本地库搭建，不需要考虑安全性问题，如果小伙伴在服务器上配置，并且存在数据库服务器与服务器之间的操作，那么这里一定要慎重一些，选择账号、密码的方式，还是更加安全的。

最后一个步骤，填写发布的名称，给主播起个霸气的名字，就完成发布的操作了!

我们来看看是否创建成功，在发布文件夹下，会出现我们发布的任务，并且可以通过监视器来查看发布服务器的情况。

订阅操作步骤：

那么主播已经创建好了，粉丝们要开始关注了，这样才能接受来自主播的各种“毒害”。。。

新建订阅：

列表中果然出现了主播的身影，果断关注他就可以了!

选择订阅的粉丝是哪个：这里是TestReadOne数据库。

关于安全性的设置，我们同样采取代理的方式。

以上就完成了第一个订阅数据库TestReadOne的操作，TestReadOne数据库重复上述操作即可。

操作成功之后，我们可以看到订阅的目录中，多了两个订阅者。

通过查看发布的数据库的监视器，已经开始正常工作状态了。

发布库中的表与数据，也同步到订阅的数据库之中。

三个数据库中的数据，也是完全同步的状态了。

此时我们继续测试一下，在发布库Test中，增加两条数据，修改一条数据，删除一条数据，观察订阅库中是否也随之改变。

测试之后发现，数据完全一致，订阅库中的数据，随着发布库数据的改变，而随之改变。