如何在绑定数据库的应用程序之间进行有效通信
本文关键字：之间 有效 通信 应用程序 绑定 数据库 | 更新日期: 2023-09-27 18:37:08
我们有许多不同的老式客户端服务器C#WinForm客户端应用程序，它们本质上是数据库的前端。然后是一个C#服务器端窗口服务，它等待客户端应用程序提交订单，然后处理订单。
服务器端服务发现是否有工作要做的方法是轮询数据库。多年来，由于无数的商业规则，等待订单的轮询逻辑变得更加复杂。因此，即使没有什么可做的，轮询存储过程本身也会使用相当多的SQL Server资源。此外，还要求订单在提交时立即处理，这会给自己带来性能问题，因为数据库一直在被轮询。
现在的设置实际上很好，但负载即将通过屋顶，很明显，它撑不住了。
有哪些有效的方法可以在一堆不同的客户端应用程序和服务器端windows服务之间进行通信，比目前的方法更经得起未来的考验？
数据库服务器是SQL server 2005。如果真的是这样的话，我可能会有能力为最新的SQL Server买单，但我宁愿不打那场仗。
您可以通过多种方式通知客户。
- 您可以使用像NServiceBus这样的现成解决方案，将信息从服务器发布到客户端或其他服务器。NServiceBus使用MSMQ以一种非常简单和持久的方式向多个订阅者发布一条消息
- 您可以使用MSMQ或其他排队产品从服务器发布将要传递到客户端的消息
- 您可以在Windows服务上承载WCF服务，并使用双工通道从每个客户端连接到它。每次发生更改时，服务都会通知相应的客户端，甚至所有客户端。这对代码来说更复杂，但也更灵活。您可能会向客户端发送足够的信息，使他们根本不需要轮询数据库
- 您可以让服务向所有客户端广播UDP数据包，以通知他们需要进行更改。您可能可以在数据包中添加足够的信息，以便客户端决定是否需要从服务器提取数据。这对于服务器和网络来说是非常轻量级的，但它假设所有客户端都在同一个LAN中
也许您可以利用SqlDependency仅在数据实际更改时接收通知。
您可以使用任何消息中间件(如MSMQ、JMS或TIBCO(在客户端和服务之间进行通信。
到目前为止，最简单、最便宜的答案就是简单地购买一台更大的服务器。
除此之外，您所从事的开发工作很有可能早期失败。我所说的失败并不是说你最终会刮去你最终建造的任何东西。相反，我的意思是，当你调试你的无数业务规则时，你启动了更改，订单就会被搞砸。
坦率地说，我不会考虑在压力下改变沟通方式；假设你关于负荷在短期内"突破屋顶"的说法。
如果你的风险敞口如此之大，以至于第一天必须100%正常工作(当你预计订单会大幅增加时，这是正常的(，没有任何问题，那么就扩大DB服务器的规模。见鬼，我甚至不会在上面安装最新的sql服务器。相反，只需购买一台更大的机器，安装完全相同的操作系统和数据库服务器(以及补丁级别(，然后移动数据库。
然后查看您的体系结构，以确定哪些需要放弃，哪些可以挽救。
如果每个人都连接到SQL Server，那么还有Service Broker选项。与迄今为止推荐的其他消息传递/排队解决方案不同，它完全包含在您的数据库中(没有单独的产品可供部署、管理和配置(，它针对您的备份/恢复和高可用性需求提供了一个单一的故事(没有单独的消息存储备份，没有单独的DR/HA，无论您的DB解决方案是什么，也是您的消息解决方案(，并通过统一的编程API(SQL(。
即使所有内容都在一个SQL Server实例中(即，不需要在多个SQL Service实例之间通过网络进行通信(，Service Broker仍然有一个无人能及的王牌：激活。通过激活，您完全无需轮询，因为当有事件需要处理时，系统本身会启动您的处理代码(将"激活"(。处理代码可以是内部的(T-SQL过程或SQLCLR.Net过程(或外部的(请参阅外部激活器(。