关于你的第2点：
a） 这是在处理过程中中途停止流的最佳方法吗？这样它就不会接收更多的消息了？
如果像您的情况一样，传入的数据速率非常低（每分钟只有几条记录），那么当当前所需的依赖关系系统不可用时，暂停处理输入流是可以的。
在kafka streams中，实现这样一种行为的更好的api是处理器api，正如您自己所暗示的，这实际上不是一种推荐的模式。
即便如此，你还是需要回答几个重要的问题，例如：
如果外部系统长时间停机，流处理应用程序的期望/要求行为是什么？
传入的数据速率是否会在某个时候增加，这可能意味着您需要放弃上面的暂停方法？
不过，如果你想或需要暂停，那么你可以尝试一下。
b） 数据流框架是否设计为中途停止或暂停，以便在一段时间内完全停止使用流？
一些流处理工具允许您这样做。使用它们是否是最好的模式是另一个问题。
例如，您还可以考虑以下替代方案：您也可以自动将外部系统的数据摄取到kafka中，例如通过kafka的内置kafka connect框架。然后，在kafka流中，您可以将导出的数据读入ktable（将此ktable视为来自外部系统的最新数据的不断更新的缓存），然后在原始低速率输入流和此ktable之间执行流表联接。这样的流表连接是一种常用（也是推荐的）模式，可以用边数据丰富传入的数据流（免责声明：我写了这篇文章）；例如，使用最新的用户配置文件信息丰富用户单击事件流。与当前查询外部系统并结合暂停行为的设置相比，这种方法的优点之一是流处理应用程序将与外部系统的可用性（和可伸缩性）分离。

对于传统的消息代理来说，只有一个消费者（即独占队列）时才是公平的。一旦队列被多个使用者共享，就有可能出现消息传递无序的情况。这是因为任何一个使用者都可能无法处理和确认消息，从而导致该消息被放回共享队列的头部，并随后被传递（无序）到另一个使用者。kafka使用主题分区（在传统的消息代理中不存在）保证多个消费者之间的有序并行消费。