网络农场中的 nHibernate 策略
我们当前的项目是一个新的 MVC 网站，该网站将主要使用 WCF 服务通过 Web 服务访问第三方计费系统以及用于用户个性化的小型 SQL 数据库。 WCF 服务使用 nHibernate 作为 SQL 数据库。
我们希望实现某种网络场来实现负载平衡以及故障转移和维护。如果有多个 WCF 服务正在运行，我正在尝试确定处理 nHibernate 缓存和数据库并发性的最佳方法。
我一直在考虑的一些场景...
1) 多个 IIS 服务器，一台 WCF 服务器。使用此设置，WCF 服务器将成为单点故障，但 nHibernate 缓存或数据库并发不会出现问题。
2）多个IIS服务器，每个服务器都有自己的WCF服务。这消除了单点故障，但现在一台机器上的 nHibernate 将不知道另一台机器所做的数据库更改。
第 2 点的一些解决方案是使用 IStatelessSession，因此我们不进行任何缓存，并且 nHibernate 始终直接从数据库获取。这可能是最可行的，因为我们的个性化数据库中的对象很少。我还在考虑二级缓存，例如 memcached 或 Velocity，但对于这个系统来说可能有点过分了。
我将其放在那里是为了看看是否有人有进行此类架构的经验，并获得一些解决方案的想法。谢谢！
Our current project at work is a new MVC web site that will use a WCF service primarily to access a 3rd party billing system via a web service as well as a small SQL database for user personalization. The WCF service uses nHibernate for the SQL database.
We'd like to implement some sort of web farm for load balancing as well as failover and maintenance. I'm trying to decide the best way to handle nHibernate's caching and database concurrency if there are multiple WCF services running.
Some scenarios I've been thinking about...
1) Multiple IIS servers, one WCF server. With this setup, the WCF server would be a single point of failure, but there would be no issues with nHibernate caching or database concurrency.
2) Multiple IIS servers, each with it's own WCF service. This removes a single point of failure, but now nHibernate on one machine would not know about database changes done by another machine.
Some solutions to number 2 would be to use an IStatelessSession so we're not doing any caching and nHibernate is always fetching directly from the database. This might be the most feasible as our personalization database has very few objects in it. I'm also considering a 2nd-level cache such as memcached or Velocity, but it may be overkill for this system.
I'm putting this out there to see if anyone has experience doing this sort of architecture and to get some ideas for a solution. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我是否在这里遗漏了一些东西，我在网络服务器上没有看到 nhibernate 的问题。
应用程序缓存不会成为问题，因为每个 nhibernate 框都会保留自己的缓存，该缓存将从数据存储区填充。查看创建一个可以监视的表，以了解执行缓存刷新的原因。我们过去使用 .net 2.0 中的 CacheDependency 类来执行此操作，该类将检测列的更改，然后从缓存中删除相关项目。因此，如果用户插入新产品，缓存将被删除，下一次获取产品的调用将再次加载缓存。它很旧，但请查看：http://msdn.microsoft.com/ en-us/magazine/cc163955.aspx#S2 的概念。干杯
am i missing something here, i don't see a problem with nhibernate on the webservers.
application cache would not be a problem as each nhibernate box would keep it's own cache which would be populate from the datastore. look at creating a table that can be monitored for reasons to do a cache refresh. we used to do this using using CacheDependency class in .net 2.0 that would detect changes to a column and then remove the relevant item from the cache. so if a user inserts a new product, the cache would be dropped and the next call to get the products would load the cache again. it's old but check out: http://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2 for the concept. cheers
我建议不要进行缓存，直到不进行缓存成为问题为止。您的数据库将进行自己的缓存，以节省您重复搜索相同数据的时间，因此您唯一需要担心的是网络上的数据。从你的描述来看，你不会有什么问题。如果您达到了这样做的阶段，请使用分布式缓存 - 允许您的服务器单独缓存将导致您在刷新时出现数据弹跳问题。
I would suggest not doing caching until not doing caching becomes a problem. Your DB will do its own caching to save you searching for the same data repeatedly, so the only thing you have to worry about is data across the wire. Judging by your description, you're not going to have a problem there. If you ever get to a stage where you do, use a distributed cache - allowing your servers to cache separately will cause you bouncing data problems on refresh.