SQL Server 2016触发器不能直接调用外部消息队列，因其运行在主DML事务内，禁止阻塞式网络I/O；唯一合规路径是触发器仅写入Service Broker本地队列，再由激活存储过程异步外发Kafka/RabbitMQ/HTTP。
SQL Server 2016 的触发器本身不能直接调用外部消息队列（如 Kafka、RabbitMQ 或 HTTP 接口），这是硬性限制——所有网络 I/O、系统命令、CLR 外部调用在触发器上下文中都被禁止或不可靠。唯一合规、事务安全、生产可用的路径是：用 Service Broker 做本地解耦，再由激活存储过程异步外发。
为什么触发器里不能直接发 HTTP 或调用 xp_cmdshell
SQL Server 触发器运行在主 DML 事务内，必须轻量、快速、可回滚。任何阻塞操作（如网络请求）会导致：
-
INSERT/UPDATE长时间卡住，拖垮业务响应 - 下游服务不可用时，整个事务失败，主表写入失败
-
xp_cmdshell默认禁用，启用需高权限且极不安全；sp_OACreate等 OLE 自动化函数在多数生产环境被禁用 - 即使强行启用，也无法保证事务一致性——外部调用成功但主事务回滚，数据就错位了
正确做法：触发器只写 Service Broker 队列
把“发送消息”拆成两步：触发器负责可靠入队（事务内），激活存储过程负责外发（事务外）。关键点：
- 先确认数据库已启用：
ALTER DATABASE YourDB SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE，然后查sys.databases.is_broker_enabled必须为 1 - 触发器中不能直接
SEND，必须先BEGIN DIALOG CONVERSATION创建会话句柄，再SEND ON CONVERSATION - 消息体建议用
FOR JSON PATH, WITHOUT_ARRAY_WRAPPER序列化，再CAST(... AS VARBINARY(MAX))入队 - 务必用
TRY...CATCH包裹对话创建和发送逻辑，捕获错误号9619（对话已结束）、9627（契约不匹配）等，并RETURN，避免中断主流程
激活存储过程负责真正外发
队列要配置 ACTIVATION，让 SQL Server 自动唤起存储过程消费消息，而不是轮询：
- 建队列时指定：
CREATE QUEUE SyncQueue WITH ACTIVATION (STATUS = ON, PROCEDURE_NAME = dbo.usp_SendToKafka, MAX_QUEUE_READERS = 2) - 激活过程中必须用
WAITFOR (RECEIVE ...)读取消息，处理完后立即END CONVERSATION，否则会话堆积在sys.conversation_endpoints - 外发逻辑（如调用
curl、Kafka .NET client或HTTP POST）必须放在激活过程里，且做好重试和死信处理 - 开头加
IF @@TRANCOUNT > 0 ROLLBACK，防止上游触发器回滚后，激活过程还在处理已失效的消息
容易被忽略的兼容性细节
SQL Server 2016 对 Service Broker 的支持是完整的，但几个低级陷阱常导致消息卡在 sys.transmission_queue：
- 消息类型（
MESSAGE TYPE）和契约（CONTRACT）必须显式创建，不能依赖[DEFAULT]—— 否则SEND表面成功，实际消息永远不出队 - 目标服务名（
TO SERVICE）必须与CREATE SERVICE中定义的完全一致，包括大小写和斜杠方向（如'//MyApp/Target'） - 备份恢复后，
is_broker_enabled可能重置为 0，需重新执行ENABLE_BROKER - 跨数据库通信需额外配置路由（
CREATE ROUTE），单库异步可省略，但别误配ENCRYPTION = ON导致握手失败
真正的难点不在“怎么发”，而在“怎么确保每条变更都不丢、不错、不重”。Service Broker 提供了事务绑定、持久化队列、会话顺序保障，但外发环节仍需自己兜底——比如 Kafka 发送失败时，要把消息写回重试表，而不是简单抛异常。
