SqlServer 复制中将大事务分成小事务分发的方法
在sql server 复制中，当在发布数据库执行1个大事务时，如一次性操作 十万或百万以上的数据。当操作数据在发布数据库执行完成后 ，日志读取器代理将扫描事务日志，一次性传递到分发数据库中。若上个事务未传递完成，连续执行多个事务，日志读取器代理将扫描日志中多个事务同时传递到分发数据库中，默认最大扫描500个事务。如果执行多次上百万或千万的数据将堵塞很久。
日志读取器代理可配置将大事务划分为多个小事务进行传递到分发数据库中，分发队列则按照小事务分发到订阅数据库中，这样数据就很快同步！
在没改代理参数之前，本人执行1次插入30万的数据到发布表中。插入完成后，监控发布到分发的记录如下：
可以看到，这1个事务的命令都得一次传递完才能分发，而分发又消耗时间，这里等待太久影响事务的实时性。
如果还有其他事务，默认500（参考参数：-ReadBatchSize），也将一起传递，耗时较长。
现在更改参数，扫描到 1000 左右的命令就即时分发，需要设置如下参数：
-MaxCmdsInTran number_of_commands
注：该参数只能添加到日志读取器代理中，在代理配置文件没有此参数的设置。
添加后重启 日志读取器代理。
再次插入 30 万的数据！~到监视器查看
可以看到，命令达到 1000 左右就进行分发了，此时查看订阅数据库，数据也同步过来了，这样就省去了较多扫描命令的时间。
更详细查看每个事务的命令数，如下：
SELECT top 10 A.xact_seqno,A.entry_time,COUNT(*) AS cmds FROM distribution.dbo.MSrepl_transactions A(NOLOCK) INNER JOIN distribution.dbo.MSrepl_commands B(NOLOCK) ON A.xact_seqno=B.xact_seqno GROUP BY A.xact_seqno,A.entry_time ORDER BY cmds DESC
这个参数虽好，但是也可能引起数据的一致性。
如：
在发布更新了一批数据，但是订阅查询时却有不同。
分发事务遇到冲突或者死锁，也导致这部分的数据不一致。
参考：复制日志读取器代理
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
事务分组是什么？ 事务分组是seata的资源逻辑，类似于服务实例。在file.conf中的my_test_tx_group就是一个事务分组。 通过事务分组如何找到后端集群？ 首先程序中配置了事务分组（GlobalTransactionScanner 构造方法的txServiceGroup参数） 程序会通过用户配置的配置中心去寻找service.vgroupMapping .[事务分组配置项]，取得
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo