这是一个判断电话。我要说的最决定性的因素是插座保持打开状态的时间。如果它的“事务性”长度在系统之间差异很大，那么我会说这很好。我没有看到群集的任何问题，因为SQL Server没有Active / Active群集（但是NLB肯定有可能）。另一个决定因素将是套接字是否是单实例（在非广播端口上侦听）。
所以，如果是这样，
- 该函数/存储过程将从T-SQL（SQL Server代理或SSRS？）中调用
- 功能/存储过程预计将在“交易”时间段内退出
（我会说典型的情况是30秒-但在高负载的系统上，调用先锁定然后等待30秒的调用可能会很麻烦，因此您需要考虑用例。）
- 该函数是可重入的（可以并行运行多次）
否，如果：
- 该函数是从C＃或其他功能更强大的客户端调用的（您在此处进行处理-也许是库吗？）
- 该功能将等待一段不确定的时间，远远超过典型的交易时间
- 该函数是单个实例（只有一个会话才能成功执行该函数）
考虑一些说明差异的示例：
SQL Server代理作业，每天使用从大型机上抓取的费率图表填充表。
已安装CLR函数，该函数获取XML抓取文档，连接到大型机，并使用TN 3270屏幕抓取以XML文档中指定的形状返回结果集
- 必须从SQL中调用（以简化维护和故障报告）
- 如果超过设置的超时时间（〜30s），则应该超时
- 可以在多个会话中并行运行
- 答案：SQL CLR函数的理想人选
“ Ticker”应用程序，其中应用程序侦听价格更新的UDP广播，并将结果集作为流式结果集返回给客户端
CLR函数打开UDP广播侦听端口，并将结果异步写回到客户端。这一直持续到达到应用程序定义的结束条件（特定的数据包有效负载，查询取消或超时）
- 必须从SQL中调用以处理多种平台（Linux上的PHP上的某些客户端，Windows上的VB6上的其他客户端）
- 具有定义的且用户可控制的超时（但部分无法通过此测试，因为它可能会超过交易持续时间）。
- 可以并行（广播）在多个会话中运行
- 答案：SQL CLR函数的“确定”候选人
将接收到的事件转储到表中的系统日志服务器
一个函数，该函数在0.0.0.0:514上打开UDP侦听器并返回事件作为流结果集。
- 没有真正的理由，因为它正在缓冲到表中，而不必从SQL调用
- 没有超时-预计将运行24/7
- 调用应用程序（SQL Server代理）必须确保此功能始终执行一次，如果失败则将其重新启动（重新实现服务管理器）
- 答案：：不太适合SQL CLR，请考虑使用Service Broker + NT服务