MSMQ 还能用多久——“连弃用都算不上”的遗留队列迁移判断

“听说 MSMQ 已经被废止了。现在还在运行的系统，是不是也必须马上迁移？”——在既有系统的维护中，首先需要把这一点区分清楚。

MSMQ（Microsoft Message Queuing）作为操作系统功能是否存续，与从 .NET 使用它的 API 是否被支持，是两回事。在本文的基准时点 2026 年 7 月，MSMQ 并未列入官方的弃用一览，仍作为 Windows 的可选功能保留着。另一方面，标准库 System.Messaging 是 .NET Framework 专用的，并未移植到 .NET（Core 及以后）。¹²³

也就是说，问题不在于“明天 MSMQ 就会停掉”，而在于“把应用迁到 .NET 时，队列的实现会成为迁移的障碍”。

本文面向负责维护和迁移 MSMQ 系统的开发者，以及决定方针的信息系统部门。先确认事实关系与继续使用的条件，然后进入盘点、迁移目标选型、表队列的实现和切换步骤。

从 VB6 或 .NET Framework 迁移的整体做法，请参考《VB6 到 .NET 的迁移实务》《.NET Framework→.NET 迁移前检查清单》。本文只聚焦队列这一部分。

1. 先说结论：把操作系统的存续与应用的迁移分开看

如果要把应用迁到 .NET，原则上队列也要一起迁移。如果短期内仍以 .NET Framework 运维，那么在确认操作系统的支持期限与运维条件之后，可以选择继续使用。新项目不建议采用 MSMQ。⁴

从你现在要决定的事情读起

如果要通读全文，顺序是：确认存续 → 继续使用的条件 → 盘点 → 迁移目标 → 实现 → 切换。回顾判断时，请参考第 7 章的总结。

1.1. 先确认在谈哪一层

“MSMQ 还能不能用”的答案，按层次不同而不同。状态的基准时点与开头相同，都是 2026 年 7 月。

1.2. 没有被弃用的是操作系统功能

Windows 客户端的“Deprecated features”里列着 NTLM、VBScript、WordPad 等，但没有 MSMQ 这一项。Windows Server 的“Features Removed or No Longer Developed”也一样，包括 Windows Server 2025 的标签页在内都没有。¹²

弃用（deprecated）是一个官方阶段，表示已结束积极开发、将来有可能被删除，它与删除（removed）不同。就 MSMQ 而言，连这个弃用声明都还没有发布——这就是本文所确认到的状况。

1.3. 妨碍向 .NET 迁移的是托管 API

System.Messaging.MessageQueue 的参考文档覆盖的是 .NET Framework 1.1～4.8.1，没有面向 .NET（Core 及以后）的版本。Windows 兼容性包（Microsoft.Windows.Compatibility）提供注册表、WMI、Windows 服务、EventLog 等约两万个 API，但不包含 System.Messaging。³⁶

要用 P/Invoke 保留，就得连包装层的维护一起扛下来

并不是连原生 API 也没有了。MQSendMessage、MQReceiveMessage 等 Win32 API，从 .NET 用 P/Invoke 调用本身是可行的。但原先由 System.Messaging 承担的格式化器与事务协作，都要自己写成包装层并持续维护。这不是迁移的正选，而是无论如何都要保留 MSMQ 时的续命手段。⁵

1.4. 把 CoreWCF 当作“WCF 接收端”的路径来判断

.NET Framework 的 WCF 有使用 MSMQ 的绑定。把它放到 .NET 上托管的路径，就是 CoreWCF 的 MSMQ 传输（CoreWCF.MSMQ）。⁷

但它的用途是经由队列被调用的 WCF 服务的接收端。它既不是能替代 System.Messaging 的通用队列 API，也不是发送端客户端的替代品。

CoreWCF 本身有 Microsoft 的支持策略。另一方面，MSMQ 传输的实现依赖 .NET Framework 版 System.Messaging 的社区移植，不能认为这部分依赖也享有同样的保证。采用前要确认所用版本是否属于支持对象、依赖部分由谁来维护。⁷

由此可见，“MSMQ 已被废止”和“不能原样迁到 .NET”不是一个意思。选择 P/Invoke 或 CoreWCF，等于把队列的替换往后推，代价是扛下这条路径的维护负担。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 28 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 是否继续使用：由 .NET 迁移计划和运维体制来决定

2.1. 为什么仅凭“还在运行”无法做出判断

.NET Framework 4.8 作为 Windows 的组件，按所安装的操作系统的生命周期获得支持。因此，在支持期限内继续运行的计划是可以做出来的。⁴

要确认的不只是能不能运行。如果因为依赖 MSMQ 而把整个应用留在 .NET Framework 上，下面这些维护与迁移上的负担也会一并留下。

维护人员流失的问题，在《没有源代码也没有文档的系统的维护》中也有讨论。MSMQ 的咨询之所以多半不是从故障处理而是从迁移工时估算开始，正是因为真正的问题不在于能不能运行，而在于这类依赖与交接。

“操作系统还在支持期内就能运行”和“越等越容易迁移”是两回事。即使短期内不迁移，也要先把难点盘点出来。

2.2. 短期内不迁移，就要满足 4 个最低条件

没有把应用升到 .NET 的计划，从投入产出比看短期内也不打算改动——这种所谓的“搁置”在有条件的前提下是合理的。但前提是下面 4 项全部满足。

其中年度复查，是为了不漏掉弃用公告和操作系统更新影响的步骤。为应对人员调动，不只留下配置，还要留下恢复步骤。这些条件没有补齐就维持现状，风险是将来既发现不了系统已经停了，也查不出原因。

3. 盘点：记录下你把什么交给了 MSMQ

3.1. 掌握功能与术语

在 MSMQ 中，发送端把消息写入队列，同一台机器或另一台机器上的应用在自己方便的时机取出。需要迁移目标接手的性质主要有下面 3 个。

接收方停了也能先存下来：store-and-forward

即使接收方停机，消息也会先在本地累积，等恢复后再送达。这在不稳定的站点间线路上很有用，但它并不无条件地保证跨重启的持久性。

把队列与数据库更新一起确定：事务

队列操作可以纳入事务；用上 MS DTC（分布式事务协调器）之后，可以把从队列取出和数据库更新放进一个分布式事务中一起确定。

不引入额外中间件就能用：随操作系统同捆

因为不需要额外引入中间件，2000 年代的订单收发联动、报表的异步处理、生产现场的工序间联动等场景都广泛使用了它。这 3 点的组合，正是它至今仍然留存的原因。

用术语区分累积、持久化与事务

判断表中用到的术语，也在这里统一。⁹

“接收端停了也能累积”和“MSMQ 或机器重启后消息仍在”是两回事。要分开调查：只用到了前者，还是也需要由 recoverable 消息或事务消息实现的后者。

3.2. 从代码、配置和运维中找出依赖

不要只看库引用就结束盘点

先找 System.Messaging 的引用和 MessageQueue 的创建位置。但仅凭那里没有引用，还不能断定“没有使用 MSMQ”。要按调用路径分别确认。

逐个队列留下迁移判断的依据

用下面的表，逐个队列记录确认结果。目的不是确认完就算了，而是把它作为迁移方针和立项材料的依据留存下来。

4. 迁移目标：不按后继产品名，而按需要的性质来选

4.1. 用 4 个问题梳理需求

根据盘点结果，确认下面 4 点。

1. 接收端做的是不是更新自家业务数据库的处理。
2. 事务队列与数据库更新，是不是用 DTC 一起确定的。
3. 发送端与接收端是否在不同机器、不同站点。是否真的用到了 store-and-forward。
4. 消息量有多大。如果是多数业务系统那种一天几千到几万条的规模，仅凭候选方案的处理能力很难成为决定因素。

4.2. 按性质给出的首选

如果是更新同一系统业务数据库的异步任务，先考虑表队列。只有当出现向多个系统分发、路由等表队列满足不了的需求时，才选择消息代理。

为什么先考虑表队列

这里说“先考虑表队列”，并不是因为想在任何用途上都推荐数据库。而是因为在 MSMQ 时代的业务系统中常见的更新同一个数据库的异步处理里，用表队列既能简单地保持一致性，又能利用既有的备份、监控与运维流程。

适合消息代理的需求，以及需要额外设计的部分

RabbitMQ 和 Azure Service Bus 适合多系统、多语言的松耦合分发、扇出和路由。需要高吞吐量时也可以纳入考虑。但由于队列与业务数据库成了不同的资源，不能把 MSMQ+DTC 的原子性原样搬过去，而要在应用侧设计幂等性与重发。新中间件的监控、冗余、补丁和人员培训也要算进估算里。

即使迁移，也不代表停机期间的累积可以直接砍掉

请确认离线耐受性和接收端停机期间的累积，是不是可以去掉的需求。选了云上的队列，也不会自动附带发送端本地的累积；换成命名管道，停机期间的待接收也不会以同样的形式保留下来。需要的话，就在应用侧加上重发与缓冲，或者把队列保留下来。

5. 表队列：把队列操作与业务更新放在同一个数据库中确定

本章先确认把两者放进同一个数据库的意义。在此基础上，依次来看取出 SQL 的前提、顺序的保证范围、工作进程的事务、实际运维中要补上的处理。

5.1. 为什么可以不再需要 DTC

在 MSMQ 中，队列与数据库是不同的资源。要把“已从队列取出”和“已更新业务数据”一起确定，就需要由 DTC 支撑的分布式事务。

把队列改成与业务数据同一个数据库中的表之后，两者都变成对该数据库的更新。取出、业务更新和完成记录可以用一个本地事务确定。把分布式事务换成本地事务，正是这次迁移的核心。

不只接收端，发送端也能同时确定

在发送端，也可以把业务数据的更新和消息行的 INSERT 放进同一个事务。这就是 Outbox 模式，可以防止“只更新了业务数据，消息却没有发出去”这种不一致。

下面是 SQL Server 上的最小形式。C# 部分是用来表示事务边界的伪代码，不是可以直接部署的完整实现。

5.2. 保存任务的表

CREATE TABLE dbo.JobQueue (
    Id          BIGINT IDENTITY(1,1) PRIMARY KEY,
    Payload     NVARCHAR(MAX) NOT NULL,                    -- 正文。用 JSON 保存
    Status      TINYINT       NOT NULL DEFAULT 0,          -- 0:未处理 1:处理中 2:已完成
    EnqueuedAt  DATETIME2     NOT NULL DEFAULT SYSUTCDATETIME(),
    StartedAt   DATETIME2     NULL,                        -- 用于回收停在“处理中”的行
    RetryCount  INT           NOT NULL DEFAULT 0
);
CREATE INDEX IX_JobQueue_Status ON dbo.JobQueue (Status, Id);

Payload 中存放 JSON 正文，用 Status 区分未处理、处理中和已完成。StartedAt 与 RetryCount 用于回收和重试的运维。

5.3. 取出一条，以及数据库设置的确认

用一条 SQL 完成取出行的更新与正文的获取

取出时，一边把一条更新为“处理中”，一边用 OUTPUT 接收正文。借助 READPAST，可以跳过被其他工作进程行锁住的候选而不必等待，从而用多个进程并行处理。¹⁰

WITH next_job AS (
    SELECT TOP (1) *
    -- READCOMMITTEDLOCK 在 READ_COMMITTED_SNAPSHOT 为 ON 的数据库上是必需的（后述）。
    -- 在 OFF 的数据库上它与默认行为相同，所以一直带着就能同时兼顾两种情况
    FROM   dbo.JobQueue WITH (READPAST, UPDLOCK, READCOMMITTEDLOCK)
    WHERE  Status = 0
    ORDER  BY Id          -- 按投入顺序取出。这是它成其为“队列”的条件
)
UPDATE next_job
SET    Status = 1, StartedAt = SYSUTCDATETIME()
OUTPUT inserted.Id, inserted.Payload;

先确认快照设置与隔离级别

读这段 SQL 时，要确认 READ_COMMITTED_SNAPSHOT 和会话的隔离级别。

官方文档指出，当数据库的 READ_COMMITTED_SNAPSHOT 为 ON，且会话处于 READ COMMITTED、或者同时使用了 READCOMMITTED 提示时，就不能直接指定 READPAST。处理办法是：如果有 READCOMMITTED 提示就去掉它，并加入 READCOMMITTEDLOCK。¹⁰

默认的隔离级别就是 READ COMMITTED，因此不做任何处理就把它搬到启用了快照的数据库上，结果不是单纯被阻塞，而是SQL 语句直接报错。Azure SQL Database 默认为 ON。本地部署的数据库也可能为了缓解读取阻塞而启用了它，所以要先查清楚。

SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME();

上面的取出 SQL 加了 READCOMMITTEDLOCK，无论快照设置如何都使用基于锁的读取。在 OFF 的数据库上，它与默认行为相同。¹⁰

不一并写上 ROWLOCK 的理由，以及 READPAST 的局限

另一方面，与常见的 WITH (READPAST, UPDLOCK, ROWLOCK) 不同，这里没有一并写上 ROWLOCK。因为ROWLOCK 与 READCOMMITTEDLOCK 属于同一组粒度提示，同一张表上不能同时指定两者。¹⁰

READPAST 能跳过的只有行锁，跳不过页锁。像本例这样用 TOP (1) 的索引查找取一行的范围内，锁升级实际上不成问题；但如果想显式写上 ROWLOCK，就要在确认 READ_COMMITTED_SNAPSHOT 为 OFF 之后，把 READCOMMITTEDLOCK 去掉。

5.4. 取出顺序与写入业务数据的顺序是两回事

要给取出的候选指定排序

省掉 ORDER BY 写成 UPDATE TOP (1)，选中哪一行是不确定的。UPDATE 的 TOP 不会对目标行排序，仅仅存在 (Status, Id) 索引也不构成顺序保证。为了避免旧任务一直被往后排，示例中指定了 ORDER BY Id。¹¹

并行处理时先取出的未必先生效

不过，并行处理的完成顺序是对不齐的。工作进程 A 在处理任务 1 期间，工作进程 B 会用 READPAST 跳过那一行，把任务 2 先提交。

如果像对同一个订单号的更新那样，写入顺序本身有意义，就要在下面两种做法中选一种。

两种都不选，就要在设计中写明并行处理不保证整体的 FIFO。在 MSMQ 上并行接收也会出现同样的问题。重要的是，不要带着“既然是队列就一定按顺序”的理解去做迁移。

5.5. 工作进程的事务边界

接收端要对齐的，是取出、业务数据更新和完成记录这三者的事务。下面的伪代码把这三个处理交给同一个连接和事务，最后一起确定。

while (!stoppingToken.IsCancellationRequested)
{
    using var tx = connection.BeginTransaction();

    var job = DequeueOne(connection, tx);          // 上面的 UPDATE ... OUTPUT
    if (job is null)
    {
        tx.Commit();
        await Task.Delay(TimeSpan.FromSeconds(1), stoppingToken);  // 为空时只等待一个轮询间隔
        continue;
    }

    ApplyBusinessData(connection, tx, job);        // ← 更新业务数据（真正想做的工作）
    MarkDone(connection, tx, job.Id);              // Status = 2

    tx.Commit();   // “取出”与“业务更新”在这一行同时确定
}

要点在于：DequeueOne、ApplyBusinessData、MarkDone 使用同一个连接和事务，最后的 Commit 把取出与业务更新一起确定。换成消息代理时，这种同库的性质就不存在了，需要另行设计一致性方案。

5.6. 实际运维中要补上的回收、重试与清理

在最小示例之外，还要设计下面这些运维处理。

在中小规模的业务系统中，用表加轮询、或者加通知的形式，往往就够用了。在增加一套队列产品之前，先确认这种实现能否满足所需的性质与运维要求。

6. 切换步骤：先把格式、行为和接收端对齐

切换时，先把消息格式以及输入与结果的测试对齐。然后再选择是用桥接连通新旧，还是把旧队列排空后切换。

6.1. 确定新旧能够共存的消息格式

迁移后默认使用 JSON。不要带过去的是 BinaryMessageFormatter 这类BinaryFormatter 系列的序列化。BinaryFormatter 的实现已在 .NET 9 中从运行时删除，从安全角度也不推荐。⁸

另一方面，并不是所有二进制格式都不行。像 Protocol Buffers、MessagePack 这样规范由独立方维护的格式，把它原样带到新系统本身没有问题。先在 3.2 节的盘点中确认格式化器与正文的类型。

6.2. 改写之前，先用测试把输入与结果固定下来

队列处理是容易出现时序相关缺陷的部分。先准备好“给出这条输入消息，就会得到这个结果”的特性化测试，让替换之后也能机械地确认结果一致。也请参考《用特性化测试固定行为之后再重构》。

6.3. 先从接收端做起，桥接要按会丢失、会重复来设计

先让接收端支持新队列

先准备好新队列，让接收端支持它，然后再切换发送端。

中间加一个把消息从旧 MSMQ 搬到新队列的小桥接程序，就不必一次性切换所有发送端。桥接程序本身留在 .NET Framework 上也没关系。

按有无事务区分交接步骤

但是，如果在从 MSMQ 取出之后、写入新队列之前停机，就会发生丢失或重复投递。要根据迁移源队列的种类，按下面的方式设计。

队列的事务属性在创建时就已确定，之后无法更改。请注意，不能把事务接收的步骤原样用在非事务队列上。

6.4. 桥接不划算，就排空再切换

如果为桥接所做的丢失与重复对策与系统规模不相称，就不要勉强让新旧并存，而是转向计划停机把旧队列排空之后再切换的做法。

留着消息就切换，会造成重复处理和丢失。把队列排空再切换，结果往往是最安全也最快的做法——这是本文基于实务给出的判断。

7. 总结

在本文的基准时点 2026 年 7 月，MSMQ 尚未被官方列为弃用。作为操作系统功能留存下来，和容易迁移到 .NET，是两回事。System.Messaging 封闭在 .NET Framework 之内，要把应用升到 .NET，原则上队列也要一并重新审视。¹²³

如果短期内继续使用，就要确认操作系统的支持期限，并准备好搭建与恢复步骤、队列监控、配置记录以及每年一次的判断复查。搁置的最大风险不只在技术，还在于将来没有人能碰它。

如果要迁移，先盘点依赖与消息格式。对于更新同一个业务数据库的异步处理，表队列是首选。它可以把原先由 MSMQ+DTC 承担的一致性，换成同一数据库上的本地事务。出现向多个系统分发、路由等表队列满足不了的需求时，再考虑 RabbitMQ 或 Azure Service Bus。

在此基础上，再确认 SQL 的隔离级别与提示、并行时的写入顺序，以及桥接的丢失与重复对策。重要的是，不要因为“听说被废止了”就着急，而要先掌握自己的系统究竟依赖什么，再决定维持还是迁移。

相关文章

• VB6 应用能用到什么时候 —— 运行时支持现状与务实的 .NET 迁移做法
• .NET Framework→.NET 迁移前检查清单
• 用特性化测试（Characterization Test）固定行为之后再重构
• Windows 的进程间通信（IPC）判断表
• 认为按 Send 的单位就能 Receive 的误解 —— 按字节流处理的接收端设计
• 接手了没有源代码也没有文档的系统，该怎么承接下来
• 业务应用的数据库架构迁移与版本管理

相关咨询领域

小村软件有限责任公司承接包括 MSMQ 在内的遗留架构盘点与迁移规划、从 .NET Framework 到 .NET 的迁移，以及包含队列处理在内的业务系统改造。

• 现有资产复用与迁移支持
• 现有 Windows 软件的改造与维护
• Windows 应用开发
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

MSMQ 已经被废止了吗？

没有。截至 2026 年 7 月，MSMQ 既没有出现在 Windows 客户端的弃用功能一览中，也没有出现在 Windows Server 的“已删除功能与停止开发功能”一览中。它仍作为 Windows 的可选功能同捆在现行操作系统中。“已被废止”这种说法之所以流传开来，是因为与 .NET 一侧的状况混淆了。处理 MSMQ 的标准类库 System.Messaging 只存在于 .NET Framework，并未移植到 .NET（Core 及以后）。也就是说，准确的状态是“作为操作系统功能仍然存续，但没有从现代 .NET 使用它的官方手段”。

有没有办法从 .NET 8 或 .NET 10 使用 MSMQ？

没有官方的托管 API。System.Messaging 是面向 .NET Framework 4.8.1 及之前版本的 API，Windows 兼容性包（Microsoft.Windows.Compatibility）中也不包含它。用 P/Invoke 调用 MSMQ 的原生 Win32 API（如 MQSendMessage）在技术上可行，但这意味着要自己编写并维护包含格式化器与事务协作在内的包装层。社区方面，CoreWCF 项目发布了用于 MSMQ 传输的包（CoreWCF.MSMQ），但它是为了在现代 .NET 上托管经由队列被调用的 WCF 服务（WCF 服务端的移植），既不是能替代 System.Messaging 的通用队列 API，也不是发送端客户端的替代品。它的实现同样依赖 .NET Framework 版 System.Messaging 的社区移植。它可以作为验证或临时续命的选项。CoreWCF 本身有微软官方的支持策略，但这并不意味着这个 MSMQ 实现所依赖的 System.Messaging 社区移植也享有同样的保证，因此要把它作为业务系统的前提，就应先确认所用版本是否属于支持策略的对象、以及依赖部分如何处理，再做判断。从实务角度看，正道是在把应用升到 .NET 的同时一并迁移队列。

迁移目标选 RabbitMQ 还是 Azure Service Bus 更好？

在这二选一之前，请先考虑把数据库的表当作队列使用的方案。使用 MSMQ 的中小规模业务系统，多数情况下队列的对端处理就是更新自家的数据库。这种情况下，表队列可以在与业务数据相同的本地事务中确定“取出消息”与“更新业务数据”，用更简单的机制替代原本由 MSMQ+分布式事务（DTC）实现的一致性。只有在表队列满足不了的需求上，例如需要多系统之间的松耦合分发或高吞吐量时，才去考虑：本地部署需求强就选 RabbitMQ，可以放到云上就选 Azure Service Bus——按这个顺序推进不容易出问题。

短期内保持 .NET Framework 不动、把它搁置起来，这个判断可行吗？

有条件地可行。.NET Framework 4.8 作为 Windows 的组件，按操作系统的生命周期获得支持，MSMQ 本身也没有被弃用，因此可以预期它会“继续运行”。不过，如果选择搁置，至少要做到下面 4 点：在装机步骤中写明 MSMQ 功能的启用方法、加上队列长度与日志队列的监控、把消息格式与连接配置写成文档、为人员调动做好准备并留下恢复步骤。搁置真正的风险不在技术，而在于“变得没有人能碰它”。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。