一. 前言
1. 背景
大部分场景中，DB操作80%是读，20%是写，对于时效性要求不高的数据，为了减少磁盘读和写的竞争，引入读写分离的概念，即在数据库上进行主从配置，一个主，多个从，实现主从同步，从而业务上实现读写分离。
读写分离在网站发展初期可以一定程度上缓解读写并发时产生锁的问题，将读写压力分担到多台服务器上。基本原理是让主数据库处理增、删、操作，而从数据库处理SELECT查询操作。随着系统的业务量不断增长，数据不断增多，数据库的IO操作压力会很大，读写分离也是数据库分库的一种方案。
(1). 主库：叫读写库，主要用来处理 增删改，特殊情况也可以查。
(2). 从库：叫只读库，主要用来查询数据。
2. 需要解决的问题
在业务上区分哪些业务是允许一定时间延迟的，可以接受数据同步的耗时。
3. 常见实现方式
复制模式、镜像传输、日志传输、和 Always On技术
二. SQLServer各种模式介绍
1. 复制模式
(1). 简介
复制模式也被称为【发布-订阅模式】，是由主服务器进行发布消息，备份服务器进行订阅，当主服务器数据发生变更时，就会发布消息，备份服务器读取消息进行同步更新，中间过程延迟比较短。
复制方式是以前很常见的一种主备，速度快，延迟小，可以支持部分同步等优点，但是也有一个很明显的缺点，因为是部分同步，如果是表修改，可以主动同步，但是如果是新增表、视图等操作，必须在发布属性中，将新加的表或者视图添加到同步配置中，否则对这个表做的任何操作都不会同步。
复制模式同步，要求数据库名称和主机名称必须一致，否则查找不到数据库主机；要求数据库不能使用端口，必须是可以通过ip直接访问的。
(2). 发布分为4种模式：
A.快照发布
发布服务器按'预定的时间间隔'向订阅服务器发送已发布数据的快照。
快照发布，就是将所有要发布的内容，做成一个镜像文件，然后一次性复制到订阅服务器，两次快照之间的更新不会实时同步,而是按照设置的'预定间隔'进行。这种方式占用带宽较多，因此比较适用内容不是很大，或者更新不需要很频繁的场景。
B.事务发布
在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。
事务发布，是在第一次设置好事务复制之后，所有发布的内容都会进行镜像快照，订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。当主服务器数据发生变更时，会通过日志传递同步
给订阅服务器，数据近似于同步更新。
此方式会对主服务器性能造成很大影响（实时同步每次变更，而不是最终变更），适用于对数据及时性要求比较严格主备方案，但是目前已被微软提供的集群Always On所取代。
C.对等发布
对等发布支持多主复制。发布服务器将事务流式传输到拓扑中的所有对等方。所有对等节点可以读取和写入更改，且所有更改将传播到拓扑中的所有节点。
D.合并发布
合并发布是相当于两台都是主服务器，都可以对数据进行更新修改等操作，然后定时将发布服务器上的内容与订阅服务器上的内容进行合并，并根据配置保留相应内容，此种很少用。
(3). 该模式的订阅分两种：
A.请求订阅：从数据库按照既定的周期来请求主数据库，将增量数据脚本获取回去执行，从而实现数据的同步。
B.推送订阅：主数据库数据有变更的时候，会将增量数据脚本主动发给各个从数据库(性能优于请求订阅模式，建议使用)。
注：从数据库中表设计的时候，主键不要用自增！！
2. 镜像传输
数据库镜像传输，严格来说不是主从架构，而是主备架构，将两台数据库服务器通过一台中间监控服务器关联起来，两台服务器通过镜像文件，实时同步数据（有延迟，延迟很短）。当主服务器宕机之后，监控服务器自动切换到备份服务器上。
此方案优点是可以快速的切换主备方案，相比较Always on集群，可以不用共享磁盘即可实现，避免了数据库集群存储单点故障，导致整个集群崩溃。
缺点也很明显，无论是主备服务器，要实现同步操作，都是依赖于性能低的那一端，因此两台服务器都要是高性能的才可以保证同步的及时性；同时备份服务器只是备份和故障转移，不能提供从服务器的只读访问，
因此才说是主备服务器，而且是一对一，只能有一台备份服务器。
3. 日志传输
与镜像传输模式类似，是将主数据库日志备份，发送到从服务器上，然后从服务器还原日志，更新数据。
此方式优点在于从服务器可以有多台从服务器，而且当主服务器脚本操作异常后，只需要在日志同步之前，及时拦截日志传输，即可保留从服务器数据，减少灾难损失；此方式相较于“复制发布”模式，还有一个有点就是无论是新增表、视图等等，都会通过日志同步给从服务器，而复制模式不行
而相应的缺点就是通过日志备份传输，在还原，会有较大的时间延迟。而且无法自动转移故障，只能手动转移。
4. Always On技术
AlwaysOn是基于Windows的故障转移集群，集群技术是微软提供的，可用性最高的主备方案。它是将多台服务器通过一个共享的外部存储区域（SAN），连接成一个资源共享的服务器群体，数据库文件和实例，都存放并运行在该共享区域节点上，每台服务器相当于一个节点，共同访问共享的节点实例。服务器只有一个节点处于活动状态，当活动节点出现故障，会有其他节点主动启动，取代当前故障点，整个过程只需要几秒钟，用户无法感知。
集群有很多优点，是目前最高效的高可用技术，但是他也有很明显的缺点，所有的节点，都依赖于共享节点实例，如果共享节点出现故障，将会导致整个集群失去作用，且很难恢复。
三. 发布订阅模式实操
事先准备：
(1). 启动SQLServer代理模式。
A. 在服务中启动：运行services.msc，找到 ‘SQL Server 代理 (MSSQLSERVER)’，手动启动。
B. 在开始菜单中找到SQLServer Configure Manger页面配置，手动启动。
(2). SQLServer要用本机名登录，不能Localhost
(3). 准备数据库(1主2从)
A. 主库：ReadWriteMaster
B. 从库：ReadWriteSlave1、ReadWriteSlave2
结构：含有一张UserInfor表，如下图：
PS：从库也可以不用创建，因为在新建订阅的时候，可以选择自动创建，会自动同步数据库结构。
1. 配置分发服务器
(1). 如果是首次配置读写分离，需要配置分发服务器，后续不再配置。 如果不想用之前的分发服务器，可以右键复制，禁用分发服务器，然后重新配置。
注：配置过程中，快照地址要有读写权限，不要放到C盘。
2. 新建发布
下面的演示步骤，是以【快照发布】的模式进行创建的，配置成10s同步一次； 也可以选择【事务发布】，实时同步，不需要配置同步频率。
3. 新建订阅
下面的演示步骤，采用的是【推送订阅】的模式进行，配置的是已经创建好的从数据库ReadWriteSlave1（ReadWriteSlave2相同），也可以现场创建。
补充：右键启动复制监视器，查看发布订阅的同步情况
四. 实操测试
1.单纯的SQL测试
use [ReadWriteMaster] select * from [dbo].[UserInfor] --delete from [dbo].[UserInfor] use [ReadWriteSlave1] select * from [dbo].[UserInfor] --delete from [dbo].[UserInfor] use [ReadWriteSlave2] select * from [dbo].[UserInfor] --delete from [dbo].[UserInfor] insert into [dbo].[UserInfor] values('008','ypf1',26,'2020-07-08')
结果：
向主数据库中插入一条数据，约10s后（用到是上面的快照发布），查询从数据库，数据已经通过来了。
2.结合EFCore进行测试
!
- 作 者 : Yaopengfei(姚鹏飞)
- 博客地址 : http://www.cnblogs.com/yaopengfei/
- 声 明1 : 如有错误，欢迎讨论，请勿谩骂^_^。
- 声 明2 : 原创博客请在转载时保留原文链接或在文章开头加上本人博客地址，否则保留追究法律责任的权利。