我正在使用Storm，它适用于很多用例。最近我看了Trident，它是 Storm 的高级抽象。它支持一次性处理并使有状态处理更容易。
但现在我想知道.. 为什么我不能总是使用 Trident 而不是 Storm？
到目前为止我读到的：
使用 Trident 代替 Storm 时还有其他缺点吗？因为现在，我认为我上面列出的缺点是微不足道的。
哪些用例不能用 Trident 实现？
后果：
自从我提出这个问题后，我的公司决定先选择 Trident。我们只会在出现性能问题时使用纯 Storm。遗憾的是，这不是一个积极的决定，它只是成为默认行为（当时我不在）。
他们的假设是，在大多数用例中，我们需要状态或仅处理一次，或者我们将在不久的将来需要它。我理解他们的推理，因为从 Storm 迁移到 Trident 或返回不是一个简单的转换，但在我个人看来，没有状态的流处理的概念并没有被所有人理解，这是使用 Trident 的主要原因。
回答您的问题：什么时候不应该使用 Trident？每当你负担得起的时候。
Trident 增加了 Storm 拓扑的复杂性，降低了性能并生成了状态。问自己一个问题：您是否需要 Trident 的“恰好一次”处理语义，或者您能否接受 Storm 的“至少一次”处理语义。只有一次，使用三叉戟，否则不要。
我还想强调一个事实，Storm 保证所有消息都会被处理。有些消息可能只被处理了不止一次。
如果尽可能低的延迟是您的目标，并且您不需要完全一次处理，那么使用 Storm 比 Trident 更好。
Trident 是在 Twitter Storm 之上进行实时计算的高级抽象，在 Storm 0.8.x 中可用。Storm 是无状态流处理框架，Trident 提供有状态流处理。
Chris，由于这两个都是开源技术，所以 trident 作为风暴之上的一个场景的唯一实现，当然，这带来了性能开销。如果三叉戟无法满足您的要求，您可以在风暴之上创建自己的状态实现。Trident 及时产生了更高级别的项目，例如 Trident-ML。
假设我们想做过滤+向元组添加字段。如果我们使用 Storm，我们通常使用 2 个机器人进行过滤，添加字段。所以我们需要再次将元组发送到新的bolt，可能正在使用全局分组。所以这里的nw带宽可能会成为瓶颈。
通过使用 trident，我们可以在单台机器上使用 do above。所以在这种情况下不需要重新组合。除了“恰好一次”/“在东部一次”之外，这样的用例可以区分使用什么等。
三叉戟是一种分组逻辑分组