SQL Server到Azure Cache for Redis百万数据迁移：两种方案对比咨询

问题背景 #

需要将SQL Server中的100万条记录分批次迁移到Azure Cache for Redis，无法一次性完成，需解决迁移中途失败后的断点续传问题，同时评估两种候选方案的优劣。

方案1：自定义C#应用迁移 #

原代码的痛点 #

你提供的逐条写入代码存在两个核心问题：一是单条写入效率极低，网络往返次数过多；二是中途失败后必须从头开始，没有容错机制。

优化后的实现思路（解决断点续传+提升性能） #

针对这两个问题，可通过批量读写+检查点机制优化：

1. 批量操作提升效率：使用StackExchange.Redis的StringSet批量重载方法，一次写入多组键值对，大幅减少网络请求次数，提升吞吐量。
2. 可靠的断点续传：
   • 基于SQL Server记录的自增ID分段（比创建日期更可靠，避免重复或遗漏），每次读取固定批次（比如1000条），写入成功后将当前批次的最大ID作为检查点保存（可存在本地文件、SQL Server表或Redis中）。
   • 应用重启时先读取检查点，从该ID之后继续读取数据，完全避免重复写入和从头开始的问题。
3. 异常重试与失败处理：对批量写入添加重试逻辑（比如用Polly库），单批次写入失败时自动重试，多次失败则记录该批次ID，后续单独处理。

优化后的代码示例：

using StackExchange.Redis;
using System.Collections.Generic;
using System.IO;
using System.Linq;

class RedisMigration
{
    private const string CheckpointFile = "redis_migration_checkpoint.txt";
    private const int BatchSize = 1000; // 可根据Redis性能调整大小

    static void Main()
    {
        var cacheConn = "your_azure_redis_connection_string";
        using var redisConn = ConnectionMultiplexer.Connect(cacheConn);
        var redisDb = redisConn.GetDatabase();

        // 读取上次的检查点，默认从0开始
        long lastProcessedId = LoadCheckpoint();

        while (true)
        {
            // 从SQL Server批量读取下一批数据
            var batchData = FetchSqlBatch(lastProcessedId, BatchSize);
            if (!batchData.Any()) break;

            // 转换为Redis键值对集合
            var redisEntries = batchData.Select(row => 
                new KeyValuePair<RedisKey, RedisValue>($"myKey:{row.Id}", row.Value))
                .ToArray();

            // 批量写入Redis
            redisDb.StringSet(redisEntries);

            // 更新检查点为当前批次的最大ID
            lastProcessedId = batchData.Max(row => row.Id);
            SaveCheckpoint(lastProcessedId);

            Console.WriteLine($"Processed up to ID: {lastProcessedId}");
        }

        Console.WriteLine("Migration completed successfully!");
    }

    // 加载检查点
    private static long LoadCheckpoint()
    {
        if (File.Exists(CheckpointFile) && long.TryParse(File.ReadAllText(CheckpointFile), out var id))
        {
            return id;
        }
        return 0;
    }

    // 保存检查点
    private static void SaveCheckpoint(long id)
    {
        File.WriteAllText(CheckpointFile, id.ToString());
    }

    // 从SQL Server批量获取数据的实现
    private static List<SqlRecord> FetchSqlBatch(long startId, int batchSize)
    {
        // 示例SQL逻辑：
        // SELECT Id, Value FROM YourTable WHERE Id > @StartId ORDER BY Id 
        // OFFSET 0 ROWS FETCH NEXT @BatchSize ROWS ONLY
        // 实际需用ADO.NET或EF Core实现数据读取
        return new List<SqlRecord>();
    }

    // 对应SQL Server记录的实体类
    private class SqlRecord
    {
        public long Id { get; set; }
        public string Value { get; set; }
    }
}

方案1的优势 #

• 完全自定义控制，可灵活调整批次大小、重试策略、键命名规则等细节
• 批量操作大幅降低Redis连接开销，迁移速度比逐条写入提升数倍
• 断点续传逻辑简单可靠，失败后无需从头开始，只需从断点继续

方案2：Azure Data Factory（ADF）迁移的劣势 #

ADF用于这个场景存在不少硬伤，主要包括：

1. 无原生Redis连接器：ADF没有直接对接Azure Cache for Redis的组件，必须通过Web活动调用Redis REST API，或借助Azure Function中转写入，额外增加了架构复杂度和维护成本。
2. 逐条写入效率极低：如果用ADF逐条调用Redis API，100万条记录会产生100万次HTTP请求，网络延迟和开销极大，迁移速度会非常慢，远不如自定义应用的批量Redis操作。
3. 断点续传与容错复杂：ADF的重试机制是针对整个活动的，若单条记录写入失败，需要额外配置死信队列来收集失败数据，恢复时还要手动排查失败点，远不如自定义应用的检查点机制直观可控。
4. 成本更高：ADF按活动运行时间和调用次数计费，大量的逐条API调用会导致成本显著上升，同时还要承担Azure Function的额外费用（如果用中转的话）。
5. 灵活性不足：无法自定义复杂的数据转换、键的生成逻辑，若需要对SQL数据进行预处理（比如序列化复杂对象），ADF的处理能力远不如自定义代码灵活。

最终建议 #

优先选择优化后的方案1，它在迁移效率、容错能力、灵活性上都远优于ADF方案。如果必须使用低代码工具，可以考虑ADF结合Azure Function实现批量写入Redis，但仍需自行开发批量逻辑和断点处理，复杂度并不低。

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