MassTransit乐观并发模式下Saga锁定与消息重试异常问题

问题根源 #

1. Redis SAGA的双重并发控制逻辑
   即便设置了ConcurrencyMode.Optimistic，MassTransit的Redis SAGA实现仍会先尝试获取分布式锁来阻止多Pod同时操作同一个Saga实例。锁获取失败时抛出的Unable to lock saga异常，会触发MassTransit内部默认的锁重试逻辑（约1秒间隔），而非你配置的100ms消息重试。

2. 重试策略未覆盖锁冲突异常
   你配置的messageRetry大概率只针对业务异常，没有包含MassTransitException（锁冲突场景）和RedisSagaConcurrencyException（乐观版本冲突场景），导致自定义重试规则未生效。

3. 乐观并发的触发时机
   乐观并发的版本校验是在成功获取分布式锁之后执行的，所以锁冲突是前置竞争问题，和乐观版本冲突是两个不同阶段的并发错误。

解决办法 #

1. 扩展重试策略，覆盖所有并发异常 #

修改重试配置，明确指定需要重试的异常类型，让自定义的100ms间隔生效：

x.UseMessageRetry(r =>
{
    r.Interval(3, TimeSpan.FromMilliseconds(100));
    // 捕获锁失败异常
    r.Handle<MassTransitException>(ex => ex.Message.Contains("Unable to lock saga"));
    // 捕获乐观版本冲突异常
    r.Handle<RedisSagaConcurrencyException>();
});

2. 自定义Redis SAGA的锁参数 #

调整锁的重试间隔和超时，让锁竞争的重试逻辑匹配你的预期：

x.AddRedisSaga<OrderDetailState>(context)
    .ConfigureSaga(sagaConfig =>
    {
        sagaConfig.LockRetryInterval = TimeSpan.FromMilliseconds(100);
        sagaConfig.LockTimeout = TimeSpan.FromMilliseconds(500);
        sagaConfig.LockRetryCount = 3;
    })
    .ConcurrencyMode(ConcurrencyMode.Optimistic);

3. 减少Saga实例竞争概率 #

• 确保消息的CorrelationId路由均匀，避免大量消息集中到同一个Saga实例上；
• 验证消息的幂等性，避免重复消息触发不必要的并发竞争。

重要提示 #

乐观并发（版本校验）和分布式锁是MassTransit Redis SAGA的两层并发控制：锁用于阻止同时操作，版本校验用于防止更新覆盖，两者协同工作而非互斥。多Pod部署下，合理配置重试和锁参数才能达到预期的延迟效果。

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