如何在C#中高效实现大内存表行子集的异步变更监听？

需求背景 #

• 内存数据库维护1000万-5000万条数据行
• 需支持至少5万个观察者同时活跃，每个观察者监听约1万行的任意子集，异步等待其中任意行变更
• 每秒约1000-10000行发生写入/更新

目标是实现如下C#接口的高效版本：

interface ITable<TPrimaryKey, TRow>
{
  Task WaitUntilAnyRowChanged(IReadOnlySet<TPrimaryKey> keysToListenTo, CancellationToken ct);
}

现有思路回顾 #

思路1：为行关联TaskCompletionSource #

每行绑定一个TaskCompletionSource，变更时完成现有TCS并生成新实例；观察者通过Task.WhenAny等待所有订阅行的TCS。

• 缺点：对数千个TCS调用Task.WhenAny效率极低，内存分配量大

思路2：为观察者使用AsyncAutoResetEvent #

每行维护List<AsyncAutoResetEvent>，观察者将自身的事件注册到所有订阅行；变更时遍历触发所有关联事件。

• 缺点：写入操作额外增加遍历观察者的开销，可能大幅降低写入速度

思路3：观察者监听所有变更流 #

观察者订阅全量变更键流，自行过滤关心的子集。

• 优点：实现简单，性能可预测
• 缺点：观察者仅关心小子集时效率极低，浪费大量资源

思路4：轮询版本戳 #

每行维护装箱的版本戳，观察者定期轮询订阅行的版本并对比。

• 优点：实现简单，写入无额外开销，GC压力小
• 缺点：变更检测存在轮询延迟，监听键数量增加时扩展性下降

更优解决方案 #

方案A：反向订阅索引+观察者级异步信号（思路2优化） #

核心是将"行维护观察者信号"改为"行维护观察者ID映射"，每个观察者仅持有一个异步信号：

1. 数据结构：
   • 用ConcurrentDictionary<TPrimaryKey, ConcurrentHashSet<Guid>>存储「行主键→订阅该行的观察者ID」映射
   • 用ConcurrentDictionary<Guid, (AsyncAutoResetEvent Signal, IReadOnlySet<TPrimaryKey> Keys)>存储「观察者ID→自身信号+订阅键集合」
2. 接口实现：
   • 生成唯一观察者ID，创建AsyncAutoResetEvent，将ID注册到所有订阅行的HashSet中
   • 等待Signal.WaitAsync(ct)，完成后从所有订阅行的HashSet中移除ID，并清理观察者字典记录
3. 变更处理：
   • 行更新时，取出该行的观察者ID集合，遍历触发每个观察者的Signal.Set()

优势：

• 写入开销可控：仅需查找观察者集合（O(1)），遍历开销取决于该行的订阅者数量（若平均每个行被10个观察者订阅，每秒10000行更新仅需遍历10万次，完全在承受范围内）
• 内存开销低：每个观察者仅一个异步信号，远低于原始思路2
• 变更即时通知，无延迟

注意点：

• 需处理CancellationToken触发时的订阅清理，避免内存泄漏
• 用并发集合保证线程安全

方案B：分区变更流+本地过滤（思路3优化） #

通过哈希分区缩小观察者的处理范围，解决全量流的低效问题：

1. 数据结构：
   • 将主键按哈希值分为N个分区（比如100个），每个分区对应一个Channel<TPrimaryKey>
   • 实现哈希函数Func<TPrimaryKey, int>计算主键所属分区
2. 接口实现：
   • 计算订阅键的分区并去重，订阅对应分区的Channel
   • 用Task.WhenAny等待任意分区的变更，检查变更键是否在订阅集合中，是则完成Task
3. 变更处理：
   • 行更新时，计算分区并将主键写入对应Channel

优势：

• 写入开销极低：仅计算分区+写入Channel，O(1)操作
• 观察者过滤范围大幅缩小（100个分区的话，每个观察者仅需处理约20个分区的变更，过滤量从每秒10000行降至200行）
• 利用Channel的高效异步特性，支持高并发观察者

注意点：

• 分区数量需根据业务调整：过多会增加订阅复杂度，过少则过滤开销仍大

方案C：版本戳+增量通知（思路4异步优化） #

保留版本戳的低GC优势，结合异步通知消除轮询延迟：

1. 数据结构：
   • 每行维护值类型long版本戳（无需装箱，减少GC）
   • 全局维护Channel<(TPrimaryKey Key, long NewVersion)>推送变更信息
   • 观察者本地存储Dictionary<TPrimaryKey, long>记录订阅键的上次版本
2. 接口实现：
   • 先同步检查订阅键的当前版本，若有更新直接返回已完成Task
   • 若无更新，订阅全局Channel，遍历变更项检查是否符合条件，是则更新本地记录并完成Task

优势：

• 写入开销低：仅更新版本戳+写入Channel
• 变更即时通知，无轮询延迟
• 内存开销小，GC压力极低

注意点：

• 高并发下全局Channel可能成为瓶颈，可结合方案B的分区思路拆分为多Channel

方案选择建议 #

• 若对变更延迟要求极高，且每行订阅者数量可控：优先选方案A
• 若写入性能是第一优先级，且订阅键分布均匀：优先选方案B
• 若追求低GC和简单实现，可接受少量过滤开销：优先选方案C

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