与分区 Service Fabric 有状态服务的一致性答案

【问题标题】：Consistency with partitioned Service Fabric stateful service与分区 Service Fabric 有状态服务的一致性
【发布时间】：2016-08-03 02:24:39
【问题描述】：

让我们举一个简单的例子。我有一个管理用户的有状态服务。它有一个可靠的字典，可以将 UserID 映射到一些数据，包括用户名。

在此服务的 RegisterUser 方法中，我们要检查用户名是否未被使用。当服务是单例时，这很简单，但是当它被分区时，我们最终会遇到几个问题：

我正在寻找有关处理此类情况的可能方法的一般建议。我可以想象这种问题会经常发生在分区数据上。

【问题讨论】：

【解决方案1】：

这通常通过本质上是原子的外部数据存储来解决。使用 SQL 数据库之类的事务性数据存储来存储用户名/ID。这将允许您执行诸如创建唯一约束以强制这些用户名的唯一性。

【讨论】：

【解决方案2】：

由于现有答案都没有直接解决您的问题（无论是有效的建议），我将回答您的原始问题以作记录：

通常您会使用某种确定性分区方案，例如范围分区 - 例如，如果您需要搜索用户“foo”，您将搜索 F 分区（或 EG 分区）而不是每个分区。李>
SF 可靠集合使用可能能够保护您免受竞争条件副作用影响的事务。阅读本文了解更多详情：https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-services-reliable-collections/#persistence-model

您的标题谈到了一致性级别 - Service Fabric 中的所有操作都是高度一致的，这意味着在确认之前将在所有副本中提交写入。

【讨论】：

我的问题一般来说是关于对某些不是“主键”的数据施加唯一约束。我相信这在分区的有状态服务中是不可能的。在此特定示例中，可以使用用户名作为“主键”。我们可能希望允许用户更改他们的用户名，在这种情况下，我们可能不得不将用户数据从一个分区复制到另一个分区，这在事务上很难做到。

【解决方案3】：

由于这种情况下的客户端应用程序需要立即做出不依赖于参与者/服务的其他状态的响应，我认为无状态服务将是更好的选择。您依赖的状态是来自外部存储（如数据库）的数据。

【讨论】：

【解决方案4】：

SF 中的可靠集合可用于并发事务，Service Fabric 保证了一致性。如果您在分区中使用相同的字典，则不会因分区而遇到任何问题。当您需要同时更新两个字典并且您在每个字典中都依赖数据时，问题变得复杂。在这种情况下，您可以使用“Saga”模式或“Twophase commit”模式等模式。

更多信息请参考https://docs.microsoft.com/en-gb/azure/service-fabric/service-fabric-reliable-services-reliable-collections#persistence-model：可靠集合提供了开箱即用的强一致性保证，使推理应用程序状态更容易。强一致性是通过确保事务提交仅在整个事务已登录到多数仲裁副本（包括主副本）后完成来实现的。为了实现较弱的一致性，应用程序可以在异步提交返回之前向客户端/请求者确认。

可靠字典：表示键/值对的复制、事务和异步集合。与 ConcurrentDictionary 类似，key 和 value 都可以是任意类型。

【讨论】：