我们最近有一个带有逻辑的端点，通过简单地调用Bus.HandleCurrentMessageLater（）故障来推迟消息处理。在大约48小时内，ServiceControl的RavenDB文件增长到100多个演出（它只是在相同的几条消息上调用）。
以下是我们的SC保留设置：
审核消息将在此期限后删除：14天。
错误已归档或已解决的邮件将在此期限后删除：10小时。
- 重复调用Bus.HandleCurrentMessageLater（）的单个端点与每秒处理1,000条消息的大型系统有什么区别？ 是否存在一些审计配置？在简单地调用HandleCurrentMessageLater时可用，或者期望具有此类吞吐量的系统可以在不到一天的时间内处理超过50场演出的SC数据库
- 在寻找更好的推迟消息的方法的同时，我注意到有很多关于弃用NSB版本4和5中存在的“限制行为”的简单机制的讨论。 自定义行为仍然是“已批准”的限制方法吗？
- 如果未满足某些条件，是否可以创建可以启用/禁用给定处理程序的CustomCheck？