Background
后端日志处理系统已经与 Kafka 和 Storm 集群一起到位。
用例
在后端生成并记录特定类型X的多个事件。每个都包含一个 id 说userid.现在这些事件被一个风暴螺栓和提取useid和其他一些字段消耗，比如说userdata并写入卡夫卡中的另一个主题，比如data主题。
现在，其他一些拓扑会使用此data主题。它使用单个userid和不同的userdata查找多个此类事件。如果有n这样的记录，则需要采取一些行动。
问题
如何使用来自 kafka 的一些关键数据在风暴螺栓中聚合？ 有些用户可能会在 20 分钟内达到N记录计数，有些用户可能需要几个小时，具体取决于用户交互，因此后端记录的事件。目标是在此类记录的计数达到某些N时获取所有用户 ID 和相应的使用数据
这不是特定于 Storm 的问题，而是与用户会话管理有关。如果你预计你的系统要面对很多会话，这些会话需要很长时间才能达到一定的状态(在你的情况下达到n事件)，并最终同时积累了大量数据，那么你需要在设计中考虑到这一点，这意味着明智地选择n并围绕它构建大量集成测试，以检查你的系统在负载下是否保持响应。
你可以
- 考虑根据负载和统计数据使
n动态(我想这就是DevOps的全部内容) - 仅存储
n以供userid，并将数据保留在数据库或文件系统中，并在达到临界值时将其恢复n。这在某种程度上与流式拓扑的想法相矛盾，但它开始有意义，特别是如果您需要在处理数据后保留(部分)数据。
并不是说如果要部署软件更新，除了n之外，还需要考虑时间值t因为会话越短，持续部署就越容易。