Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:
SQL ServerAzure SQL Managed Instance
En este artículo se describen los detalles de cómo Service Broker enruta los mensajes. Para ver una introducción, consulte Rutas.
En la mayoría de las aplicaciones, una sencilla aproximación al enrutamiento de Service Broker es suficiente. En cada base de datos que contiene un servicio, se especifica una ruta para los servicios externos con los que se comunica el servicio. Sin embargo, Service Broker proporciona un sistema de enrutamiento sofisticado para controlar casos en los que una aplicación necesita un comportamiento más complejo. Para obtener ejemplos que ilustran el proceso de enrutamiento, consulte Ejemplos de enrutamiento de Service Broker.
Descripción del proceso de ruta
SQL Server mantiene dos niveles distintos de información de enrutamiento. Cada base de datos contiene una tabla de enrutamiento local, sys.routes, para las conversaciones iniciadas en esa base de datos. En el caso de las conversaciones que se originan en la instancia de SQL Server, SQL Server busca la tabla de enrutamiento en la base de datos que ha creado la conversación. En el caso de las conversaciones que llegan desde fuera de la instancia, SQL Server busca en msdb.sys.routes.
El proceso de coincidencia básico es idéntico tanto si la conversación se origina en la instancia como fuera de ella. El proceso pasa por alto las rutas que han expirado. El proceso de enrutamiento consta de tres pasos distintos:
Buscar rutas coincidentes: Service Broker busca un conjunto de rutas posibles mediante la coincidencia del nombre del servicio y el identificador de Service Broker.
Elija una ruta: Service Broker elige una ruta entre el conjunto de rutas posibles.
Busque el servicio de destino: cuando la ruta elegida especifica
'LOCAL'como dirección de red, Service Broker busca el servicio en la instancia. Si el servicio no existe en la instancia, Service Broker podría volver al paso 2 y elegir otra ruta.
Cuando el mensaje se ha enviado desde el iniciador al destino y el iniciador ha recibido un mensaje de confirmación del destino, el iniciador usa el identificador de Service Broker en los mensajes de confirmación para enrutar los mensajes posteriores al mismo destino. Service Broker controla los mensajes de confirmación; el proceso resulta transparente para una aplicación que usa Service Broker. Para obtener más información sobre los mensajes de confirmación, consulte Protocolos de comunicación de Service Broker.
Responder mensajes desde un servicio de destino
Cuando un mensaje que llega desde fuera de la instancia procede de un servicio de destino, SQL Server comprueba si la instancia actual contiene el identificador de Service Broker en el mensaje. Si es así, el mensaje se entrega en la instancia actual, como se describe en Buscar el servicio de destino más adelante en este artículo. De lo contrario, SQL Server sigue el proceso de coincidencia estándar.
Búsqueda de rutas coincidentes
El siguiente procedimiento describe cómo SQL Server hace coincidir rutas. En cada paso, si una o más rutas coinciden, el proceso de coincidencia finaliza y Service Broker elige una de las rutas coincidentes de la siguiente manera:
Si la conversación especifica un identificador de Service Broker, busca una ruta con una coincidencia exacta para el nombre de servicio y el identificador de Service Broker.
Busque una coincidencia exacta para el nombre del servicio entre las rutas que no especifiquen un identificador de Service Broker.
Si la conversación no especifica un identificador de Service Broker, busque una coincidencia exacta para el nombre del servicio entre las rutas que especifican un identificador de Service Broker. Si la tabla de enrutamiento contiene rutas que coinciden con el nombre del servicio y tienen identificadores de Service Broker diferentes, elija arbitrariamente un identificador de Service Broker. A continuación, elija solamente las rutas que usan dicho identificador de Service Broker.
Si existe una ruta a un servicio de enrutamiento dinámico y no existe ninguna solicitud pendiente de una ruta al servicio, marca la conversación como DELAYED y solicita información de enrutamiento a ese servicio.
Busque una ruta que no especifique ni el nombre del servicio ni el identificador de Service Broker.
Si la conversación especifica un identificador de Service Broker y si la instancia contiene una o varias bases de datos que contienen servicios con nombres que coinciden con el nombre especificado en la conversación, enrute la conversación como si la tabla de enrutamiento contenía una ruta con el nombre del servicio y la dirección
'LOCAL'de red .Marca la conversación como DELAYED.
Cuando una conversación se marca como retrasada, Service Broker vuelve a realizar el proceso de coincidencia después de un período de tiempo de espera. No se considera un error no encontrar una ruta coincidente.
Elección de una ruta
Si el proceso de coincidencia encuentra más de una ruta coincidente, Service Broker elige una ruta entre las coincidentes. En este caso, las rutas que tienen el mismo identificador de Service Broker, el mismo nombre de servicio y la misma dirección de red se consideran idénticas. Service Broker usa el siguiente procedimiento para elegir la ruta exacta. En cada paso, el proceso continúa en el siguiente paso si no hay ninguna ruta que coincida con la especificación de dirección del paso.
Elige una ruta entre las que especifican una dirección de reflejo.
Elija una ruta entre las rutas que especifiquen
'LOCAL'como dirección de red. Si esta instancia de SQL Server no contiene un servicio que coincida con el nombre especificado en la conversación, continúe en el paso 3.Elige una ruta entre las que especifican una dirección de red.
Elija una ruta entre las rutas que especifiquen
'TRANSPORT'como dirección de red.
Si el reenvío del broker no está activo, Service Broker elimina el mensaje si la conversación no se origina en la instancia actual y la dirección de la ruta elegida no es 'LOCAL'.
Buscar el servicio de destino
Como se ha descrito anteriormente, Service Broker entrega mensajes a un servicio en la instancia actual cuando la ruta coincidente especifica 'LOCAL' como dirección de red. Para los mensajes que se originan fuera de la instancia, la ruta debe estar en msdb.sys.routes. Para los mensajes que se originan en la instancia, la ruta coincidente debe estar en la sys.routes tabla de la base de datos que inicia la conversación.
Cuando Service Broker determina que el servicio para el mensaje está en la instancia actual, Service Broker debe localizar el servicio en la instancia. Cuando existe un identificador de Service Broker para la conversación en la conversación o en la ruta, Service Broker entrega mensajes a la base de datos identificada por el identificador de Service Broker.
De lo contrario, Service Broker localiza el servicio buscando primero el nombre del servicio en la base de datos que contiene la conversación. A continuación, busca el nombre del servicio en las demás bases de datos de la instancia. Service Broker entrega el mensaje al primer servicio buscado. Sin embargo, el orden en el que Service Broker busca en las otras bases de datos dentro de una instancia no se especifica y no se garantiza que sea constante de una conversación a otra. Esto significa que si existe más de una copia del servicio de destino en la instancia, Service Broker elige aleatoriamente el servicio de destino.
Otras consideraciones
Para mejorar la confiabilidad, el enrutamiento de Service Broker contiene medidas de seguridad contra bucles de enrutamiento. El enrutamiento de Service Broker reconoce el reflejo de base de datos y puede redirigir conversaciones de manera transparente a la instancia asociada activa de una base de datos reflejada.
Bucles de ruta
El reenvío de mensajes de Service Broker realiza un seguimiento del número de veces que un mensaje se reenvía para protegerlo de bucles de enrutamiento infinitos. Para obtener más información, consulte Reenvío de mensajes de Service Broker.
Si la ruta coincidente contiene una dirección de red que se resuelve en la instancia actual, SQL Server trata la conversación como si se originara fuera de la instancia. Service Broker enruta mensajes para la conversación mediante las rutas de msdb.sys.routes. El enrutamiento de estos mensajes es idéntico al de los mensajes externos a la instancia. En concreto, el reenvío de mensajes debe estar activo para que Service Broker reenvíe el mensaje a una dirección de red distinta de 'LOCAL'.
Direcciones reflejadas
Las rutas con direcciones de reflejo tienen la mayor prioridad al elegir una ruta entre el conjunto inicial de rutas coincidentes. Sin embargo, Service Broker no tiene en cuenta especialmente las direcciones de espejo al encontrar rutas coincidentes para una conversación.
Cuando Service Broker elige una ruta que especifica una dirección de espejo y Service Broker no ha entregado previamente un mensaje mediante la ruta, Service Broker envía una solicitud a ambas direcciones para determinar cuál instancia es actualmente la principal. Cuando Service Broker identifica la instancia entidad de seguridad, envía todos los mensajes que usan la ruta a esta instancia sin ponerse en contacto con la instancia de reflejo. Si el principal no es accesible, o esa instancia indica que ya no es el principal, Service Broker envía mensajes a la otra dirección para la pareja, si la instancia de SQL Server en la otra dirección indica que es el nuevo principal.
En los casos en los que Service Broker no puede llegar al principal, pero la pareja no reclama ser una nueva principal, Service Broker no envía mensajes a la pareja. A continuación, Service Broker vuelve a intentar con la dirección principal y la dirección del socio hasta que se pueda acceder a la principal, o bien el socio indica que ahora es el principal. Al adoptar este enfoque, Service Broker entrega mensajes de forma confiable cuando el principal y el socio pueden comunicarse, pero la instancia que envía el mensaje no puede llegar al principal.