当您从 CM 进行发布时，它会在 Web Db 的 eventqueue 表中放置一条记录。 所有 CD 服务器都将命中 eventqueue 表进行更新并继续。

此命中发生后默认为 2 秒。

简而言之，它们通过数据库中的事件进行通信。注意：这非常简单，但以这种方式看到它有助于我了解事件的工作原理并解决问题。

例如，发布项目时，发布者（在 CM 上或以专用角色运行）从主数据库读取其数据并将其写入 Web 数据库。完成后，它通过在网络数据库的 EventQueue 表中写入一行来引发事件。 CD 服务器接收此事件并清除其相应的缓存等，从而导致从 Web 数据库重新加载该数据。

所有 Sitecore 数据库都有 EventQueue 表，事件会转到不同数据库中的表，具体取决于事件类型。事件基本上只是一个类名和一组序列化数据。事件可以“本地”和“全局”引发，指示是否有多个实例应该接收该事件。假设您有两个 CD 服务器共享一个 Web 数据库，两个 CD 都必须接收该事件。

为了跟踪已处理的事件，在 Properties 表中存储了一个“EQSTAMP”值。它被命名为 [database]_EQSTAMP_[InstanceName]。因此，不要让两个 Sitecore 实例共享相同的实例名称，这一点很重要。如果未设置，Sitecore 将通过组合主机名和 IIS 站点名称来创建实例名称。此时间戳的十进制 Value 对应于 Stamp 表中的十六进制 EventQueue 列。

通常情况下，您永远不必自己玩这些表，但我发现了解它们的工作原理并密切关注它们是很好的。它们会变大并导致一些问题。 CleanupEventQueue 计划任务负责从 EventQueue 表中删除旧的已处理事件。如果您的 EventQueue 在两次清理之间变得过大，您可能需要调整此代理的调度。

注意：这是服务器之间最常见的通信方式。更高版本的 Sitecore 也有其他技术，例如 Rebus。

Event Queues. Why? How? When? 文章详细解释了它，它还描述了在现实生活中使用这种机制的陷阱。

另请注意，Sitecore.Link 项目是获取有关 Sitecore 功能的更多知识的好地方。

它在网络上积累了 Sitecore 知识。

谢谢。