我正在编写一个REST API,它需要为我的组织的ActiveDirectory提供集成服务,特别是查询用户和组数据,然后在API中为自动完成字段查询提供端点.

我的组织的ActiveDirectory非常大,它有大约130K的用户和组对象.

查询所有这些对象并将它们存储在我们当前的后备存储(MongoDB)中大约需要40分钟.

我们决定检查是否有跳过Mongo使用的选项,并将所有查询的AD对象存储在Web API内存中.

在SO中查看其他问题我意识到Singleton无法工作,因为每次重置IIS应用程序池时,存储在其中的数据都会丢失,然后API无法提供大约40分钟的数据,这是不可能发生的.

我还查看了this问题,它引用了命名空间System.Runtime.Caching.但是,命名空间提供的MemoryCache在重置IIS应用程序池时也会丢失所有数据.

我的问题是 – 是否有任何其他解决方案将来自AD的数据存储在Web API内存中.我们目前希望避免使用持久性存储(关系或文档数据库)来保存信息,但如果没有可行的解决方案,我们可能会坚持使用Mongo(除非提供更好的存储).

最佳答案 从可扩展性的角度来看,内存中的声音听起来很糟糕.如果要对API进行负载平衡,则可能会在内存中拥有此数据的多个副本,但是当API的一个实例处理请求或其他实例时,它们可能会略有不同,从而导致不同的结果.

在内存中,可能推断出一个列表,或者更好的是字典.您可以考虑支持多个节点的Redis服务器,并将其存储在内存中.它类似于字典,因为您将键值对存储为< string,string>. API的所有实例都可以指向同一个Redis群集,因此您可以获得一致性,扩展性和性能.

您还可以考虑具有特殊集合的Service Fabric,它允许您在有状态和无状态服务之间共享状态.与Redis一样,数据被序列化并存储在Service Fabric集群中.它具有很强的容错能力,内置HA和DR.

在性能方面没有什么比单身人士词典更好,所以它取决于你现在和将来需要什么.