Azure Service Fabric可靠集合的并发安全转置及方案合理性确认

问题背景 #

我有一个服务，会将大量传入的Orders存入IReliableDictionary。在新订单持续进入时，我需要在程序运行全程维护一个独立的订单有序列表。

请问如何高效且并发安全地将IReliableDictionary中的数据转置为另一个有序集合，以避免死锁且无需每次有新订单时都从头重建有序列表？

编辑：查阅文档后，我认为可通过在事务提交前更新本地内存中的有序集合来实现，代码如下：

using (var tx = this.StateManager.CreateTransaction()) { 
    bool addOk = await orderDictionary.TryAddAsync(tx, 123, someOrderToAdd); 
    if (addOk) { 
        this.SortedOrders.Add(someOrderToAdd); 
    } 
    await tx.CommitAsync(); 
}

能否有人确认我对文档的理解是否正确，且上述实现不会引发并发问题？

你的思路方向是没问题的，但这段代码存在两个关键的并发安全和一致性问题，我来帮你拆解并给出可行的优化方案：

1. 当前实现的核心问题 #

• 事务提交失败会导致数据不一致：如果tx.CommitAsync()执行失败（比如事务冲突、节点临时故障），IReliableDictionary里的新增操作会被回滚，但你已经加到SortedOrders里的订单不会被移除——这就导致内存集合和持久化字典的数据对不上了。
• 内存集合本身不是线程安全的：如果SortedOrders是普通的SortedSet<T>或者List<T>，多个并发请求同时执行Add操作时，会触发竞态条件，轻则导致元素丢失，重则直接让集合损坏抛出异常。

2. 正确的实现方式 #

要保证两个集合的强一致性，同时兼顾并发安全，需要做到这几点：

（1）换用线程安全的内存有序集合 #

首先得把普通集合换成线程安全的实现：

• 如果是基于排序键的有序需求，可以自己用ReaderWriterLockSlim封装一个SortedSet<T>——读操作加共享锁，写操作加排他锁，兼顾性能和线程安全。
• 要是排序逻辑简单，也可以用ConcurrentDictionary存储，之后按需提取值排序，但这种方式适合读少写多的场景。

（2）事务提交成功后再更新内存集合 #

把内存集合的更新逻辑移到事务提交成功之后，这样就能避免事务回滚带来的不一致：

using (var tx = this.StateManager.CreateTransaction()) 
{ 
    bool addOk = await orderDictionary.TryAddAsync(tx, 123, someOrderToAdd); 
    if (addOk) 
    {
        // 先确保事务提交成功，再更新内存集合
        await tx.CommitAsync();
        this.ThreadSafeSortedOrders.Add(someOrderToAdd);
    }
    else
    {
        await tx.AbortAsync();
    }
}

（3）处理服务重启/故障转移后的集合重建 #

Service Fabric服务重启或者故障转移后，内存集合会被清空，这时候需要从IReliableDictionary全量加载数据重建有序集合。可以在RunAsync启动时做这件事：

protected override async Task RunAsync(CancellationToken cancellationToken)
{
    // 服务启动时重建内存有序集合
    using (var tx = this.StateManager.CreateTransaction())
    {
        var enumerator = await orderDictionary.CreateEnumerableAsync(tx);
        using (var e = enumerator.GetAsyncEnumerator())
        {
            while (await e.MoveNextAsync(cancellationToken))
            {
                this.ThreadSafeSortedOrders.Add(e.Current.Value);
            }
        }
    }

    // 后续处理业务逻辑...
}

（4）给事务加重试逻辑 #

Service Fabric的事务很容易因为并发冲突失败，所以要加重试逻辑，避免订单丢失：

// 简单实现一个重试策略，针对临时异常重试
var retryPolicy = new RetryPolicy(
    exception => exception is FabricTransientException,
    retryCount: 3,
    delayBetweenRetries: TimeSpan.FromMilliseconds(100));

await retryPolicy.ExecuteAsync(async () =>
{
    using (var tx = this.StateManager.CreateTransaction()) 
    { 
        bool addOk = await orderDictionary.TryAddAsync(tx, 123, someOrderToAdd); 
        if (addOk) 
        {
            await tx.CommitAsync();
            this.ThreadSafeSortedOrders.Add(someOrderToAdd);
        }
    }
});

3. 额外优化建议 #

• 如果需要支持复杂的范围查询、排序过滤，不如直接用轻量内存数据库（比如LiteDB）替代普通集合，它自带事务和索引，性能和可靠性都更好。
• 高并发场景下，可以把内存集合的更新操作放到后台线程池执行，但一定要保证更新操作的原子性，别搞出异步竞态。

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