SQLServer事务复制延迟优化之并行（多线程）复制

事务复制的延迟

在数据库的主从复制过程中，包括MySQL的主从复制，SQLServer的事务复制等等，鉴于主节点往往是并发写入的，而从节点（SQLServer中叫做订阅节点）在重放主节点的写操作的时候，往往会产生一定时间的延迟，如何降低这种复制延迟，并行复制或者说多线程复制是其中手段之一。

SQLServer事务复制分发线程

参考如下图例涉及的事务复制相关的线程，类似于MySQL的MTS多线程并行复制技术，SQLServer数据的事务复制同步过程中，数据库在主节点（publication发布节点）上以并发的形式写入，从节点（Subscribtion订阅节点）默认情况下以单线程的方式来“重放”主节点的写入操作，这样在高并发的情况下可能会造成一个较高的复制延迟。这里的并行复制，就是下图中的writer thread，以多个线程的方式并行执行，来尽可能地降低复制延迟。

图片来源于https://red9.com/blog/sql-server-replication-performance-tips/

事务复制分发线程参数SubscriptionStreams

以下是SQLServer事务复制的进程结构示例图，从中可以看到，distrib.exe的writer thread就是把distrubution中解析出来的日志在订阅节点上重放的的实现者。

分发代理distrubution agent有一组配置文件，涉及到22个分发相关的参数，参考下图，其中SubscriptionStreams参数就是所谓的并行复制参数，默认值是1。

先看官方对SubscriptionStreams参数的解释：

SubscriptionStreams参数可以极大地提高聚合复制（注：这里官方叫aggregate replication ，一个很奇怪的用词）的吞吐量。

它允许到订阅服务器的多个连接并行应用批量更改，同时保持着事务在单线程下的特征（意思是和单线程回放效果一致）。如果其中一个连接执行或提交失败，则所有连接将中止当前批处理，代理将使用单个流重试失败的批处理。在此重试阶段完成之前，订阅服务器上可能存在暂时的事务不一致。在成功提交失败的批之后，订阅服务器将恢复到事务一致性状态。

SubscriptionStreams默认值是1，也就是distrubution agent使用一个线程在订阅节点做回放，该参数的可配置范围为1~64，但并不意味着事务复制的吞吐量会随着该参数的增加而等比例增加，考虑一下因素：

1，如果分发节点和订阅节点之间网络流存在瓶颈

2，订阅节点服务器CPU核数

3，订阅节点的磁盘IO处理能力有限

以上因素都会影响到订阅节点回放事务操作的效率。