Service Broker 和 AlwaysOn 可用性组：奇怪的传输队列行为

Question

我也在我的博客上发布了这个问题：http : //www.sqldiablo.com/2012/04/15/service-broker-alwayson-availability-groups-odd-transmission-queue-behavior/。

在过去的几个月里，我一直在从事一个项目，该项目将利用 Service Broker 和 AlwaysOn 可用性组来实现我工作的公司的一些 HA 和 DR 目标（更多信息：）http://www.sqldiablo.com/service-broker-replication/。就在最近，我能够在我的开发实验室中实施完整的解决方案，并将我们网站的一个实例指向它。当我们在我们的数据库和网站中解决一些问题以使两者与我的 Service Broker Replication 项目正常工作时，我开始注意到 Service Broker 与 AlwaysOn Availability Groups 一起使用时的一些奇怪行为，我想在博客中介绍它尝试看看其他人是否已经看到了这个问题，并且可能知道如何解决它。

设置：

我有一台运行 6 个 Windows Server 2008 R2 VM (BTDevSQLVM1-BTDevSQLVM6) 的 Hyper-V 主机。VM 分组为具有节点和文件共享仲裁的 2 节点 WSFC。我已经在每个 VM 上安装了独立的 SQL 2012 Developer Edition 实例，并在每个集群（SBReplDistrib、SBRepl1 和 SBRepl2）上创建了一个带有侦听器的可用性组。

出于本博文的目的，我将重点介绍 SBRepl1 和 SBReplDistrib 之间的通信。下图显示了对话每一方的 Service Broker 对象：

（我是新手，还不能发布图片，所以请在上面的 URL 上查看我的博客以获取图片）

Service Broker 端点和路由是根据这篇 MSDN 文章设置的。MSDB 中的 SBRepl_Receive 路由用于本地服务器的服务（SBReplDistrib 上的//SBReplDistrib/SBRepl，SBRepl1 上的//SBRepl1/SBRepl），并指向本地实例。SBRepl1 上的 SBRepl_Send 路由将服务 //SBReplDistrib/SBRepl 映射到 TCP://SBReplDistrib:4022，SBReplDistrib 上的 SBRepl_Send_SBRepl1 路由是 SBRepl1 上服务的类似映射。

预期行为：

我对 Service Broker 如何处理消息发送和接收的理解是这样的（这非常简单。Klaus Aschenbrenner 的书“Pro SQL Server 2008 Service Broker”中有很多关于这个过程的细节）：

1. 发起方应用程序创建一条消息（在本例中为格式良好的 XML）
2. 如果发起方服务和处于通话状态的目标服务之间存在对话对话，应用程序可以简单地在现有对话句柄上发送消息。否则，发起方应用程序应开始发起方服务和目标服务之间的对话对话，并在该对话句柄上发送消息。
3. 消息放置在 sys.transmission_queue 系统表中，Service Broker 开始尝试将消息传递到目标服务。
4. Service Broker 会查找适当的路由和远程服务绑定，并使用它们来确定要连接到的地址以传递消息。
5. Service Broker 打开与目标的连接，进行身份验证并将消息传递给目标 Service Broker。
6. 目标 Service Broker 尝试对消息进行分类并确定哪个本地服务将处理该消息（为此它使用 msdb 数据库中的路由数据）。
7. 目标 Service Broker 将消息传递到目标服务的队列
8. 一旦消息成功传递到目标队列，目标 Service Broker 就会查找返回到发起方的路由信息​​，并尝试传递已收到消息的确认。
9. 发起者的 Service Broker 接收确认并使用 MSDB 中的路由信息​​来确定确认是针对什么本地服务的。
10. 在成功将确认路由到发起服务后，该消息将从 sys.transmission_queue 系统表中删除。
11. 如果发起方没有收到消息已收到的确认，它将定期重试将消息传递给目标。如果目标已经收到消息，它将简单地放弃任何额外的交付重试并为它们发送确认。

奇怪的行为：

第 11 步是我看到 Service Broker 和 AlwaysOn 的一些非常奇怪的行为。我看到消息被传递到目标并成功处理，我还看到确认被发送回发起者并被接收。但是，该消息仍保留在 sys.transmission_queue 中，就好像没有收到确认一样。更奇怪的是，如果没有收到确认，Service Broker 不会像我期望的那样尝试重新发送消息。相反，消息只是保留在 sys.transmission_queue 中，并且随着新消息的发送，它们被传递、确认，并且它们也保留在 sys.transmission_queue 中。在我看来，服务代理正在获得确认，因此停止尝试传递消息，但不会将其从 sys.path 中删除。由于某种原因传输队列。这些消息的传输状态保持空白，这表明 Service Broker 尚未尝试传递它们。

我检查了服务队列上的保留设置，它被设置为关闭，但这只会影响服务队列而不是 sys.transmission_queue。我还使用 SQL Profiler 跟踪了对话的双方，我能够看到消息被发送，确认被发送回发起者并被接收（参见本文末尾的 XML 跟踪数据）。

不过，在痕迹中确实有一件奇怪的事情突然出现在我身上。我注意到双方似乎对 TCP 连接有点困惑，因为消息是从节点本身的 IP 地址发送的，而服务路由和消息本身指向 AG 侦听器的名称/IP。这种混乱似乎导致每一方关闭两个服务之间的现有连接并创建一个新的连接以传递消息或确认。我不确定这是否正常，或者它是否与为什么没有正确处理确认有关，但这是我能看到的唯一可以解释奇怪行为的东西。

求助请求：

目前，我没有解决此消息保留问题的方法，只能手动结束双方的清理对话，这并不是我真正想做的事情。如果您对为什么会发生这种情况或我能做些什么有任何想法，请给我留言并让我知道。如果您希望我提供有关我的设置或问题的任何其他信息，也请在评论中告诉我。如果/当我找到此问题的解决方案时，我将发布这篇文章的后续文章。

跟踪数据：

请参阅我的博客文章（网址在问题的开头）。

Answer 1

在过去的几个月里，我一直与 Microsoft 的产品支持团队合作，他们已经承认 SQL Server 2012 中存在与此问题相关的两个错误。他们将发布针对这些错误的补丁，作为 SQL Server 2012 下一个服务包的一部分。