我有一个Web应用程序集群（Java + Tomcat），应用程序生成事件。体积不是那么高，但每天的事件不到1000万（不均匀地分布着山峰和山谷）。
我们需要在用户界面上显示事件的计算聚合。目前，这是通过对每个页面显示上具有许多索引的大表运行数据库查询来完成的。
是否有良好的架构方法来保持事件流并计算（动态）并保持总数，如平均值，平均值，最小值，最大值等？
实时并不重要，但近实时是必须的。例如，低于1分钟的延迟是可以接受的。
答案 0 :(得分：2)
您可以使用推模型或拉模型。 （或者如果您更喜欢这些条款，则主动/被动。）在这两种情况下，您都有一个集中的记录管理员，必须汇总您想要的数据。在推送模型中，您的分散服务/服务器/应用程序将定期将更新推送到您的记录管理员。在拉模型中，您的记录管理员将定期查询您的分散服务并请求更新。
在推送方案中，每个独立服务/服务器/应用程序都会记录自己的事件计数器。一旦事件计数器超过某个阈值，它将通知记录管理员新的状态。例如，他们可以每100或1000或delta事件推送更新。因此，（假设没有不可检测的故障）记录管理员总是知道系统中发生了多少事件加上或减去你的delta。这提供了很好的性能，因为每当有人想要访问事件记录时，所有数据都已经聚合。一个缺点是系统的开销很小但是持久性很高。另一个原因是你永远不知道服务是否已经失败，或者它最近是否有很多事件（加/减三角洲）。
在拉动情景中，您的分散服务仍保留日志，但在记录管理员请求更新之前，他们不会做任何事情。当您想知道系统状态时，记录管理员必须查询系统中的每个人，获取他们的响应并汇总结果。这可能是最容易实现的，而且一个积极的方面是在您实际请求更新之前没有系统开销。缺点是更新请求会在系统发生时对系统造成很大的拖累（因为每个人都会丢弃所有内容并在整个系统中产生流量）。出于同样的原因，当请求进入时，它会花费一些时间来生成更新。
现在，这两种方法都与实施方法无关。这些方法中的任何一种都可以使用完全平坦的拓扑实现，其中每个服务都直接与您的记录管理器通信。或者，您可以形成服务层次结构，以便层次结构中的每个父级负责聚合其子级的数据。在这方面你想要做的事情实际上取决于系统需要多快的速度。