问题标签 [reliability]

我已经考虑过如何确保将特定密钥分发到池中的所有 memcached 服务器。

我目前未经测试的解决方案是创建另一个 memcached 实例，如下所示：

在这种情况下，当某些密钥需要存储在所有服务器上以确保可靠性时，该怎么做？

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

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

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

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

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

我们需要编写能够持续（即在可用时发送新数据）同时将非常大的文件（几个 Tb）发送到多个目的地的软件。一些目的地有到源的专用光纤连接，而有些则没有。

出现几个问题：

• 我们计划为此任务使用 TCP 套接字。为了处理网络中断和连接断开，您会推荐什么故障转移程序？
• 上传完成后应该发生什么：服务器是否应该关闭套接字？如果是这样，那么让另一个守护进程在另一个端口上提供文件校验和是一个好的设计决定吗？
• 除了再次下载它们之外，您能否推荐一种处理损坏文件的方法？也许我可以将它们分成 10Mb 的块并分别计算每个块的校验和？

谢谢。

考虑以下（简化的）代码：

这是可靠、安全和/或良好的做法吗？或者除了使用 const ints 而不是枚举之外，还有更好的方法来实现我想做的事情吗？我真的更喜欢枚举，但代码可靠性比可读性更重要。

我正在构建一个 WCF 路由器，我的客户端使用 Reliable Sessions。在这种情况下，当客户端打开通道时，会发送一条消息（建立可靠会话？）。其内容如下：

这里的问题是标头不包含任何我可以用来查找将消息路由到哪个服务的信息。在 Busatmante 的路由器示例代码中，她通过向端点添加标头来解决此问题：

打开可靠会话时，消息包含此自定义标头。

这很棒; 但是，我需要以编程方式配置客户端。我认为 ChannelFactory Endpoint 会有一个 Header 对象，我可以手动添加我的自定义标题。不幸的是，它没有。因此，我进行了一些搜索，发现了一些通过实现 IClientMessageInspector 来扩展 WCF 的建议，以添加我的标头并将其作为一种行为添加到我的端点。

因此，当我的客户进行服务调用时，消息包含自定义标头，但建立可靠会话的消息仍然没有。

所以我的问题是；如何以编程方式将自定义标头添加到端点，以使可靠会话消息包含它？

非常感谢

长版：

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

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

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

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

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

简洁版本：

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

这似乎是Graph API所期望的一个非常明显的基本事情，但我遇到了严重的困难。我要做的就是获取任何特定 URL 的 ID。他们有一个方法：

这很好用。但如果我尝试另一个 URL，比如我的博客，

它不会像所有示例那样给我一个数字 ID。相反，这个：

如果我尝试使用那个“id”，我会得到 jack（可能是因为查询字符串看起来无法解析）：

那么这是怎么回事？Graph API 只是选择性可靠，还是我误解了什么？我已经在我知道在 Facebook 上很受欢迎的 URL 上进行了尝试，但结果好坏参半。

我需要一种方法来监视用户编辑会话，我正在审查的解决方案之一是让我使用unload事件发送 ajax 请求以通知服务器编辑会话结束。（请参阅：监控用户会话以防止编辑冲突）

我对事件的（相当有限的）阅读unload表明附加到此处理程序的代码必须快速运行，因此通常用于清除对象以防止内存泄漏。

我的问题是，这是否可以足够可靠地用于此目的？

PS。我知道这个async: false选项。

越来越多受到关注的 noSQL 数据库使用主/从模式来提供“可用性”，但它所做的（至少从我的角度来看）是在一个随时会中断的链中创建薄弱环节。- 主人倒下，奴隶停止运作。

这是处理大量数据和平衡读/写的好方法，但从可用性的角度来看？没那么多...

我从一些 noSQL 中了解到，slave 可以轻松地更改为 master，但是在大多数应用程序中这样做会让人头疼。对？

那么你们这些人是怎么照顾这种东西的呢？主/从数据库在现实世界中是如何工作的？

InterBase 的架构导致磁盘写入使数据库处于始终一致的状态——每个软件架构师都应该知道的 97 件事，p87

这个属性在2010年终于常见了吗？

是否有关于存在磁盘错误时数据库稳定性/可靠性的研究？