我一直想知道巨大的应用程序（例如Facebook）是如何在几乎实时的情况下处理通知用户有关事件（例如某人给你的消息），而不是每秒/分钟汇集数据库等（我假设Facebook不检查如果每秒都有登录用户的新消息）。当数据库发生更改（插入或更新行）时，Sql Server中是否有任何方法可以在C＃应用程序中接收通知？
（希望）让事情变得更加实用：
您如何处理连接到数据库服务器的桌面聊天应用程序，并允许用户互相发送消息，为接收消息的人提供即时通知？
您如何处理通知用户他们在“离线”时收到的消息？
假设应用程序可以处理数百/数千个用户，并且通知应该（相对）即时（不需要每隔10秒汇集数据库以查看是否有新消息）。
答案 0 :(得分：5)
使用数据库作为通信中心的中心将成为瓶颈，并且可能无法很好地扩展。既然你提到过.NET，你应该查看SignalR。 https://www.asp.net/signalr
在一个简单的用例中，您可以写入数据库并同时发送通知事件，以告知客户端检查您刚刚写入数据库的新内容。
答案 1 :(得分：2)
这取决于您需要的准确程度。 Facebook不需要准确，所以无论如何都可以做到这一点。为了准确实现，例如存在服务质量问题，以便消息必须在特定时间到达目的地，那么您需要在客户端和服务器之间建立双向链接。 Websockets在HTTP上执行此操作，尽管它实际上只是掩盖了轻量级HTTP轮询机制。
在确保特定会话（用户）获取消息方面，我很想使用内存数据库（如Redis）作为生成的所有消息的可写缓存。如何为用户会话更新Redis中的会话存储取决于消息的来源;它可能是
1）由于数据库更新 2）因为外部系统输入 3）因为已经过了一段时间并且达到了一些计划守门人。
在所有这些情况下，您可能使用不同的技术来通知分布式消息缓存，因此在SQL Server中，您可能会生成一个Trigger来写入传出消息表，可能使用SQL Server Object Broker或MSMQ作为消息转储。单独的进程将解析消息转储并上载Redis缓存。
答案 2 :(得分：1)
如上所述，它应该是服务器（应用程序）的责任，而不是db
我会按以下方式进行：
应用程序（让它成为中央服务器）必须确保是否传递了消息。如果已交付，请将其保存到历史记录（db）。如果不是，请将其保存到推迟的消息（db）。
如果用户处于离线状态，他/她将登录服务器。登录完成后，服务器会发送他/她推迟的消息。
在无服务器/分布式系统的情况下，逻辑将是相同的，除了推迟的消息可以仅保存在客户端，或保存在一些消息路由的节点上