Service Broker 简介

由于最近在做跨域文件的传输，用到了SQL  Broker，写在简单介绍一下，大部分来自MSDN。

 

Service Broker 是 Microsoft SQL Server 2005 中的新技术，它可帮助数据库开发人员生成安全、可靠且可伸缩的应用程序。 由于 Service Broker 是数据库引擎的组成部分，因此管理这些应用程序就成为数据库日常管理的一部分。

Service Broker 为 SQL Server 提供队列和可靠的消息传递。 Service Broker 对使用单个SQL Server 实例的应用程序和在多个实例间分配工作的应用程序都适用。

在单个 SQL Server 实例中，Service Broker 提供了可靠的异步编程模型。数据库应用程序通常使用异步编程来缩短交互式响应时间，并增加应用程序总吞吐量。

Service Broker 还会在 SQL Server 实例之间提供可靠的消息传递服务。Service Broker 可帮助开发人员编写与称为服务的独立的、自包含的组件相关的应用程序。 需要使用这些服务中所包含功能的应用程序可以利用消息来与这些服务进行交互。Service Broker 使用 TCP/IP 在实例之间交换消息。Service Broker 包含一些功能，有助于避免通过网络进行未经授权的访问以及对通过网络发送的消息进行加密。

1. Service Broker 的作用 ：Service Broker 可帮助开发人员生成异步的松散耦合应用程序，可以在这些应用程序中组合使用独立组件来完成任务。这些应用程序组件交换包含完成任务所需信息的消息。
2. 会话
3. 消息排序和协调
4. 事务异步编程
5. 支持松散耦合应用程序
6. Service Broker 组件
   • Service Broker 队列集成在数据库中。
   • 队列对相关消息进行协调和排序。
   • 会话组件。 会话组、会话和消息构成 Service Broker 应用程序的运行时结构。 应用程序将消息作为会话的一部分进行交换。 每个会话都是一个会话组的一部分；会话组可以包含多个会话。Service Broker 会话是对话，即正好是两个参与者之间的会话。 有关会话组件的详细信息，请参阅会话体系结构。
   • 服务定义组件。 这些组件是设计时组件，用于指定应用程序所用会话的基础结构。 它们定义应用程序的消息类型、应用程序的会话流和应用程序的数据库存储。 有关服务定义组件的详细信息，请参阅服务体系结构。
   • 网络和安全组件。 这些组件定义用于交换 SQL Server 实例外部的消息的基础结构。 为了帮助数据库管理员管理更改环境，Service Broker 允许管理员独立于应用程序代码来配置这些组件。 有关网络和安全组件的详细信息，请参阅网络传输与远程安全机制。

会话：

Service Broker 是围绕着发送和接收消息的基本功能来设计的。 每个消息都是“会话”的一个组成部分，会话是一个可靠的、持久的通信渠道。 Service Broker 要求每个消息和会话都必须具有一个特定的类型，以帮助开发人员编写可靠的应用程序。

新的 Transact-SQL 语句使应用程序可以可靠地发送和接收消息。 应用程序向“服务”发送消息，“服务”是一组相关任务的名称。 应用程序从“队列”中接收消息，“队列”是一个内部表的视图。

同一任务的消息是同一会话的一部分。 在每个会话中，Service Broker 保证应用程序对每个消息只接收一次，并按照消息的发送顺序来接收消息。 实现某个服务的程序可以关联“会话组”中该同一服务的相关会话，详细信息请参阅 Service Broker 的优点。

基于证书的安全机制有助于保护敏感消息并控制对服务的访问。

理解 Service Broker 的一个方法是将它想像成邮政服务。 若要与远方同事展开会话，您可以通过邮政服务发送信件进行联络，邮政服务会分拣信件并投递。 您和您的同事从邮箱中检索信件、阅读它们、撰写回信并发送新的信件，直到会话结束。 信件传递是“异步”的，也就是您和您的同事同时可以处理其他任务。



在这个与邮政服务的类比中，信件就是消息。 Service Broker 服务就是邮局投递信件的地址。 队列就是在信件投递后用于保存它们的邮箱。 应用程序接收消息、对消息进行操作，然后发送响应。

使用 Service Broker 的程序通过与邮递相类似的方式保持与其他程序之间的会话。

您无需具体了解您的同事何时阅读邮件或回复邮件。 同样，使用 Service Broker 的应用程序不必了解其他服务如何处理消息、如何传递消息或其他应用程序何时处理消息。

消息排序和协调：

Service Broker 在处理队列（一种常见的数据库编程技术）时，有两个关键方面不同于传统产品：

 

集成队列意味着常规数据库维护和管理还要包括 Service Broker。 通常，管理员无需进行与 Service Broker 有关的日常维护任务。

Service Broker 框架提供一个用于发送和接收消息的简单 Transact-SQL 接口，并且该接口结合了一套针对消息传递和处理的强保证策略。Service Broker 保证程序对会话中的每条消息只接收一次，其顺序是消息发送的顺序，而不是消息进入队列的顺序。 传统的队列产品提供消息的顺序是消息进入队列的顺序，同时要求应用程序确定消息的顺序和分组。Service Broker 保证两个队列读取器不能同时处理来自同一会话的或同一相关会话组的消息。

起始程序为每个任务启动一个会话，然后向目标服务发送消息。 消息中包含执行任务中特定步骤所需的数据。 目标服务接收该消息。 目标服务的程序处理该消息，然后响应起始服务。 会话继续进行，最终根据开发人员确定的规则结束。

Service Broker 可处理编写消息应用程序中包含的最困难的任务。 这些任务包括协调、可靠的消息传递、锁定和启动队列读取器。 这使得数据库开发人员能够集中精力解决业务问题。

事务异步编程

在 Service Broker 基础结构中，应用程序间的消息传递是“事务”和“异步”的。 由于 Service Broker 消息传递是事务性的，因此，如果某个事务回滚，则该事务中的所有 Service Broker 操作都将回滚。 这包括发送和接收操作。 在异步传递中，数据库引擎在应用程序继续运行时处理传递。 为了提高伸缩性，Service Broker 提供了一些机制，当处理队列的程序需要进行一些必要的工作时，这些机制可以自动启动这些程序。 有关详细信息，请参阅 Service Broker Activation。

异步编程可以帮助开发人员编写使用队列的应用程序。 很多数据库都包含用作队列的表，其中包含当资源允许时所要完成的工作。 队列允许数据库在有效地使用可用资源时保持对交互用户的响应。Service Broker 提供队列功能以作为数据库引擎的重要部分。

队列功能使应用程序可以在与请求工作的事务不同的另一个事务中执行该工作。Service Broker 扩展了此概念，使应用程序可以在另一个实例或另一台计算机中执行工作。Service Broker 在数据库中提供内置队列和实例间的可靠事务消息传递，这对数据库开发人员很有帮助。

支持松散耦合应用程序

Service Broker 支持松散耦合的应用程序。 松散耦合应用程序由多个相互间独立发送和接收消息的程序组成。 此类应用程序必须包含用于交换消息的相同定义，并且必须为服务间的交互定义相同的总体结构。 但是，应用程序不必同时运行、在 SQL Server 的相同实例中运行或共享实现详细信息。 应用程序不必知道会话中其他参与者的物理位置或实现情况。

Service Broker 组件

Service Broker 有三种类型的组件：

 

服务定义组件、网络组件和安全组件是数据库和 SQL Server 实例的元数据的一部分。 会话组、会话和消息是数据库所包含的数据的一部分。

2. Service Broker 的功能为数据库应用程序的帮助很大。这些功能和好处包括：

• 数据库集成提高了应用程序的性能并简化了管理。
• 适用于简化的应用程序开发的消息排序和协调。
• 应用程序松耦合提供了工作负荷灵活性。
• 相关消息锁定使一个应用程序的多个实例可以对同一队列中的消息不必显式同步处理。
• 自动激活使应用程序可以随消息量进行调整。

Service Broker 的功能为数据库应用程序的帮助很大。这些功能和好处包括：

 

数据库集成

Service Broker 的集成设计对应用程序性能和管理有所帮助。

与 SQL Server 集成可以进行事务性的消息传递，从而避免了外部分布式事务协调器的额外开销和复杂性。在一个数据库事务内，应用程序接收一个或多个消息，处理消息并发送答复消息。如果事务失败，所有工作都回滚，并且收到的消息会返回到队列中，以便可以尝试再次处理它。仅当应用程序提交事务之后，操作才会生效。应用程序保持一致性状态。

当数据、消息和应用程序逻辑都在数据库中时，管理变得更简单，因为应用程序的管理（灾难恢复、安全性、备份等）随之成为数据库日常管理的一部分，而且管理员不必管理三个或四个单独的组件。

在传统的消息传递系统中，消息存储区和数据库可以不一致。例如，当一个组件从备份中还原时，另一个组件也必须同时从备份中还原，否则消息存储区中的信息与数据库中的信息不匹配。由于 Service Broker 将消息和数据保存在同一个数据库中，因此消除了不一致问题。

公共的开发环境也是数据库集成的一个好处。应用程序的消息传递部分和数据部分可以在 Service Broker 应用程序中使用相同的 SQL Server 语言和工具，这使开发人员在基于消息的编程中可以充分利用对数据库编程技术的熟悉。实现 Service Broker 服务的存储过程可以用 Transact-SQL 或一种公共语言运行时 (CLR) 语言来编写。数据库外的程序使用 Transact-SQL 和类似的数据库编程接口，如 ADO.NET。

此外，数据库集成使自动资源管理成为可能。Service Broker 在 SQL Server 实例的上下文中运行，因此它监视准备从该实例中所有数据库传送的所有消息。这样使每个数据库在维护自己队列的同时，帮助 Service Broker 管理整个 SQL Server 实例中的资源使用情况。

排序和协调消息

在传统的消息传递系统中，应用程序负责排序和协调到达顺序可能不对的消息。例如，应用程序 A 发送消息 1、2 和 3。应用程序 B 接收并确认消息 1 和 3，但是在接收消息 2 时出现错误。应用程序 A 重新发送消息 2，但是，现在该消息是在消息 1 和 3 后面收到的。过去，开发人员或者必须编写应用程序，使消息顺序不出问题，或者在消息 2 到达之前暂时缓存消息 3，以便应用程序可以以正确的顺序处理这些消息。这两个解决方案都既不明了也不简单。

传统系统还存在另一个问题，即重复传递。在上面的示例中，如果应用程序 B 收到消息 2，但是返回给应用程序 A 的确认消息丢失，应用程序 A 将重新发送消息 2，这导致应用程序 B 收到消息 2 两次。应用程序代码必须能够识别出重复消息并放弃它，或者重新处理该重复消息，而不产生任何负面效果。同样，这两个方法也很难实现。

消息协调在传统上也是难以处理的问题。例如，某个应用程序可能向一个服务提交成百上千个请求。该服务并行处理这些请求，并且它每处理完一个请求就立即返回一个响应。由于处理每个请求所花费的时间长短是不同的，因此应用程序收到响应的顺序与它发送传出消息的顺序不同。但是，为了正确处理响应，应用程序必须将每个响应与正确的传出消息相关联。在传统的消息传递系统中，每个应用程序都管理此关联，这使得应用程序的开发成本和复杂程度加大了。

Service Broker 通过自动处理消息顺序、唯一传递和会话标识解决这些问题。在两个 Service Broker 端点间建立会话后，一个应用程序只对每个消息接收一次，并且以该消息的发送顺序接收它。您不需要对应用程序额外编写代码，即可按照顺序处理这些消息，且仅处理一次。最后，Service Broker 自动将标识符包含在每个消息中。应用程序可以始终掌握特定消息属于哪个会话。

松耦合与工作负荷灵活性

Service Broker 提供起始应用程序和目标应用程序间的松耦合功能。应用程序可以向队列发送一个消息，然后继续应用程序处理，而依靠 Service Broker 确保该消息到达其目标。这种松耦合带来了计划上的灵活性。发起方可以发出多个消息，而多个目标服务可以并行处理这些消息。每个目标服务按照其自己的速度处理这些消息，具体情况取决于当前的工作负荷。

排队也可使系统更平均地分配处理任务，从而减少服务器所需的峰值容量。这样可以提高数据库应用程序的总体吞吐量和性能。例如，许多数据库应用程序在一天中的某些特定时段事务量激增，这使资源消耗加大并使响应时间延长。使用 Service Broker，这些应用程序无需对提交的业务事务执行该事务的所有处理。而是使用 Service Broker 将有关该事务的信息发送给执行后台处理的应用程序。这些执行后台处理的应用程序可靠地处理这些事务一段时间，同时主入口应用程序继续接收新的业务事务。

如果目标不是立即可用的，消息保留在发送数据库的传输队列中。Service Broker 会重试发送该消息直至该消息成功发送为止，或者直至会话的生存期过期，这使得即使两个服务中的一个在会话期间的某个点不可用，会话也可以在两个服务之间可靠地继续。传输队列中的消息是数据库的一部分；即使实例发生故障转移或重新启动，Service Broker 也可以传递消息。

相关消息锁定

在传统的消息传递应用程序中，最难实现的任务之一是使多个程序并行读取同一队列。在传统的消息传递系统中，当多个程序或多个线程读取同一队列时，可能会以错误的顺序处理消息。Service Broker 通过会话组锁定防止出现这种情况。

试想传统的订单处理应用程序。队列收到两个消息，消息 A 包含有关创建订单标题的指令，消息 B 包含有关创建订单行各项的指令。如果这两个消息分别由不同的应用程序实例移出队列，并且同时处理，则订单行项事务有可能尝试先提交，并因订单尚未存在而失败。这一失败进而导致事务回滚和消息重新入队，然后消息被再次处理，从而浪费了资源。程序员解决此问题的传统做法是：将消息 A 和消息 B 中的信息组合成一个消息。虽然这种方法对两个消息来说简单明了，但是对于涉及需要协调几十个或几百个消息的系统来说，这一方法就无能为力了。

Service Broker 通过关联会话组中的相关会话来解决这个问题。Service Broker 自动锁定同一会话组中的所有消息，使这些消息只能由一个应用程序实例来接收和处理。同时，应用程序的其他实例可以继续将其他会话组中的消息移出队列并处理它们。这样使得多个并行应用程序实例可以可靠而有效地工作，而不需要在应用程序中编写复杂的锁定代码。

自动激活

Service Broker 最有用的功能之一是激活功能。激活功能使应用程序可以动态地调整自身，以匹配队列中到达的消息量。Service Broker 提供了一些功能，这些功能使在数据库中运行的程序和在数据库外运行的程序都可以利用激活。但是，Service Broker 不要求应用程序必须使用激活。

Service Broker 监视队列中的活动，以确定某个应用程序是否在接收所有含有可用消息的会话的消息。当有工作需要由新的队列读取器来执行时，Service Broker 激活功能会启动一个新的队列读取器。Service Broker 监视队列中的活动来确定何时有工作需要由队列读取器来执行。当队列读取器的数量与传入的通信流量相匹配时，队列会定期进入一种状态，即队列或者为空，或者该队列中的所有消息都属于正由另一队列读取器处理的会话。如果队列在一段时间内没有达到此状态，则 Service Broker 会激活应用程序的另一个实例。

对于在数据库中运行的程序和在数据库外运行的程序，应用程序使用不同的激活方法。对于在数据库中运行的程序，Service Broker 启动队列所指定的存储过程的另一个副本。对于在数据库外运行的程序，Service Broker 生成一个激活事件。程序监视此事件以确定何时需要另一个队列读取器。

Service Broker 不停止通过激活功能启动的程序。激活的应用程序都被编写为如果在特定的时间段内没有消息到达以供接收，则在这段时间过后将自动关闭。以这种方法设计的应用程序使应用程序实例的数量可以随服务的通信流量更改而动态地增大或减小。此外，如果系统关闭或重新启动，则系统重新启动时，应用程序会自动启动以读取队列中的消息。

传统的消息传递系统没有此行为，结果在某个给定的时间专用于特定队列的资源经常不是太多就是太少。

3. Service Broker 的典型使用

• 异步触发器
• 可靠的查询处理
• 可靠的数据收集
• 用于客户端应用程序的分布式服务器端处理
• 用于客户端应用程序的数据合并
• 大规模批处理

对于需要异步执行处理的应用程序或需要跨多个计算机分发处理的应用程序，Service Broker 会非常有用。Service Broker 的典型使用包括：

 

异步触发器

使用触发器（如联机事务处理 (OLTP) 系统）的许多应用程序均可受益于 Service Broker。触发器将向 Service Broker 服务请求工作的消息排队。触发器实际上并不执行所请求的工作。触发器而是创建一条消息，该消息中包含有关要完成的工作的信息，然后将此消息发送给执行该工作的服务。触发器随后返回。

原始事务提交时，Service Broker 将消息传递给目标服务。实现此服务的程序在单独的事务中执行此项工作。通过在单独的事务中执行此项工作，原始事务可以立即提交。应用程序可避免由执行此项工作时，保持原始事务为打开状态而引起的系统速度下降。

可靠的查询处理

某些应用程序在出现计算机故障、停电或类似问题的情况下也必须能够可靠地处理查询。需要可靠的查询处理的应用程序可以通过向 Service Broker 服务发送消息来提交查询。实现此服务的应用程序读取该消息，运行查询，然后返回结果。上述这三个操作发生在同一个事务中。如果在事务提交前发生故障，则整个事务都将回滚，并且消息将返回到队列中。计算机恢复时，应用程序重新启动并再次对消息进行处理。

可靠的数据收集

从一组数量众多的源中收集数据的应用程序可以利用 Service Broker 来可靠地收集数据。例如，具有多个站点的零售应用程序可以使用 Service Broker 向中心数据存储区发送事务信息。因为 Service Broker 提供可靠的异步消息传递，所以即使各个站点临时断开与中心数据存储区的连接，仍可以继续处理事务。Service Broker 安全机制可帮助确保消息不会被误传，还可帮助保护传输中的数据。

用于客户端应用程序的分布式服务器端处理

访问多个 SQL Server 数据库的大型应用程序可从 Service Broker 获益。例如，订购图书的 Web 应用程序可以使用服务器端的 Service Broker 在包含订购、客户、库存以及信用卡数据的不同数据库间交换信息。由于 Service Broker 提供消息队列和可靠的消息传递，因此，即使其中某个数据库不可用或负荷过重时，应用程序仍可继续接受订单。在这种情况下，Service Broker 用作分布式 OLTP 系统的框架。

用于客户端应用程序的数据合并

必须同时使用或显示多个数据库中的信息的应用程序可以利用 Service Broker。例如，将多个位置的数据合并到一个屏幕的客户服务应用程序可以使用 Service Broker 来并行（而不是依次）运行这些请求，这样做可以大大缩短应用程序的响应时间。客户服务应用程序并行向不同的服务发送请求，在这些服务响应请求时，客户服务应用程序收集响应并显示结果。

大规模批处理

必须执行大规模批处理的应用程序可以利用 Service Broker 提供的排队和并行处理功能来迅速高效地处理大量的工作。应用程序将待处理的数据存储在 Service Broker 队列中。程序定期从队列中读取数据并进行处理。应用程序可以利用 Service Broker 提供的可靠的消息传递，在发出请求的计算机以外的其他计算机上执行批处理。