Windows – 开发群集感知非基于Web的企业应用程序中的常见问题

我将首先回答问题的持久连接部分,因为它更容易.所有良好的网络负载平衡解决方案(包括内置于Windows Server中的Microsoft NLB服务,但也包括F5 BigIP等负载平衡设备)都能够在连接期间“粘附”从客户端到特定群集节点的各个连接.在微软的NLB中,这被称为“ Single Affinity”,而其他负载均衡器称之为“Sticky Sessions”.有时会有一些警告(例如,如果将新成员添加到群集中,Microsoft的NLB将断开连接,尽管单个连接永远不会从一个主机移动到另一个主机).

re：全局变量,它们是负载均衡系统的祸根.负载均衡应用程序的大多数设计人员将进行大量的重新架构,以最大限度地减少对共享状态的依赖,因为它会阻碍负载平衡应用程序的可扩展性和可用性.这些方法中的大多数归结为两步策略：首先,将共享状态移动到高度可用的位置,其次,更改应用程序以最小化必须访问共享状态的次数.

我见过的大多数集群应用程序都会在RDBMS中存储共享状态(甚至像全局变量这样的共享,易失性状态).这主要是出于方便.您还可以使用in-memory database获得最佳性能.但是,将RDBMS用于所有共享状态(瞬态和持久)以及使用现有数据库工具实现高可用性的简单性往往适用于许多服务. RDBMS的Perf当然比内存中的全局变量慢几个数量级,但是如果共享状态很小,那么无论如何你都会读出RDBMS的缓存,如果你正在进行网络跳转来读/写数据差异相对较小.您还可以通过优化数据库模式来实现快速读取/写入,例如通过删除不需要的索引并对所有读取查询使用NOLOCK,其中不需要精确的,高达毫秒的精度.

我并不是说RDBMS永远是共享状态的最佳解决方案,只是改善共享状态访问时间通常不是负载均衡应用程序获得性能的方式 – 而是通过消除对性能的需求来获得性能在每个请求上同步访问(特别是写入)共享状态.这是我上面提到的第二件事：更改你的应用程序以减少对共享状态的依赖.

例如,对于简单的“计数器”和类似指标,应用程序通常会将其更新排队,并让一个线程负责从队列中异步更新共享状态.

对于更复杂的情况,应用程序可能会从悲观并发(检查资源预先可用)开始到Optimistic Concurrency(假设它可用,然后如果你最终退出工作,例如,将相同的项目出售给两个不同的客户端) ！).

Net-net,在负载均衡的情况下,暴力解决方案通常不能创造性地思考您对共享状态的依赖性,并提出创造性的方法来防止必须等待同步读取或在每个请求上写共享状态.

我不打算在您的方案中使用MSCS(Microsoft群集服务). MSCS是一种故障转移解决方案,这意味着即使其中一个群集节点出现故障,它也能很好地保持单服务器应用程序的高可用性,但是您将无法获得真正的负载平衡服务所带来的可扩展性和简单性.我怀疑MSCS确实有共享状态的方法(在共享磁盘上)但是它们需要设置MSCS集群,其中涉及设置故障转移,使用共享磁盘以及其他不适合大多数负载均衡应用程序的复杂性.您最好使用数据库或专门的内存解决方案来存储您的共享状态.