我正在设计一个系统,该系统应分析大量用户事务并生成汇总度量(如趋势等).系统应该快速,稳健和可扩展.System是基于java的(在Linux上).
数据从生成用户事务的日志文件(基于CSV)的系统到达.系统每分钟生成一个文件,每个文件包含不同用户的事务(按时间排序),每个文件可能包含数千个用户.
CSV文件的示例数据结构:
10:30:01,用户1,...
10:30:01,用户1,...
10:30:02,用户78,...
10:30:02,用户2,......
10: 30:03,用户1,...
10:30:04,用户2,...
...
我计划的系统应该处理文件并实时执行一些分析.它必须收集输入,将其发送到多个算法和其他系统,并将计算结果存储在数据库中.数据库不保存实际输入记录,而只保留有关事务的高级聚合分析.例如趋势等
我计划使用的第一个算法要求最佳操作至少10个用户记录,如果5分钟后找不到10条记录,它应该使用可用的数据.
我想使用Storm来实现,但我更愿意尽可能地将这个讨论留在设计层面.
系统组件列表:
每分钟监视传入文件的任务.
读取文件,解析文件并使其可用于其他系统组件和算法的任务.
用于缓冲用户的10条记录的组件(不超过5分钟),当收集10条记录或5分钟时,是时候将数据发送到算法进行进一步处理.由于要求为算法提供至少10条记录,我想到使用Storm Field Grouping(这意味着为同一个用户调用相同的任务)并跟踪任务中10个用户记录的集合,当然我计划有几个这样的任务,每个任务处理一部分用户.
还有其他组件可以处理单个事务,对于它们,我计划创建其他任务,在解析每个事务时(与其他任务并行).
我需要你的帮助#3.
设计这样一个组件的最佳实践是什么？很明显,它需要为每个用户维护10条记录的数据.键值映射可能会有所帮助,是否可以在任务本身或使用分布式缓存中管理映射？例如Redis是一个键值存储(之前从未使用过它).
谢谢你的帮助
distributed-computing distributed-caching batch-processing redis apache-storm
我正在使用 WebSockets 运行一些测试。
对于测试，我使用了基于 Alchemy-Websockets .NET 的服务器。
Web 应用程序打开多个窗口，用于监视不同的服务和系统。
我对高负载情况特别感兴趣，在这种情况下，服务器必须向客户端发送大量事件，以反映实时更新。我希望 GUI 能够完全响应并在实时用户体验中以网格和图表形式呈现数据。
我在主窗口线程中创建了 WebSocket，并在每条传入消息上添加了一个条目到网格用于显示的数组 (SlickGrid)。为了使 GUI 正常工作，我添加了 20ms 的 setInterval 来渲染网格更新，一切都工作正常，速度非常快。
问题是是否需要或建议将 WebSocket 移至工作线程。在阅读有关工作线程的内容时，我在用例中看到了在线程中处理 I/O 的建议。
我认为只有在阻塞时这才有意义。
据我所知WebSocket是异步的并且不会阻塞。我在某处读到它是由浏览器内部的线程实现的，这是有道理的。
我考虑将 WebSocket 移动到工作线程中，允许工作线程在将数据移动到主窗口之前缓冲或聚合一些数据，如果事件发生率较高，我会看到以下方法：
将 WebSocket 留在主线程上也并不理想。如果服务器负载较高，GUI 将不会优先考虑 WebSocket 传入消息事件。
在工作线程中收集数据，似乎我可能会错过高负载期间的实时更新，因为工作线程正在缓冲。
工作线程的另一个问题似乎是数据重复，这可以通过较新的可传输对象来解决，但不确定所有浏览器对它的支持程度如何。
为什么不在主窗口上托管 WebSocket？
那么最佳实践是什么？