用于处理固定宽度文件的高效模式

发布于 2024-11-16 19:45:44 字数 300 浏览 3 评论 0原文

我有一个案例，我需要读取一个包含接近 100000 条逻辑记录的平面文件。每个逻辑记录由 nx128 个字符部分组成。即，类型 A：3x128，类型 B：4-5 X 128 等，其中最大可能的 n 为 6。

应用程序必须读取文件并处理记录。问题是只有当我们读取每个 nx128 分区的前 52 个字符时才能确定“n”。

您能否建议我可以重复使用的任何设计模式或任何有效的算法来执行此操作？

注意：1. 性能是一个重要标准，因为应用程序每天需要处理数千个文件。 2. 数据不以行分隔。它是一个长串状的图案

需要登录才能够评论，你可以免费注册一个本站的账号。

墟烟 2024-11-23 19:45:44

您可以采用主-工作者（或主-从）模式，其中主线程将负责读取数据的前 52 个字符以确定记录的长度。然后，主设备可以将读取和处理记录的实际工作推迟到工作线程，并再次移至下一条记录以仅读取前 52 个字符。每个工作人员将负责（重新）打开文件并处理特定范围的字符；需要向工人提供此信息。

因为，我还没有看到文件的结构，所以我只能发布一些可能的限制或问题供实现者考虑：

有效且高性能的实现将依赖于为工作线程提供文件指针和Worker 应该处理的数据长度。简而言之，工作线程实际上应该以随机访问模式读取文件，而不是让主线程执行读取（这是串行的）。如果您无法执行随机访问，则您无法做很多事情来优化主从模式。
不建议生成新的工作线程。使用线程池。这也意味着您可以根据池的大小限制打开的文件描述符的数量。
将进一步的请求排队以处理字符范围，以防池耗尽。这样，主服务器可以继续执行其工作，直到读取最后一条记录。
记录之间的依赖关系将要求您序列化处理记录。如果每个记录都可以在它自己的线程上处理，而不需要其他线程的结果可用，那么采用这种方法应该不会遇到任何困难。