如何使我的矩阵乘法Java代码更加自动防故障?

时间:2016-02-20 03:17:22

标签: java multithreading matrix

我正在开发一个项目,在那里我获得了一个可以在分布式系统中运行的Java矩阵乘法程序,该程序运行如下:

usage: java Coordinator maxtrix-dim number-nodes coordinator-port-num

例如:

java blockMatrixMultiplication.Coordinator 25  25 54545

以下是输出结果的快照:

enter image description here

我想用某种故障安全功能扩展这段代码 - 我很好奇如何在运行的矩阵乘法计算中创建检查点。一般的想法是恢复到计算中的位置(但它不需要如此细粒度 - 只是恢复到开始,即row 0 column 0

我的第一个想法是使用日志文件(如Apache log4j),我将记录相关的矩阵状态。然后,如果我们在计算过程中强行关闭应用程序,我们就可以恢复到合理的检查点。

我应该将MySQL用于这样的任务(或者更轻量级的数据库)吗?或者一个基本的日志文件(并使用一些有用的Apache库)是否足够好?感谢任何提示,谢谢

源代码:

MatrixMultiple

Coordinator

Connection

DataIO

Worker

1 个答案:

答案 0 :(得分:3)

如果我正确理解了问题,您只需要在发生崩溃时或在应用程序中途退出的情况下,在单个矩阵计算中恢复您的位置。

最小可行解决方案

最简单的方法是只恢复您主动乘以的两个​​矩阵,但不是你的进度,并在下次加载应用程序时从头开始乘以它们。

过程:

  1. public static int[][] multiplyMatrix(int[][] a, int[][] b)类的MatrixMultiple开头,创建一个文件,让它调用recovery_data.txt,两个数组的状态相乘(参数{{ 1}}和a)。或者,您可以使用一个简单的数据库。
  2. b课程的public static int[][] multiplyMatrix(int[][] a, int[][] b)末尾,在您返回之前,请清除该文件的内容,或者擦除您的数据库。
  3. 当程序最初运行时,很可能接近MatrixMultiple的开头,你应检查文本文件的内容是否为非空,在这种情况下你应该乘以文件的内容,并显示输出,否则照常进行。
  4. 实施说明:

    • 使用简单的文本文件或完整的关系数据库是您必须做出的决定,主要是基于您真正知道的真实世界数据,但在我看来,纺织品在大多数情况下都胜出情况,这是我的理由。您将要按顺序读取数据以重建矩阵,因此关系不是那么有用。数据库更难以使用,而不是太难,但与文本文件相比毫无疑问,并且由于您不会过多地使用查询,因此通过它们通常可能使程序员的方式不能平衡生活更轻松。
    • 考虑如何存储阵列。在文本文件中,您有几个选项,我的建议是将每行存储在一行文本中,用空格或逗号或其他字符分隔,然后在第二个矩阵之前添加一行额外的空格。我认为在crAlexander's Answer here中使用了类似的方法,但我还没有测试过他的代码。或者,您可以使用像JSON这样更复杂的东西,但我认为这样做太过分了。如果您正在使用数据库,那么关系结构也应该为您的数据做出若干逻辑安排。

    战略检查点

    您表示有兴趣通过利用上次程序运行时已经处理过一些计算的可能性来保存一些计算。让我们先来看看在处理完每一行后添加检查点的优点和缺点,我最好能看到它们。

    优点:

    • 如果系统已关闭,请在下次运行程序时节省计算时间。

    缺点:

    • 进行额外写入将使用更多节点(如果分布更多)(或稍后更多)或增加计算的一般延迟,因为您现在必须为每个检查点引入数据库写入操作
    • 实施起来比较复杂(但可能不太多)
    • 如果我对最小可行解决方案的实施有关能够使用文本文件的说法使您确信不必添加RDBMS,那么我将收回有关不利用查询的部分以及所有被访问的内容顺序,所以数据库现在可能是一个更聪明的选择。

    我并不是说检查站肯定不是更好的解决方案,只是因为我不知道它们是否值得,但这是我会考虑的:

    • 您是否希望人们相对于他们将要运行的计算总量频繁地在计算中途退出?如果你认为这个功能会被大量使用,那么添加检查点的专业人员相对于整体减慢计算的速度变得更加重要。
    • 完成人们提供程序的典型计算需要很长时间吗?如果是这样,我在缺点中提到的增加的延迟(百分比)更小,因此可能更容易忍受,但用户已经对性能不太满意,因此取消了那里的一些效果。它还使检查点的论点更加重要,因为它有可能节省更多时间。

    因此,如果您预计会发生相对大量的实例,并且需要相对较长的时间来完成计算,我只会建议像这样的检查点。

    如果您决定使用检查点,请将方法修改为:

    • 在您为数据库生成该行内容的数组上处理每一行之后,或者如果您使用纺织品,在纺织品的末尾,在另一条空行之后将其与最后一个矩阵。

    • 启动时如果您需要完成已经开始的计算,只解析并分发尚未考虑的行,并从数据库中检索其他行的内容。

    实施频繁检查点的快速点:通过将此任务推送到其他线程,可以大大减少添加频繁检查点所带来的额外延迟。这样做会使用更多进程,并且实际产生进程或线程总会有一些延迟,但是您不必等待整个写操作在继续之前完成。

    关于任何此类故障安全方法的实施的快速警告

    如果存在未经检查的边缘情况,这意味着某种无效矩阵会使程序崩溃,这个故障保护现在通过在每次启动时再次尝试来完全阻止程序。为了解决这个问题,我看到了一些明显的解决方案,但也许有些想法可以让你修改我喜欢的方法:

    • 使用大量的try和catch语句,如果您遇到任何类似的错误,这些错误似乎是由格式错误的数据造成的,请擦除您的恢复文件,或修改它以添加一条说明,告诉您的程序将其视为特殊处理案件。对这种特殊情况的一个很好的处理方法可能是在开始时显示两个矩阵,并解释说您的程序可能因内容格式错误而无法将它们相乘。
    • 在解决当前问题时,在文件/数据库中添加程序已退出的次数,如果这不是第一次恢复,请将其视为上述选项中的特殊情况。

    我希望这为您提供了足够的信息,以最合理的方式实现您的故障保护,考虑到您怀疑的实际用途,并注意到也许还有其他方法可以解决这个问题,这些可以同样有自己的利弊列表。