Azure SQL原始层并发读写处理咨询（基于Azure Data Factory实现）

该场景核心冲突为5分钟一次的高频小批量写入作业，和单次耗时30~60分钟的ODS长时读作业之间的锁冲突、资源争抢问题，可按照优先级选择以下适配方案：

1. 只读副本分流读请求（优先级最高，改动最小） #

• 为原始层Azure SQL Database开通只读副本，将ODS层所有数据读取请求全部切到只读实例上，主库仅承担5分钟一次的源端同步写入负载，完全避免读写资源争抢
• 改造成本极低：仅需将Azure Data Factory的数据源连接串替换为只读副本的专用端点即可，无需修改数据同步、拉取的业务逻辑，主从同步延迟通常在秒级，完全满足ODS层的数据时效性要求
• 成本可控：只读副本可选择比主库低1~2档的计算配置，只要能支撑ODS拉取的查询负载即可，不会产生过高额外成本

2. 调整事务隔离级别规避锁冲突（无额外成本的轻量方案） #

如果暂时不需要新增只读副本，可通过调整隔离级别解决锁冲突问题：

• 优先在库级别开启读提交快照隔离（RCSI），或者在ADF的查询语句开头执行SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
• 开启后读操作不会申请共享锁，不会阻塞写入操作，也不会读到脏数据，会自动从版本存储中读取一致性的历史数据版本，完美适配长时读和高频写并行的场景
• 注意提前扩容tempdb空间，版本存储会占用tempdb资源，建议tempdb容量配置为库总容量的30%以上

3. 拉取逻辑优化+时序错峰（调度层面的补充方案） #

配合上述方案使用可进一步降低负载冲突：

• 统计源端同步作业的实际执行窗口（通常单次增量同步耗时很短），将ADF的ODS拉取作业启动时间错开同步执行窗口，避免高峰期争抢IO/CPU资源
• 将ODS全量拉取逻辑改为增量拉取，对接Azure SQL内置的*变更跟踪（Change Tracking）或变更数据捕获（CDC）*能力，每次仅拉取上次同步后新增/变更的数据，可将单次拉取耗时从小时级压缩到分钟级，大幅降低读操作的资源占用时长

4. 资源组隔离兜底 #

• 配置Azure SQL的资源治理器（Resource Governor），给源端同步写入作业、ODS读作业分配独立的资源池，分别划定CPU、IO、内存的占用上限，避免某一类作业占满全部资源导致另一类作业超时
• 可按写入优先级更高的原则配置，比如给同步作业分配60%的资源配额，给ODS读作业分配40%的资源配额，避免源端同步延迟超标

内容的提问来源于stack exchange，提问作者suny sinha