我正在从事一个项目，其中有连续的事件流。有许多并发用户可以创建/更新/删除规则，并在流与这些规则匹配时收到警报。
为此，我使用了 Esper，从规则动态生成 EPL 语句并注册它们。这很容易出错，因为规则有时很复杂并且无法动态转换为 EPL。这也是不可扩展的。
处理这个问题的正确方法是什么？是否有针对此类用例的标准方法/库。
谢谢你
复杂的事件处理引擎通常用于解决复杂的需求。正如名字所说，我们正在寻找事件和时间之间的复杂关系，因此它的事件处理也很复杂。
简单的事件处理将满足简单的需求。简单的需求只需两个场景即可测试。例如，假设我们要查找温度超过 100 的事件。Esper EPL 中的设计是“select * from Event(温度 > 100)”。这可以通过两个或三个场景进行测试：例如，Event={temp=99}、Event={temp=100} 和 Event={temp=101}。
有一些中等复杂性事件处理的用例。这些通常需要 4 到 9 个场景进行测试。例如，假设我们想要查找在一滑动分钟内到达的 100 多个事件（滑动，而不是跳跃）。 Esper EPL 中的设计是“从 Event#time(60) 中选择 count() > 100 的 count()”。现在需要一堆场景来测试这个规则，比如没有事件、100个事件、101个事件、61秒内101个事件等等。这里涉及时间，这使得这些场景更难以描述和测试。
我想说，复杂事件处理适用于中等到高度复杂的事件处理情况。这是您需要首先明确要求的事情。在设计 Esper EPL 之前，您需要确定事件到达和时间流逝的不同场景。
需求驱动工具。埃斯珀确实可以很好地处理更复杂的要求，但有一个学习曲线。根据我的经验，扩展是可以完成的，但需要规划。当用一句话谈论低延迟分析和扩展时，没有灵丹妙药的简单方法。 Esper 具有高可用性，但这不是免费的，但可以在 Kafka 堆栈中很好地扩展。
有一个名为 StreamingFlow4J 的开源项目在 Esper CEP 中解决了这个问题。它可以轻松地在Epl规则中进行CRUD操作。