问题标签 [fault-tolerance]

我将构建一个要减少单点故障的系统，并且我需要一个数据库。是否有任何（免费）关系数据库系统可以很好地处理多主设置（即易于添加和删除节点的地方），还是使用 NoSQL 数据库更好？

据我了解，键值存储会更好地处理这个问题。对于多主（集群）设置，您推荐什么数据库系统？

我目前正在开发一个服务器应用程序，如果我们同意尝试并保持一定水平的服务。我们要保证的服务级别是：如果服务器接受请求并且服务器向客户端发送确认，我们希望保证请求会发生，即使服务器崩溃。由于请求可以长时间运行并且确认时间需要很短，我们通过持久化请求来实现这一点，然后向客户端发送确认，然后执行各种操作来满足请求。随着动作的执行，它们也会被持久化，因此服务器在启动时知道请求的状态，并且还有与外部系统的各种协调机制来检查我们的日志的准确性。

这一切似乎都运行得很好，但我们很难有任何信念这样说，因为我们发现测试我们的容错代码非常困难。到目前为止，我们已经提出了两种策略，但都不是完全令人满意的：

• 让外部进程监视服务器代码，然后尝试在外部进程认为是测试中的适当点时将其终止
• 向应用程序添加代码，使其在某个已知的关键点崩溃

我对第一个策略的问题是外部进程无法知道应用程序的确切状态，因此我们不能确定我们是否遇到了代码中最有问题的点。我对第二种策略的问题，虽然它可以更好地控制故障是否发生，但我不喜欢在我的应用程序中注入故障的代码，即使是可选编译等。我担心过分看故障太容易了注入点并将其滑入生产环境。

我们有一个 Web 服务器，我们将在该服务器上启动许多应用程序。它们都将共享数据库和 memcached 服务器，但每个应用程序都有自己的 mySQL 数据库，并且每个应用程序的所有 memcached 键都带有前缀。

可能的情况：

如果我们集群中的 memcached 服务器出现故障，我们希望通过电子邮件/iphone 推送通知或任何其他适当的方式自动联系某人（操作系统管理员）。

如果我们要在我们的服务器上为我们的客户安装 150 个相同的应用程序，并且一个 memcached 服务器死了 - 所有 150 个应用程序都会单独发现这一点并联系我们的系统管理员，他们肯定会考虑找一份新工作在早上 4 点 15 分收到 150 条消息时，他或她不会被吵醒。

可能的解决方案：

一种想法是设置一个外部服务器来进行错误处理，该服务器获取发送的 $_POST 或 cURL 请求，并根据实际错误消息的严重性处理错误消息的存储。它当然会在收到错误调用时进行检查，如果同一个 memcached 服务器已被报告为离线，则无需向系统管理员发送垃圾邮件并发出额外的提醒......

问题：

• 关于如何处理错误的好方法是什么？
• 业内大佬们是怎么处理的？

谢谢！

我一直在研究许多作为 Windows 服务或计划任务运行的应用程序。

现在，我想确保这些应用程序具有容错性和可靠性。例如; 我有一个每小时运行的服务。如果服务在运行或运行时崩溃，我希望应用程序在同一时期再次运行（这涉及到一些事情，包括数据处理的事务），以避免数据丢失。此外，我喜欢程序以详细报告错误。我的目标是避免数据丢失并且不落后于运行程序。

我已经构建了一个用户可以导入到项目中的类库。库应该保存程序运行实例的信息，即。程序读取和写入运行间隔、运行状态等信息。这些数据存储在数据库中。

我很好奇，是否有一些最佳实践可以使计划任务/ Windows 服务具有容错性和可靠性。

编辑：我说的是不同服务器上的独立任务或服务。我的目标是确保服务继续运行，报告任何故障并从中恢复。

长版：

我是 erlang 的新手，正在考虑将它用于可扩展的架构。我发现该平台的许多支持者都在吹捧其可靠性和容错性。

但是，我很难准确理解在这个消息在瞬态内存中排队的系统中如何实现容错。我知道可以安排主管层次结构来重生已故的进程，但是我一直无法找到很多关于重生对进行中的工作的影响的讨论。正在运行的消息和在垂死节点上丢失的部分完成工作的工件会发生什么？

当消费者进程死亡时，所有生产者都会自动重新传输未确认的消息吗？如果不是，这怎么能被认为是容错的？如果是这样，是什么阻止了已处理但未完全确认的消息被重新传输，从而不适当地重新处理？

（我认识到这些问题并不是 erlang 独有的；在任何分布式处理系统中都会出现类似的问题。但是 erlang 爱好者似乎声称该平台使这一切变得“简单”..？）

假设消息被重新传输，我可以很容易地设想一个复杂的消息链的下游影响在发生故障后可能变得非常混乱的场景。如果没有某种繁重的分布式事务系统，我不明白如何在不解决每个过程中的重复的情况下保持一致性和正确性。我的应用程序代码必须始终强制执行约束以防止事务被多次执行吗？

简洁版本：

分布式 erlang 进程是否会受到重复消息的影响？如果是这样，重复保护（即幂等性）是应用程序的责任，还是 erlang/OTP 以某种方式帮助我们解决这个问题？

我在 .NET Winforms 中开发了一个报表查看器（它只运行查询并显示结果）。

这适用于报告数据库。然而，上面是一个更大的应用程序的一小部分，它从另一个数据库获取数据。它看起来像这样：

受监控系统的状态发生变化（例如延迟增加）=> 事件作为事务记录到 SQL Server 数据库（称为此数据库 A）=> 这会触发触发器以将相同的事件写入报告数据库。

我不确定这两个数据库之间的差异，它们可能针对不同的目标进行了调整，或者这两个数据库可能存在一些财务甚至政治原因。

无论如何，有人提到报告数据库“在事务上依赖于”主数据库这一术语。这到底是什么意思？报告数据库完全依赖于数据库 A 的事务？这让我想到了一些问题：

1) 我该如何处理报表数据库没有磁盘空间但数据库A仍在向报表数据库触发触发器的情况？将 2) 连接到上述内容是否会很好，如果我将触发器及其数据无法触发到报告数据库中（不确定如何，但从概念上讲...），它会起作用吗？即使这样，这也使系统不是实时的。

在这样的设置中，异常处理是否还有其他危险/问题？

谢谢

我们正在使用 Scala + Akka 开发一个服务器系统，用于为 Android、iPhone 和 Second Life 中的客户端提供服务的游戏。该服务器的某些部分需要高度可用，在多台机器上运行。如果其中一台服务器死机（例如硬件故障），则系统需要继续运行。我想我希望客户有一个他们将尝试连接的机器列表，类似于 Cassandra 的工作方式。

到目前为止，我在 Akka 中看到的多节点示例在我看来似乎集中在可扩展性的概念上，而不是高可用性（至少在硬件方面）。多节点示例似乎总是存在单点故障。例如，有负载均衡器，但如果我需要重新启动其中一台具有负载均衡器的机器，我的系统将遭受一些停机时间。

是否有任何示例显示 Akka 的此类硬件容错？或者，您对实现这一目标的好方法有什么想法吗？

到目前为止，我能想出的最佳答案是研究 Erlang OTP 文档，思考它们，并尝试找出如何使用 Akka 中可用的构建块将我的系统组合在一起。

但是，如果有关于如何在多台机器之间共享状态的资源、示例或想法，如果其中一台机器出现故障，事情会继续运行，我肯定会很感激他们，因为我担心我可能会重新发明轮子在这里。也许有一个多节点 STM 容器可以自动保持共享状态在多个节点之间同步？或者这很容易做到，以至于文档不会费心展示如何做的例子，或者我的研究和实验还不够彻底。任何想法或想法将不胜感激。

Erlang 如何容错，或者在这方面有什么帮助？

我有一个多步骤过程，其中每个步骤都会执行一些网络 IO（Web 服务调用），然后保留一些数据。我想以容错的方式设计它，以便如果服务失败，无论是因为系统崩溃还是其中一个步骤失败，我都能够从最后一个无错误步骤恢复并重新开始。

这是我正在考虑如何解决这个问题（这是相当高的水平）：

1. 将每个步骤的状态（NOT_STARTED、IN_PROGRESS、FAILED）存储在数据库表中
2. 如果步骤失败，将其及其相关步骤标记为“FAILED”并移至下一个非相关步骤
3. 通过读取此表进行恢复（例如在应用程序的引导部分中）

我想知道是否有一些设计模式、框架和算法可以解决这个问题。

NServiceBus 或等效的 ESB 是否适合具有大量不同类型的后台维护类型任务的应用程序？例如：

• 扫描数据库以查找用户生成的内容中出现的某些单词
• 更新存储相对昂贵查询结果的数据库表
• 为内容创建/维护外部索引
• 发送预定事件的事件通知电子邮件。

我的想法是使用某种任务调度程序（Windows 内置的、Quartz.NET 或我自己的基于数据库的解决方案）定期将不同类型的消息发布到总线上。时间可以短至一分钟，也可以长至几天。我想使用总线的原因是，当系统变得更大、更繁忙以及任务变得更加频繁或资源密集时，我可以扩展订阅者的数量。只要我始终至少有两个订阅者在运行，它也会提供冗余。

明显的替代方法是编写我自己的由调度程序触发并执行工作的 Windows 服务，但我觉得使这种规模超出单台机器并提供容错可能比使用 ESB 作为管道更困难.

这听起来像一个合理的方法吗？替代建议？

TIA