问题标签 [reliability]

我正在尝试找出与域套接字一起使用的协议，但找不到有关域套接字可以信任的程度的信息。

数据会丢失吗？消息是否总是按照发送的顺序接收？即使使用数据报套接字？

转移是原子的吗？阅读套接字时，我是否可以相信我一次阅读就获得了整个消息，还是我必须自己检查？

我一直在研究事务性内存及其对系统编程（数据库、操作系统、服务器等）的可行性。我自己使用事务的经验，以及看到很少有社区在实际代码中使用事务，提出了一个问题：什么会说服你，一个编写生产代码的开发人员，在你的工作中使用事务内存？

会是普遍采用吗？高速？提高可靠性？多少？

对于那些还没有见过它们的人，内存事务就像数据库事务一样：操作（显然）并行进行，如果两个事务之间存在冲突（例如它们都写入相同的值），那么其中一个或两个事务将被回滚并重新启动。

事务性内存有几个好处：

1. 可靠性完全摆脱死锁（例如错误顺序锁定）。
2. 性能锁争用较少时速度更快。
3. 可编程性 细粒度的并发控制，无需管理许多同步对象。

然而，即使假设 TM 的实现正确、完整和快速，与锁相比，这个原语也存在已知的缺点。

1. 由于事务可能会执行多次，因此除了通过经验实验之外，更难预测性能。

   我们可以重现性能错误吗？

2. 在正确的实现之间存在一些不同的策略决策，例如，在另一个事务中结束的事务会发生什么？我们现在承诺，还是等待？

   我们能否充分理解代码的局部影响？

3. 为了在回滚的事务中支持不可撤销的行为（例如发送“发射导弹”命令），运行时变得更加复杂。

   我们能否充分理解代码的全局影响？

最后，由于软件实现可能是第一个被使用的（C、C++、Haskell、Clojure 和 Scala 等已经有实现），实际上存在性能问题。在适度争用的情况下，软件事务会带来性能损失。

你的绩效预算是多少？什么时候收益大于潜在成本？

测试可靠 UDP 层的失败场景列表有哪些？我想到了以下几种情况：

• 丢弃数据包
• 丢弃 ACK、NAK 数据包
• 乱序发送数据包。
• 丢弃初始握手包
• 丢弃关闭/关闭数据包
• 重复数据包

请帮助确定可靠的UDP需要处理的其他情况？

试图为分布式系统找到一个商业日志框架。此框架必须允许远程服务器上的 .NET 应用程序记录可以在中央位置收集的消息。如果可能，中央位置应将消息存储在 SQL Server 数据库中。

要求：

1. 能够在远程服务器上启动消息记录，即使网络中断阻止消息立即发送到中央位置。
2. 将消息分派到中央位置应由运行 .NET 应用程序的进程以外的进程处理，以防止 ASP.NET 应用程序或 Web 服务的性能下降。
3. 确保最终将消息传递到中央位置。例如，如果远程服务器在网络没有响应的时间快要结束时重新启动，则在远程服务器和正常网络条件恢复时仍应传送记录的消息。

我正在为小型企业的文档管理系统选择非 SQL 引擎还是常规 SQL 引擎。

我有使用 firebird/sql server 的经验，并且发现了良好的可靠性跟踪（特别是使用 firebird）。

这个市场到处都是蹩脚的“服务器”（克隆制造的 PC，市长），廉价的硬盘，很少使用 RAID 或类似的东西，有些在正常断电的地方，有些没有 UPS，等等...（我将包括到外部服务器的异地自动备份，但不会更改内部设置）。（我知道有关此类正确设置的最终用户教育，但愚蠢的依赖于这一点，所以坚持 te 点）

从设计的角度来看，无模式数据库是适合我的系统的方法，但是，我担心是否有任何实际解决方案（MongoDb、Tokyo Cabinet 等）像 firebird 和 survice 崩溃、故障和滥用，所以数据损坏非常罕见。

该计划是将办公文件存储在那里并提供一个中央存储库。

我在每日构建中运行一个 Visual C++ 控制台测试程序。测试时不时会调用一些被其他开发人员不当更改的函数，陷入无限循环并挂起，从而阻塞构建。

我需要一个尽可能简单的看门狗解决方案。这就是我想出的。在测试程序入口点，我启动了一个单独的线程，该线程连续循环并检查经过的时间。如果超过了某个预定义的时间，它会调用 TerminateProcess()。伪代码：

这个解决方案是否比作为单独的主程序实现的看门狗更糟糕？

当前应用程序使用Simple Java Mail每天发送几封电子邮件，但有些电子邮件从未发送到客户端。

根据应用程序服务器日志，有几个邮件服务器超时，但这并不能解释丢失电子邮件的所有情况。添加重试功能将有助于解决超时问题，但总体上是否有任何其他方法可以提高电子邮件的可靠性？

我们的产品是一个分布式系统。我工作的模块是相当新的、相当严格的、经过良好测试的。它们的开发考虑了最近的最佳实践。其他模块可以被视为遗留软件。

虽然我对我负责的模块中发生的一切保持警惕，但我一直承受着处理从其他模块发送给我的不良数据的压力。本质上，我是一个“快速失败”的原则开发人员，因此，当出现问题时，我通常能够消除模块中出错的可能性。与其说是责备，不如说是为了避免在错误的地方追逐错误而浪费精力。

但我一直反对的论点是：“我们不能让这些东西在生产中失败，客户希望它能够工作，你为什么不解决这个问题”。这将是稳健性的一个论据：在你接受的东西上要自由，在你发送的东西上要保守。

我还应该注意，这些大多是间歇性问题。我们在集成测试中看到它们，但它们很难重现。涉及时间和并发性。

我很难在这两个原则之间取得平衡。部分原因是我担心如果我开始允许和传播异常数据，我会招来麻烦，而且我对我的系统不会有太大的信心。但是，即使其他模块向我发送了错误的数据，我也不能反对保持系统正常工作。其他模块没有得到修复的原因是它们太复杂和脆弱，而我的仍然看起来清晰和安全。但是，如果我不抗拒压力，我的模块将慢慢地背负我一直拒绝的相同问题。

我应该说系统在生产中没有“崩溃”，但我的模块可能只是向操作员显示错误并要求他们联系支持。崩溃将是一个大问题，但如果我清楚地报告错误，那么这不是正确的做法吗？我怀疑我的同行只是不希望客户看到任何问题。但是我的模块拒绝来自我们产品中其他模块的数据，而不是客户输入。所以在我看来，我们只是没有解决问题。

那么，我需要更加务实还是坚守自己的立场？

如果在应用程序运行时它使用的共享库之一被写入或截断，则应用程序将崩溃。移动文件或使用 'rm' 批量删除文件不会导致崩溃，因为操作系统（在这种情况下是 Solaris，但我认为这在 Linux 和其他 *nix 上也是如此）足够聪明，不会删除与该文件，而任何进程打开它。

我有一个执行共享库安装的 shell 脚本。有时，它可用于重新安装已安装的共享库版本，而无需先卸载。因为应用程序可能正在使用已经安装的共享库，所以脚本足够聪明以 rm 文件或将它们移开（例如，当我们知道没有应用程序时 cron 可能会清空的“已删除”文件夹），这一点很重要将运行），然后再安装新的，这样它们就不会被覆盖或截断。

不幸的是，最近一个应用程序在安装后就崩溃了。巧合？很难说。这里真正的解决方案是切换到比旧的巨大 shell 脚本更健壮的安装方法，但是在切换之前有一些额外的保护会很好。有没有办法包装一个 shell 脚本来保护它不被覆盖或截断文件（最好是大声失败），但仍然允许它们被移动或 rm'd？

标准 UNIX 文件权限无法解决问题，因为您无法区分移动/删除和覆盖/截断。别名可以工作，但我不确定需要别名的所有命令。我想像 truss/strace 之类的东西，除了在每个操作之前它检查过滤器是否实际执行它。我不需要一个完美的解决方案，即使是针对故意的恶意脚本也能起作用。

我正在研究在 .NET 中使用 WPF 或将 Silverlight 4 用于连接到 WCF 服务的应用程序的 GUI 前端之间的区别。

我已阅读 Silverlight 4 中的 net.tcp 绑定仅支持传输级别的可靠性。使用 WPF 桌面应用程序，我们可以使用消息级别的可靠性。

实际的区别是什么？如果传输级别的可靠性确保所有 TCP 数据包都能通过，那是否也意味着所有 WCF SOAP 消息也能通过？