与分区服务结构有状态服务的一致性

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

由于现有的答案都没有直接回答您的问题(无论建议多么有效),我将回答您的原始问题以备记录:

1. 通常,您会使用某种确定性分区方案,例如范围分区-因此,如果您需要搜索用户“foo”,您将搜索F分区(或E-G分区),而不是每个分区。
2. SF可靠的集合使用可能能够保护您免受竞争条件的副作用的事务。有关详细信息,请阅读以下内容: https://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-services-reliable-collections/#persistence-model

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

由于本例中的客户端应用程序需要立即响应,而不依赖于actor/service的其他状态,我认为无状态服务将是更好的选择。您所依赖的状态是来自外部存储类数据库的数据。

SF中的可靠收集可用于并发事务,服务结构保证了一致性。如果在分区之间使用相同的字典,则不会因分区而面临任何问题。当您需要同时更新两个词典并且每个词典中都有相关数据时,问题变得复杂。在这种情况下,您可以使用“Saga”模式或“Twophase commit”模式。

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

可靠字典:表示键/值对的复制、事务和异步集合。与ConcurrentDictionary类似,键和值都可以是任何类型。