我想知道如何做到这一点,因为我可以为用C#编写的示例应用程序实现缓存机制。此实现旨在最终成为一个库。
我知道EntityFramework与Auto Refresh有一些相似的机制,并且NHibernate具有缓存级别。但我对这个概念有一个模糊的概念,不知道它们在内部是如何工作的。
从小研究中我知道它与SQL Server Broker Service有关,该服务将消息发送到MSMQ,并且从我的应用程序中,我针对MSMQ进行池化,但我从未见过实现示例。
更新
好吧,为了说明这适用于何处,它是一个全行业的仓库管理系统。该系统有大约 15 项服务同时运行,并一直向数据库询问有关各自存储区域中产品和容器的移动情况。
为什么有 15 个服务正在运行?
使用该管理系统的仓库有几条带有条形码扫描仪的生产线,在高峰时间每分钟读取大约 10 个标签,每条生产线都有特定的服务,因为每条生产线的逻辑各不相同,每个逻辑对不同的服务和数据库中是否存在所述条形码。
此外,它还有 10台 AGV(自动导引车),提供的服务包括:AGV 的任务发布者、任务调度器等。这些都在不断地汇集在数据库中以寻找要执行的新任务。叉车运营商的码头也是如此,他们不断汇集数据库以寻找新的集装箱运输订单。
需要补充的是,接收、调度和存储也是自动化的,并且每个都有自己的服务。
为什么系统没有中间件?
我必须澄清一下,这个规模如此之大的系统没有中间件(这将是一种荣耀,因为它可以解决许多架构问题),因为它是一个适应于 1995 年左右的旧系统的系统。以及在这些日期限制生产的其他系统。今天,它必须升级,我们在增加产量方面遇到了可扩展性问题。
为了理解这一点,BL和DAL位于同一台服务器上,因此我无法分配数据查询负载。
我澄清说,该应用程序具有在WinForms中创建的客户端,它们连接到服务(控制台应用程序)。
一种解决方案可能是使用“查询通知”,它允许从 .NET 接收对 SQL Server 数据所做更改的通知。在这篇 MSDN 文章中,您可以看到一个关于如何检测更改和接收事件的简单示例。
将它与 SignalR 结合起来可能也很有趣,这样客户端应用程序就不会直接连接到 SQL Server。在 CodeProject 中有一篇文章“ Real Time Notifications using SignalR and SQL Dependency ”非常有趣。
我不知道这个解决方案是否会提供所需的性能,或者相反,该解决方案是否可能是SQL Server R Services、ServiceBus等。
除非您的系统高度集中在 SQL Server 中(并且从您所说的看来并非如此),否则我不会推荐 SSBS。
我的建议是触发 X 进程(例如,将消息排入队列)是您的中间件(事件的逻辑起源发生的地方)。
在缓存的特定情况下,根据定义,它不应该在分布式环境中更新(例如,在本地缓存对数据库的查询的服务器群)。
如果您想保持缓存值尽可能新鲜,那么您应该考虑使用Memcached或类似的方案(redis,...)。基本上,单个缓存由它的所有消费者共享。
如果这是一种实践,那么实现自己的 memcache 会很有趣。
另一方面,您可能希望将某些更改通知客户,在这种情况下有几种策略,最适合您的情况可能是SignalR,但您必须查看您的具体情况才能了解哪种形式的缩放是最合适的。
在任何情况下,我重复一遍,除非出于特定原因,您可以在逻辑中控制该通信的流(无论是更新值的缓存,传播到客户端的事件等......) .
您不是在描述任何缓存系统(您是在描述事件通知系统)。SSBS 可以将消息发送到队列,然后您从应用程序中出列,就这么简单,但是该方案非常严格并且与数据库耦合,您需要队列管理器,而且您的客户端必须拉取(明确询问队列经理,如果有新消息)。虽然你没有暴露具体问题,但它似乎不是最合适的(或者似乎有更好的选择)。
作为一个可能不太健壮的解决方案的一部分,如果其他表发生更改,您可以使用 DDL TRIGGER 插入表中,然后从您的应用程序中查询它,如下所示:
当然,有更好的选择可以避免将更改提交到用于推送更改的表,例如 SCHEMABINDING 或类似的东西。