0

我们最近有一个端点，它具有通过简单地调用 Bus.HandleCurrentMessageLater() 故障来推迟消息处理的逻辑。在大约 48 小时内，ServiceControl 的 RavenDB 文件增长到 100 多个演出（它只是在相同的几条消息上一直调用 defer）。

以下是我们的 SC 保留设置： 审核消息将在此期限后被删除：14 天。已存档或解决的错误消息将在此期限后删除：10 小时。

  1. 重复调用 Bus.HandleCurrentMessageLater() 的单个端点与每秒处理 1,000 条消息的大规模系统之间有什么区别？ 是否有一些审计配置在简单调用 HandleCurrentMessageLater 时不可用，或者期望具有这种吞吐量的系统可以在不到一天的时间内处理增长超过 50 gig 的 SC 数据库
  2. 在寻找延迟消息的更好方法时，我注意到有很多讨论围绕着用“限制行为”来弃用 NSB 版本 4 和 5 中存在的简单机制。 自定义行为仍然是“已批准”的节流方法吗？
  3. 如果未满足某些条件，是否可以创建一个可以启用/禁用给定处理程序的 CustomCheck？
4

0 回答 0