是时候同步 IIoT 系统的一致性了

分布式系统设计中一个重要的（也是激烈争论的）话题是使用哪种一致性模型。一致性模型影响系统设计的许多部分，选择其中一个会影响系统可用性和网络故障鲁棒性等。此博客适用于希望更好地了解保持或不保持一致意味着什么的系统架构师。

首先，让我们澄清一下，这个博客不是关于 ACID (https://en.wikipedia.org/wiki/ACID) 中的“C”。 ACID 一致性确保对数据存储的更新根据一组约束是有效的。本博客重点介绍了描述在分布式存储之间复制数据时会发生什么的一致性。事实证明，ACID 确实 说点什么，但它是“I”（隔离），而不是“C”。令人困惑？有一点，但请耐心等待。

隔离也称为强一致性 .当系统具有强一致性时，分布式存储之间的所有写入和读取对于该系统中的每个应用程序都以相同的顺序执行。这是一种复杂的说法，当一个应用程序写一些东西时，所有在之后读取的应用程序 写入，保证看到新数据。

事实证明，这在许多系统中是一个非常有用的属性。它确保没有两个人可以从购物网站订购同一台冰箱，即使他们同时购买也是如此。强一致性在全局强制执行相同的操作顺序 ，所以两个购买总是由每个人按相同的顺序处理。实际上，这意味着第二次购买尝试肯定会看到冰箱缺货。

强一致性听起来很不错，那么为什么不是所有系统都使用它呢？这是因为称为 CAP 定理 (https://en.wikipedia.org/wiki/CAP_theorem)。首先，快速说明：CAP 受到许多人的批评是有道理的，因为它描述复杂分布式系统的行为太简单了——所以在使用它时要小心——但它确实为讨论一致性模型提供了一个有用的框架。我不会详细介绍 CAP，因为互联网上有很多资源可以做得比我希望在这里做的要好得多。

总之，CAP 告诉我们当应用程序暂时失去“交谈”能力时，或者换句话说：当网络出现故障时，分布式系统中会发生什么。事实证明，一个系统不可能具有强一致性和 无论连接丢失如何，始终保证正常运行时间。无赖。

这听起来很复杂，但实际上非常直观。还记得系统中所有操作的强一致性需要一个全局顺序吗？这意味着阅读必须 查看每个人以前的所有文章。如果并非所有应用程序都已连接，则无法保证这一点。一个应用程序可能已经订购了一台冰箱，但如果不是所有应用程序都收到了此订单，则它们无法订购新订单。这会导致购物网站停机！

可以通过在问题上投入更多资源来缓解停机时间，例如进行数据库复制（更多存储）或部署冗余 Web 服务器（更多计算）。今天，这在公共云基础设施中几乎是微不足道的，尽管当系统有许多活动部件时，这会变得非常昂贵和复杂，比如微服务架构。当系统不在云上运行时，添加更多资源绝非易事，因为存储、计算和带宽在非云环境中都受到更多限制。

因此，虽然强一致性对于应用程序来说很方便，但它对基础设施（和你的钱包！）来说是一种负担。为了解决这些问题，聪明的人提出了在一致性方面不那么迂腐的解决方案，但从应用程序的角度来看仍然可行。我们正在谈论的是“最终一致性”。是时候进行另一个定义了。

当给定项目没有更新时，系统最终是一致的，所有应用程序最终都会看到相同的值。或者通俗地说：如果等待的时间足够长，每个人最终都会看到相同的数据。这意味着应用程序能够同时读取和写入，并且即使在网络关闭时也能够这样做！最终，系统的基础架构会为应用程序提供所有更新。

由于应用程序不必相互等待，最终一致系统的正常运行时间理论上是无限的——前提是您的应用程序不会崩溃，也不会发生断电。然而，无穷大并不实用；一段时间后，您确实希望您的应用程序重新连接。因此，最终一致的系统通常会限制达到一致所需的时间。当该限制到期并且应用程序没有机会同步时，就会发生故障恢复。

可用性并不是最终一致系统的唯一优势。因为读取和写入不需要同步，就像强一致性系统一样，所以它们要快得多。缺乏同步也支持直接的对等通信，这进一步提高了性能，同时也提高了健壮性，因为它消除了对引入单点故障的中心化消息代理的需要。

虽然最终一致性不适用于购物网站，但考虑到它的优势（可用性、性能、稳健性、资源效率）时，它在关键任务系统中被大量使用也就不足为奇了。

RTI Connext 产品套件是 OMG DDS 标准的领先实现，该标准被广泛部署为任务关键型工业物联网系统中的协议。 OMG DDS 与其他连接协议的一个很大区别在于，DDS 的行为就像一个分布式数据库，在应用程序之间持续同步，而其他协议通常提供一个接口来发送消息并将状态管理留给应用程序。

如果您认为分布式数据库听起来像是必须处理一致性问题，那么您是对的。 RTI Connext DDS 必须不断平衡可用性和性能与一致性，才能在最苛刻的关键任务环境中工作。默认情况下，RTI Connext DDS 使用最终一致性来保证使用它构建的应用程序不会在网络出现故障时停止工作，同时确保所有应用程序最终共享相同的“世界”视图。

现在您看到了听起来像“一致性”这样抽象的东西是如何产生深远的影响，并且应该被视为早期系统设计中的一个重要主题。不幸的是，它永远不会像“强一致”或“最终一致”那样简单。 lambda 架构 (https://en.wikipedia.org/wiki/Lambda_architecture) 只是一个示例，它同时使用强一致性和最终一致性来实现两全其美。由于存在如此多的一致性，系统架构师必须就他们的系统能够承受多少一致性做出复杂的决定。

在 RTI，我们的专业服务团队可帮助您做出这些决定、推理后果并配置我们的产品以创建适合您的一致性解决方案。

在此处了解有关 RTI 服务的更多信息：https://www.rti.com/services