事务复制的延迟
在数据库的主从复制过程中，包括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处理能力有限
以上因素都会影响到订阅节点回放事务操作的效率。
SubscriptionStreams值对事务复制吞吐量的影响
参考微软官方的SQLServer team blogs中的测试结果
在单事务（ singleton transactions，每个事物一条命令）情况下，在修改默认的commitbatchsize（默认为100）为200，SubscriptionStreams为8的情况如下
在复杂事物事物（each transaction ranging from 500-1000 commands），结果如下。
以上两种情况，均说明SubscriptionStreams在8的情况下，比默认值1在事务复制，订阅节点的吞吐量会得到大幅度提升。
参考：