- **信创 = 信息技术应用创新**，用国产软硬件替换 Intel + Windows/Oracle/IBM 底座；驱动力是**自主可控（根因）+ 安全合规（直接动因，金融靠人行文件）+ 产业替代（结果）**。 - **名录七层**：芯片 / 整机 / OS / 数据库 / 中间件 / 云 / 办公，每层至少能报出 3–5 个产品名。 - **开源件不在名录的四个理由**：主体在国外、不可审计、许可可变（Redis 2024 改协议是活例子）、无国内厂商兜底。**但「不在名录 ≠ 禁止使用」**，存量分阶段替换。 - **没 MQ 的三条路**：国产 Redis 协议产品（Stream + 消费者组 + XACK/XAUTOCLAIM）、**数据库任务表**（status + version CAS + 退避 + 死信 + 僵尸回收）、进程内队列（Disruptor / Chronicle Queue，只管单机）。 - **改造真正干的活**：建库参数定死 → SQL 方言适配 → 驱动/连接池替换 → 存储过程重写 → **重收统计信息 + 重跑 EXPLAIN 做性能回归**。 **标准口述答案**（这一段 90 秒，是 Q9.11 的总纲，细节见 9.11.1–9.11.9） > 信创我的理解是「自主可控替代」，不是技术偏好，是准入要求——很多政企金融项目的招标文件直接写「数据库须选用名录内产品」。它分七层：芯片是鲲鹏、飞腾、龙芯、海光、申威；操作系统是麒麟和统信 UOS；数据库是达梦、人大金仓、OceanBase、GaussDB、TiDB、openGauss；中间件是东方通、金蝶、宝兰德、中创；云是华为云 Stack、浪潮云；办公是 WPS。 > > 关于 RabbitMQ 不在名录这件事，我理解逻辑是四个「不」：主体不在国内、不可审计、许可可能变、没有国内厂商兜底。Redis 2024 年改许可证就是个活例子。但「不在名录」不等于「禁止使用」，存量系统还在跑，落地方式是新建优先选名录内、存量分阶段替换。 > > 如果没有 MQ，队列我会走两条路。一条是国产 Redis 协议产品，用 Stream 加消费者组，XACK 确认、XPENDING 看积压、XAUTOCLAIM 处理消费者宕机，比用 List 模拟可靠得多。另一条是**数据库任务表**——库本来就在名录里，任务表建在达梦或者金仓上，用状态字段加 version 做 CAS 抢占，失败按次数指数退避，超阈值进死信表人工处理，worker 挂了靠 update_time 超时回收。这条路吞吐不高，但强一致、可查可改，金融的批量跑批很多就是这么做的。 > > 我实际做过的是数据库适配这一层：函数改写、分页方言、大小写和空串语义、`ON DUPLICATE KEY UPDATE` 改 `MERGE`，迁完还要重新收集统计信息做性能回归。 #### 9.11.1 什么是信创，为什么推 **一句话**：信创 = 信息技术应用创新，本质是**用国产软硬件替换掉以 Intel + Windows/Oracle/IBM 为核心的 IT 底座**，目标是供应链自主可控。三个驱动力，按面试里该讲的顺序： | 驱动力 | 具体含义 | 面试里怎么说 | |---|---|---| | **自主可控（根因）** | 芯片、OS、数据库、中间件的知识产权和供应链掌握在自己手里；避免制裁、断供、后门风险 | 「根子上是供应链安全，不是性能比谁好」 | | **安全合规（直接动因）** | 等保 2.0、关基保护条例、密码法、数据安全法；金融行业还有人民银行的相关规划与试点要求 | 「金融信创是人民银行推动的，分批次试点，我们做的存量改造就是按这个文件走」 | | **产业替代（结果）** | 用市场规模养生态，让国产 CPU/OS/DB 从「能用」走到「好用」 | 「先用起来才有生态，所以早期产品体验差也得推」 | **发展脉络（能报出来显得懂行）**：2013 年前后「去 IOE」是前身（阿里主导，去 IBM 小型机 / Oracle / EMC 存储）→ 2016 年后形成「信创」这个概念 → 2020 年起党政信创大规模铺开（一期试点）→ 2020–2022 金融信创分批试点（一期、二期、三期，从办公系统到一般业务系统再到核心系统）→ 2023 年后进入「存量系统改造 + 行业纵深（电信、电力、交通、医疗、教育）」。 **关键认知（这句最值钱）**：信创不是「技术选型偏好」，是**准入要求**。很多政企/金融项目的招标文件里直接写「数据库须选用信创名录内产品」，这时候技术好坏不重要，能不能进名录才重要。所以面试官说「RabbitMQ 不在信创名录里，我们后续大概率不会用 MQ」——他不是在讨论技术，是在说**合规约束**。听懂了这一层，回答的方向才不会错（不是去论证 RabbitMQ 多好用，而是给替代方案）。 #### 9.11.2 信创名录包含哪几层，各层主流产品信创的「名录」不是一张表，而是**分层的一套产品目录**（中央国家机关协议供货、各省市信创目录、行业目录，金融行业另有自己的准入清单）。按层次记，七层： | 层级 | 作用 | 主流国产产品 | 对应的国外主流 | |---|---|---|---| | **① 芯片（CPU）** | 算力底座，指令集决定生态 | 鲲鹏（ARM，华为）、飞腾（ARM，中国电子）、龙芯（LoongArch，自主指令集）、海光（x86 授权，中科曙光系）、申威（Alpha 衍生，超算） | Intel Xeon / AMD EPYC | | **② 整机 / 服务器** | 把芯片装成可用设备 | 长城、浪潮、联想开天、同方、中科曙光、华为泰山 | Dell / HP / IBM | | **③ 操作系统** | 桌面 + 服务器 OS | 银河麒麟（麒麟软件）、统信 UOS、中科方德、麒麟信安、OpenEuler 系（华为开源，商业发行版由麒麟/统信等提供） | Windows / RHEL | | **④ 数据库** | 事务与分析 | 达梦 DM、人大金仓 KingbaseES、OceanBase、GaussDB（华为）、TiDB（PingCAP）、openGauss（华为开源）、神通、南大通用 GBase | Oracle / MySQL / SQL Server | | **⑤ 中间件** | 应用服务器、消息、缓存、Web 容器 | 应用服务器：东方通 TongWeb、金蝶 Apusic、宝兰德 BES、中创 InforSuite；消息：东方通 TongLINK/Q 等；缓存：东方通 TongRDS、中创系列 | WebLogic / WebSphere / Tomcat / RabbitMQ / Redis | | **⑥ 云平台** | IaaS/PaaS 底座 | 华为云 Stack、浪潮云、天翼云、移动云、麒麟信安云 | AWS / Azure / VMware | | **⑦ 应用软件 / 办公套件** | 直接面向用户 | WPS Office、永中 Office、数科 OFD（版式文档）、金山/福昕 PDF、国产浏览器（奇安信、360、红莲花） | MS Office / Adobe | **几个必须记准的细节**（被追问时的加分点）： - **龙芯是唯一自主指令集**（LoongArch），鲲鹏/飞腾是 ARM 授权，海光是 x86 授权，申威源自 Alpha。所以「自主可控程度」排序上，龙芯 > 申威 > 鲲鹏/飞腾 > 海光（x86 生态兼容性最好，但授权来源是国外）。这个排序在面试里说出来，比背产品名有分量。 - **麒麟有两家**：麒麟软件（银河麒麟，中国电子 CEC 系）和麒麟信安（湖南，偏电力行业）。别混。 - **openGauss 和 GaussDB 的关系**：openGauss 是华为开源的内核，GaussDB 是华为云的商业产品（内部还有 GaussDB(for MySQL) 等分支）。**openGauss 是开源社区件，GaussDB 才是商业名录产品**——这个区分和下面 9.11.3 的逻辑一致。 - **TiDB 和 OceanBase**：都是分布式数据库，TiDB 是 PingCAP（国内公司，开源 + 商业版），OceanBase 是蚂蚁（开源 + 商业版）。两家都是国内主体，所以在名录讨论里有位置。 - **金融行业特别看重**：达梦、金仓在银行/政务的存量替换里占比最高（生态成熟、Oracle 兼容性好、迁移工具链完善）；OceanBase/TiDB 更多用在新建的分布式核心或大数据场景。 #### 9.11.3 为什么 RabbitMQ / Kafka / Redis / MySQL / Nginx 不在（或不被推荐进）信创名录这是那场面试的**真正杀招**，必须答得干净。核心不是「技术不好」，是**四个「不」**： | 维度 | 问题 | 后果 | |---|---|---| | **主体不在国内** | RabbitMQ → VMware/Broadcom；Kafka → Apache（主体在美国，Confluent 商业化）；Redis → Redis Ltd.（美国）；MySQL → Oracle；Nginx → F5（2019 收购） | 出问题没有国内法人主体可以追责、签合同、承诺 SLA | | **不可审计** | 开源 ≠ 可控。代码可以看，但**构建产物、依赖链、后续版本走向**不受控 | 无法做供应链安全审查，无法承诺「不会有后门/不会断供」 | | **许可与断供风险** | Redis 2024 年 3 月把许可证从 BSD 改为 RSALv2/SSPLv1（2024 年 11 月 Redis 8 又增加 AGPLv3 选项）；Elastic 改 SSPL；HashiCorp 改 BUSL | 「今天免费，明天改许可」是现实发生过的事，政企不能把核心系统押在这上面 | | **无国产厂商兜底** | 社区版没有厂商 SLA，出问题只能靠社区；而名录要求「有厂商、有服务、有源码托管/代码审计能力」 | 出了生产事故没人兜底，这在金融场景不可接受 | **所以名录收录的逻辑是**：产品必须有**国内法人主体**、能签合同、能提供**服务与技术支持**、能配合**安全审查**，最好还能做**源码托管**。这三条开源社区件都不满足。 **但必须补一句关键的限定**（这句话能让回答从「背结论」升级成「懂分寸」）： > 不在名录 ≠ 禁止使用。实际项目里大量系统还在跑 MySQL 5.7、Redis、Nginx，因为存量系统不可能一天换完。信创的落地方式是：**新建系统优先选名录内产品；存量系统按「先外围后核心、先办公后业务」分阶段替换**；过渡期允许开源件继续运行，但要有替换路线图。所以面试官说「后续大概率不会用 MQ」，准确理解是「新项目不引入，存量逐步替」。 **推荐的国产替代对照表**（这张表直接背，被问「那用什么替代」时就是答案）： | 要被替换的 | 国产替代（名录方向） | 说明 | |---|---|---| | RabbitMQ / Kafka | 东方通 TongLINK/Q、金蝶 Apusic 消息中间件、宝兰德 BES 消息、中创 InforSuite 消息 | 多为 JMS/MQ 规范实现，功能覆盖不如 RabbitMQ 灵活，路由能力弱，事务消息支持看具体产品 | | Redis | 东方通 TongRDS、华为云 DCS、阿里云 Tair、中创缓存产品 | 多数是「Redis 协议兼容 + 国产厂商服务」，迁移成本低（客户端不用改，改连接串） | | MySQL / Oracle | 达梦 DM8、人大金仓 KingbaseES V8、OceanBase、GaussDB、TiDB、openGauss | 见 9.11.8 的差异表 | | Nginx | 东方通 TongHttpServer、宝兰德 BES WebServer、中创 InforSuite Web | 多数基于开源内核二次开发 + 厂商服务 | | Tomcat | 东方通 TongWeb、金蝶 Apusic、宝兰德 BES、中创 InforSuite | 应用服务器是信创中间件里最成熟的一层 | | 定时任务（XXL-Job 等） | 国产商用调度平台，或**自研数据库任务表**（见 9.11.5） | XXL-Job/PowerJob 是国人开源（Apache 2.0），主体在国内团队，但严格说不在名录里 | | ELK | 国产日志平台 / 用国产数据库 + 自研检索 | Elastic 改 SSPL 后这一层替换诉求最强 | > 记法：**「芯片看指令集，OS 看麒麟统信，库看达梦金仓，中间件看东方通金蝶宝兰德中创，云看华为浪潮，办公看 WPS」**。这一句能在 10 秒内把七层串完。 #### 9.11.4 不用 MQ 怎么做队列：方案一 · Redis 那条临场回答的第一句是「最简单是用 Redis，LPUSH 入队 BRPOP 出队，配合 Lua 保证原子性，可靠投递用处理中集合和完成集合模拟 MQ」。这是对的骨架，但**必须补三个层次**才扛得住追问：简单版会丢、可靠版怎么补、Stream 才是正解。 **层次 1：LPUSH + BRPOP（能用，但会丢）** ```bash # 生产 LPUSH queue:cdr '{"callid":"C2001","duration":62}' # 消费（阻塞式，超时 5 秒） BRPOP queue:cdr 5 ``` 问题一目了然：`BRPOP` 是**先弹出再处理**，弹出那一刻消息就从 Redis 消失了。消费者拿到消息、还没写完库就宕机 → 消息永久丢失。所以这个版本只能用于「丢了也无所谓」的场景（日志、埋点、可重算的统计）。 **层次 2：BRPOPLPUSH / BLMOVE + 处理中队列（可靠版，模拟 ACK）** 核心思路是**把「取出」和「确认」分成两步**，中间消息留在「处理中」队列里，处理成功才删： ``` 待处理队列 queue:cdr ──BRPOPLPUSH──▶ 处理中队列 queue:cdr:processing │ 处理成功 ──LREM──┘ （从 processing 删掉 = ACK）处理失败 ── 超时巡检任务把 processing 里的搬回待处理 = 重投 ``` ```bash # 原子地「从待处理取出 + 放进处理中」，一条命令完成，中间不会丢 BRPOPLPUSH queue:cdr queue:cdr:processing 5 # 处理成功后确认（LREM 删除这一条 = ACK） LREM queue:cdr:processing 1 '{"callid":"C2001","duration":62}' # 处理失败且要重试：搬回待处理队列尾部 RPOPLPUSH queue:cdr:processing queue:cdr ``` 配套需要一个**巡检任务**（每 30 秒跑一次），扫 `processing` 队列里「存在时间超过阈值」的消息搬回待处理队列——这就是「消费者宕机后的自动重投」。为了让巡检能判断「存在多久」，更严谨的做法是**处理中不用 List 而用 ZSet**，score 存「取出时间戳」： ```bash # 取出时同时写入处理中 ZSet（用 Lua 保证两步原子） EVAL "local m = redis.call('RPOP', KEYS[1]); if m then redis.call('ZADD', KEYS[2], ARGV[1], m) end; return m" 2 queue:cdr queue:cdr:inflight 1735689600 # 巡检：取出超过 60 秒还在处理中的（说明消费者挂了） ZRANGEBYSCORE queue:cdr:inflight 0 1735689540 LIMIT 0 100 # 确认成功 ZREM queue:cdr:inflight '' ``` **Lua 为什么必须用**（这是追问点）：`RPOP` 和 `ZADD` 是两条命令，中间进程崩溃就出现「消息已弹出但没进处理中」= 丢消息。Redis 单线程执行 Lua 脚本，脚本内的多条命令是原子的，所以把「弹出 + 记入处理中」包成一个脚本，就消除了这个窗口。**注意：Lua 脚本里不能有阻塞命令（不能用 BRPOP），所以「阻塞版」只能用 BRPOPLPUSH 这种单命令原子操作，不能用 Lua 模拟阻塞。** **层次 3：Redis Stream（真正的正解，5.0+）** Stream 是 Redis 官方为消息队列设计的结构，**天生带消费者组、ACK、Pending 列表、消息回溯**，比 List 模拟可靠得多： ```bash # 生产消息（* 表示自动生成 ID，形如 1735689600000-0） XADD stream:cdr * callid C2001 duration 62 # 建消费者组（从 0 开始消费全部历史；$ 表示只消费新消息） XGROUP CREATE stream:cdr group-billing 0 MKSTREAM # 消费：> 表示取未投递过的新消息，会同时写入 Pending 列表（= 已投递未确认） XREADGROUP GROUP group-billing consumer-1 COUNT 10 BLOCK 5000 STREAMS stream:cdr > # 处理成功后确认（从 Pending 列表移除 = ACK） XACK stream:cdr group-billing 1735689600000-0 # 查看 Pending：哪些消息投递了但没 ACK，以及被谁拿走、拿了几次 XPENDING stream:cdr group-billing - + 10 # 消费者宕机后，把闲置超过 60 秒的消息转移给新消费者（Redis 6.2+） XAUTOCLAIM stream:cdr group-billing consumer-2 60000 0-0 COUNT 10 # 6.2 之前用 XCLAIM XCLAIM stream:cdr group-billing consumer-2 60000 1735689600000-0 ``` | 能力 | List 模拟 | Stream | |---|---|---| | 消息持久化 | 有（但弹出即消失） | 有（未 ACK 留在 Pending） | | 消费者组 | 需自己实现（多消费者抢同一 List） | **原生** | | ACK / 重投 | 靠 processing 队列 + 巡检 | **XACK + XPENDING + XAUTOCLAIM** | | 消息回溯 | 不支持 | 支持（按 ID 范围重读） | | 投递次数统计 | 自己维护 | `XPENDING` 自带 delivery count | | 内存控制 | 手动 LTRIM | `XADD MAXLEN ~ 100000` 近似裁剪 | | 阻塞拉取 | BRPOP 支持 | `BLOCK` 支持 | **Stream 的坑（被追问就说这些）**： - **Pending 会无限增长**：只 `XREADGROUP` 不 `XACK`，Pending 列表永远不清，内存会涨。必须有监控（`XPENDING` 的 count）+ 定期巡检 `XAUTOCLAIM`。 - **消息不会自动删除**：Stream 是「日志式」的，`XACK` 只清 Pending，消息本体还在 Stream 里，要靠 `XADD MAXLEN` 裁剪或 `XTRIM`，否则内存撑爆。这点和 List 完全不同，**是 Stream 最容易踩的坑**。 - **消费者名必须稳定**：每次重启用新消费者名，会留下一堆僵尸消费者和它们的 Pending（要靠 `XGROUP DELCONSUMER` 清）。 - **持久化**：AOF `everysec` 最坏丢 1 秒；要更强得 `appendfsync always`（性能掉很多）。副本切换（主从）也可能丢最近写入，所以严格场景仍需业务侧对账。 **Redis 方案的适用边界（这个判断比代码更重要）**： | 场景 | 合不合适 | 理由 | |---|---|---| | 任务分发、异步通知、可重算的统计 | ✅ 很合适 | 轻量，不用引入 MQ | | 需要延迟/定时（用 ZSet 存到期时间） | ✅ 合适 | ZSet 天然按 score 排序，见 Q9.7 | | 中等量级（万级 QPS 以内）、可容忍极端情况少量丢失 | ✅ 合适 | 性能足够 | | 强一致资金流水、不能丢一条 | ⚠️ 需 AOF always + 主从 + 对账 | Redis 本质是缓存，不是可靠存储 | | 百万级堆积、需要回溯重放 | ❌ 不合适 | 内存成本高，无磁盘分层 | **国产化说法（面试的原话可以这么说）**： > Redis 本身不在信创名录里，但**基于 Redis 协议的国产中间件在**——比如东方通的 TongRDS、华为云 DCS、阿里云 Tair，客户端不用改，改连接串和部署方式就行。所以「用 Redis 做队列」在信创项目里通常不是「用开源 Redis」，而是「用国产 Redis 协议兼容产品」，这一层替换成本是最低的。不过要注意这些产品对 Stream 的支持程度不一定和 Redis 5.0+ 完全一致，**上之前要确认版本能力**——这句是真实的坑，说出来很加分。 #### 9.11.5 方案二 · 数据库任务表（政企/金融最实用的一条路）那条临场回答的第二段是「用 MySQL 或达梦做任务表，带条件的 UPDATE 加 version 做 CAS 防重复领取，失败按次数退避，超阈值进死信」。方向完全正确——**这条路的真正优势是「数据库本来就在信创名录里」**：达梦、金仓都是名录产品，任务表建在它们上面，整个方案天然合规，一个中间件都不用引。金融行业的批量跑批、日终结算、异步工单，很多就是这么做的。 **① 表结构（DDL，MySQL 版）** ```sql CREATE TABLE t_task_queue ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键，同时决定领取顺序', biz_type VARCHAR(64) NOT NULL COMMENT '业务类型：CDR_BILL / SMS_SEND / REPORT_GEN', biz_key VARCHAR(128) NOT NULL COMMENT '业务幂等键：callid / orderNo', payload TEXT NOT NULL COMMENT '任务参数 JSON', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待执行 1执行中 2成功 3失败待重试 4死信', retry_count INT NOT NULL DEFAULT 0 COMMENT '已重试次数', max_retry INT NOT NULL DEFAULT 5 COMMENT '最大重试次数', next_execute_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '下次可执行时间，退避靠它', version INT NOT NULL DEFAULT 0 COMMENT 'CAS 版本号，防重复领取', claim_token VARCHAR(64) DEFAULT NULL COMMENT '本次领取凭证 UUID，用于批量抢占后回查', worker_id VARCHAR(64) DEFAULT NULL COMMENT '执行者标识 host:pid', error_msg VARCHAR(1000) DEFAULT NULL COMMENT '最后一次失败原因', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz (biz_type, biz_key) COMMENT '业务幂等：同一业务键只有一条任务', KEY idx_poll (status, next_execute_time, id) COMMENT '领取走这个索引', KEY idx_worker (worker_id, status) COMMENT '僵尸任务回收用' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='通用任务队列'; ``` **达梦 DM8 的等价 DDL**（面试如果问「换达梦怎么写」，能背出差异就赢了）： ```sql CREATE TABLE t_task_queue ( id BIGINT IDENTITY(1,1) NOT NULL, biz_type VARCHAR(64) NOT NULL, biz_key VARCHAR(128) NOT NULL, payload CLOB NOT NULL, -- TEXT → CLOB status TINYINT DEFAULT 0 NOT NULL, retry_count INT DEFAULT 0 NOT NULL, max_retry INT DEFAULT 5 NOT NULL, next_execute_time TIMESTAMP DEFAULT SYSDATE NOT NULL, -- DATETIME → TIMESTAMP，NOW() → SYSDATE version INT DEFAULT 0 NOT NULL, claim_token VARCHAR(64), worker_id VARCHAR(64), error_msg VARCHAR(1000), create_time TIMESTAMP DEFAULT SYSDATE NOT NULL, update_time TIMESTAMP DEFAULT SYSDATE NOT NULL, PRIMARY KEY (id), CONSTRAINT uk_biz UNIQUE (biz_type, biz_key) ); CREATE INDEX idx_poll ON t_task_queue (status, next_execute_time, id); -- 注意：DM 没有 ON UPDATE CURRENT_TIMESTAMP，update_time 必须在 SQL 里显式赋值 -- 注意：DM 默认大小写敏感，表名/列名建的时候是什么就是什么，SQL 里必须大小写一致 ``` **② 抢占 SQL（三种写法，按数据库能力选）** **写法 A：单条 CAS（最通用，MySQL 5.7 / DM8 / 金仓都能跑）** ```sql -- 第一步：候选（只读，不加锁；加 FOR UPDATE 会阻塞，见写法 C） SELECT id, version FROM t_task_queue WHERE status = 0 AND next_execute_time <= NOW() ORDER BY id LIMIT 100; -- 第二步：逐条 CAS 领取。影响行数 = 1 表示抢到，= 0 表示被别人抢先，跳过 UPDATE t_task_queue SET status = 1, worker_id = #{workerId}, version = version + 1, update_time = NOW() WHERE id = #{id} AND version = #{version} AND status = 0; ``` `WHERE version = ?` 就是乐观锁：两个消费者同时读到 version=3，只有一个能 UPDATE 成功（MySQL 行锁 + 条件判断），另一个影响行数为 0。**这条是本方案的核心，必须能一行一行讲清楚。** **写法 B：批量抢占 + claim_token 回查（推荐，一条 SQL 抢一批，兼容性好）** ```sql -- 一条语句抢占一批：MySQL 的 UPDATE ... ORDER BY ... LIMIT 是支持的 UPDATE t_task_queue SET status = 1, worker_id = #{workerId}, claim_token = #{claimToken}, -- 本次领取的 UUID，全局唯一 version = version + 1, update_time = NOW() WHERE status = 0 AND next_execute_time <= NOW() ORDER BY id LIMIT #{batchSize}; -- 用 claim_token 精确回查「我这次到底抢到了哪几条」 SELECT id, biz_type, biz_key, payload, retry_count, max_retry FROM t_task_queue WHERE claim_token = #{claimToken}; ``` **为什么加 claim_token 而不是靠 `worker_id` 回查**：同一台机器上的同一个 worker 会并发领多次，靠 `worker_id` 回查会把上一批的也捞出来（上一批可能还没处理完）。用一次性 UUID，每次领取互不干扰。这个细节是「真做过」和「看过博客」的分水岭。 > 注意：`UPDATE ... ORDER BY ... LIMIT` 在 MySQL 上可用；**达梦/金仓对 `UPDATE ... LIMIT` 支持不一致**，移植时通常改成写法 A（先 SELECT id 再按 id 列表 UPDATE），或者用 `WHERE id IN (SELECT ...)` 子查询。**方言差异要在设计阶段就规避**，这是信创改造的真实经验。 **写法 C：`FOR UPDATE SKIP LOCKED`（MySQL 8.0+ / 部分国产库新版本）** ```sql BEGIN; SELECT id FROM t_task_queue WHERE status = 0 AND next_execute_time <= NOW() ORDER BY id LIMIT 100 FOR UPDATE SKIP LOCKED; -- 跳过已被别人锁住的行，不排队等 UPDATE t_task_queue SET status = 1, worker_id = #{workerId}, version = version + 1 WHERE id IN (...); COMMIT; ``` 优点是不用 CAS、不会空转；缺点是**依赖数据库支持 `SKIP LOCKED`**（MySQL 8.0+、PostgreSQL 9.5+ 支持；达梦/金仓需按版本确认，Oracle 系是 11g 之后才有），且长事务会持有行锁。**在信创项目里，能不用就不用，用写法 B 更稳。** **③ 失败退避 + 僵尸回收 + 死信（三条 SQL，缺一条方案就不完整）** ```sql -- (1) 失败重试：指数退避，2^retry 分钟。注意 MySQL 的 UPDATE 是「从左到右」求值， -- retry_count 在前面已经 +1，后面算幂时用的是新值，这是最容易写错的地方 UPDATE t_task_queue SET status = 0, retry_count = retry_count + 1, next_execute_time = DATE_ADD(NOW(), INTERVAL POW(2, retry_count + 1) MINUTE), worker_id = NULL, claim_token = NULL, error_msg = #{errorMsg}, update_time = NOW() WHERE id = #{id} AND status = 1; -- (2) 超阈值进死信：不再重试，等人工 UPDATE t_task_queue SET status = 4, worker_id = NULL, claim_token = NULL, error_msg = #{errorMsg}, update_time = NOW() WHERE id = #{id} AND status = 1 AND retry_count + 1 >= max_retry; -- (3) 僵尸任务回收：worker 崩溃导致 status 一直停在 1，靠 update_time 判定超时 UPDATE t_task_queue SET status = 0, worker_id = NULL, claim_token = NULL, retry_count = retry_count + 1, update_time = NOW() WHERE status = 1 AND update_time < DATE_SUB(NOW(), INTERVAL 10 MINUTE); ``` 第 (3) 条是**这个方案唯一真正的难点**：MQ 有 Broker 帮你检测消费者掉线并重投，任务表没有，必须自己实现「心跳超时回收」。判定阈值要大于单任务最长执行时间（比如最长 5 分钟 → 阈值 10 分钟），否则会把还在跑的任务误判重投，造成重复执行（这时幂等就成了必需项）。 **④ Java 侧完整伪代码（可直接改成 Spring 组件）** ```java @Component public class DbTaskQueueConsumer { @Resource private JdbcTemplate jdbc; // 或 MyBatis Mapper @Resource private TaskHandlerRegistry registry; // biz_type → 处理器 private final String workerId = hostName() + ":" + pid(); private final ExecutorService pool = new ThreadPoolExecutor( 4, 8, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(200), new ThreadPoolExecutor.CallerRunsPolicy()); /** 定时拉取：每 1 秒一次，每次最多抢 50 条。多实例同时在跑，靠 CAS/claim_token 互斥 */ @Scheduled(fixedDelay = 1000) public void poll() { String token = UUID.randomUUID().toString(); int claimed = jdbc.update(""" UPDATE t_task_queue SET status = 1, worker_id = ?, claim_token = ?, version = version + 1, update_time = NOW() WHERE status = 0 AND next_execute_time <= NOW() ORDER BY id LIMIT 50 """, workerId, token); if (claimed == 0) return; // 没抢到，下轮再来 List tasks = jdbc.query( "SELECT * FROM t_task_queue WHERE claim_token = ?", rowMapper(), token); for (Task t : tasks) { pool.submit(() -> execute(t)); // 交给线程池，控制并发度 } } private void execute(Task t) { try { TaskHandler h = registry.get(t.getBizType()); h.handle(t); // 业务处理，内部自己保证幂等 jdbc.update("UPDATE t_task_queue SET status = 2, update_time = NOW() WHERE id = ?", t.getId()); } catch (Exception e) { retryOrDeadLetter(t, e); } } private void retryOrDeadLetter(Task t, Exception e) { String msg = truncate(e.toString(), 1000); if (t.getRetryCount() + 1 >= t.getMaxRetry()) { // 进死信：状态置 4，由人工/补偿程序处理，同时发告警 jdbc.update(""" UPDATE t_task_queue SET status = 4, worker_id = NULL, claim_token = NULL, error_msg = ?, update_time = NOW() WHERE id = ? AND status = 1 """, msg, t.getId()); alarm.warn("task dead-letter, id={}, biz={}", t.getId(), t.getBizType()); } else { // 指数退避：1、2、4、8、16 分钟 long delayMin = 1L << t.getRetryCount(); jdbc.update(""" UPDATE t_task_queue SET status = 0, retry_count = retry_count + 1, next_execute_time = DATE_ADD(NOW(), INTERVAL ? MINUTE), worker_id = NULL, claim_token = NULL, error_msg = ?, update_time = NOW() WHERE id = ? AND status = 1 """, delayMin, msg, t.getId()); } } /** 僵尸回收：单独一个低频任务，每 5 分钟扫一次 */ @Scheduled(fixedDelay = 300_000) public void reclaimZombie() { int n = jdbc.update(""" UPDATE t_task_queue SET status = 0, worker_id = NULL, claim_token = NULL, retry_count = retry_count + 1, update_time = NOW() WHERE status = 1 AND update_time < DATE_SUB(NOW(), INTERVAL 10 MINUTE) """); if (n > 0) alarm.warn("reclaimed {} zombie tasks", n); } } ``` **⑤ 数据量大之后怎么办（追问必到）** | 问题 | 处理 | |---|---| | 表涨到几千万行 | 按 `create_time` 做**分区表**（MySQL RANGE 分区按月）；或按 `biz_type` 拆表 | | 已成功的任务占空间 | 定时归档：`status=2` 且 7 天前的搬到 `t_task_queue_history`（先 INSERT SELECT 再 DELETE，分批 5000 条，避免长事务锁表） | | 领取变慢 | `idx_poll (status, next_execute_time, id)` 必须命中；`EXPLAIN` 要看到 `type=range`，不能是全表扫 | | 多实例抢同一批 | CAS/claim_token 已保证不重；但要确认**没有把 `SELECT` 写成快照读后直接更新**（那是漏洞） | | 任务本身很大（跑批、报表） | 任务表只存「调度信息 + 参数」，大结果写文件/对象存储；单任务拆成子任务表，支持分片并行 | | 需要可视化 | 加一个管理页：按状态统计、手动重放死信、手动置成功。**这是这套方案胜过 MQ 的地方——可查可改** | **⑥ 这个方案的优劣（一定要主动说，否则像在硬吹）** | 维度 | 评价 | |---|---| | 一致性 | **最强**。任务状态和业务数据在同一个库、同一个事务里，天然一致 | | 可运维 | **最强**。一个管理页就能查、能改、能重放，MQ 里做不到 | | 可追溯 | **最强**。每条任务都有完整生命周期记录 | | 吞吐 | **弱**。单表抢占靠行锁，万级/秒就吃力（实测单实例每秒几百到一两千条，取决于行宽和索引） | | 实时性 | **弱**。轮询间隔决定延迟下限（1 秒轮询 = 平均 500ms 延迟） | | 对数据库的压力 | **大**。轮询本身就是持续写压力，高峰期会和业务 SQL 抢资源 | | 合规 | **最好**。库是名录产品，不引入任何中间件 | **一句话结论（可以直接说出口）**：**「任务表适合『量中等、要可查可改、强一致、不能引中间件』的场景，典型就是政企/金融的批量与工单；不适合高吞吐的实时消息，那是 MQ 的活。」** #### 9.11.6 补充第三条路 · 进程内 / 文件队列（以及它们的适用边界）除了 Redis 和数据库，还有一条更轻的路——**进程内队列**。它解决的不是「跨服务」，是「单机内的削峰和异步」。 | 方案 | 实现 | 特点 | 适用 | 不适用 | |---|---|---|---|---| | `ArrayBlockingQueue` + 线程池 | JDK 自带 | 有界、阻塞、零依赖 | 单机异步任务、限流缓冲 | 重启即丢，不能跨进程 | | `Disruptor` | LMAX 开源，RingBuffer + 无锁 CAS + 批量消费 | **极快**（单机千万级/秒）、无 GC 压力（预分配） | 高频行情、日志异步落盘、单机内极致吞吐 | 队列满时的丢弃策略要自己定；复杂度高 | | `Chronicle Queue` | 开源，堆外内存映射文件 | **持久化**到磁盘文件、进程重启可恢复、微秒级延迟 | 单机持久队列、低延迟日志 | 单机文件，不能跨机器；商业版收费 | | 本地文件 + 状态文件 | 自研（写临时文件 → 原子 rename → 处理完删除） | 最简单，能扛重启 | 极低频、量小的兜底（如离线补数据） | 并发控制、清理都要自己写 | | 数据库 + 触发器/存储过程 | 触发器里写队列表 | 业务写入和入队在同一事务 | 老系统改造、不想改应用代码 | **强烈不推荐**：触发器难调试、难迁移（信创换库时触发器官网语法差异大）、隐式开销不可控、容易死锁 | **Disruptor 为什么快**（如果被问到，一句话就够）：用 RingBuffer 预分配对象避免 GC、用 CAS + 内存屏障替代锁、用「序号屏障」让生产者和消费者无锁协同、支持批量消费。**代价是它不持久化、不支持跨进程**——所以它是「性能工具」，不是「消息中间件」。 **存储过程/触发器的边界**：在存量系统改造里，老系统确实有「插入订单表 → 触发器写队列表」的设计。信创迁移时这类逻辑是**重灾区**：Oracle 的 PL/SQL 到 DM 的 DM SQL、到金仓的 PL/pgSQL，语法差异大，调试困难，而且触发器里的异常会影响主事务。**改造建议是「把触发器逻辑上移到应用层」**，而不是逐行翻译。 #### 9.11.7 信创改造项目实际会做什么（面试最想听这一段）面试官说「我们 20 年左右上线的系统要强制做信创改造，存量项目面临大改或阶段性逐步改造」。他其实在试探：**你知道改造具体是什么活吗？** 这一段按实际工序讲，一共八步： | 步骤 | 具体做什么 | 关键产出 / 坑 | |---|---|---| | **① 现状盘点** | 梳理技术栈：OS 版本、JDK 版本、数据库产品与版本、中间件、依赖的第三方组件（含加密机、报表工具、License 服务） | 最容易漏的是「隐式依赖」：某个 jar 里硬编码了 Oracle 驱动、某个报表工具只支持 SQL Server | | **② 兼容性评估** | 用厂商工具跑一遍（达梦 DTS / DMC、金仓 KDTS / KMA 迁移评估），产出「不兼容对象清单」 | 评估报告要按「必须改 / 建议改 / 可保留」分级，否则工作量估不准 | | **③ 数据库替换** | 建库建表 → 数据迁移 → 增量同步 → 灰度切换 | **建库参数一旦定下不能改**（尤其大小写敏感），这是最容易翻车的一步 | | **④ SQL 方言适配** | 分页、函数、自增、字符串拼接、空串语义、日期格式、`GROUP_CONCAT` | 见 9.11.8 差异表，逐条过 | | **⑤ 驱动与连接池替换** | `com.mysql.cj.jdbc.Driver` → `dm.jdbc.driver.DmDriver` / `com.kingbase8.Driver`；改 URL、schema、连接池参数（`validationQuery` 要跟着换） | 连接池的 `validationQuery` 从 `SELECT 1` 改成 `SELECT 1 FROM DUAL`（Oracle 系要 DUAL） | | **⑥ 存储过程 / 触发器 / 视图重写** | PL/SQL → DM SQL / PL/pgSQL | 工作量最大的部分，建议**能上移到应用层的就上移**，别逐行翻译 | | **⑦ 中间件替换** | Tomcat → TongWeb/Apusic/BES；Nginx → TongHttpServer；MQ → 国产 MQ 或**去掉 MQ 改任务表** | 应用服务器的 `web.xml`、JNDI 数据源配置要重配 | | **⑧ 性能回归 + 上线** | 全链路压测、慢 SQL 复查、执行计划对比、双跑对账 | **执行计划会变**：统计信息、优化器不同，MySQL 上跑 50ms 的 SQL 到达梦可能 500ms，必须重跑 `EXPLAIN` | **几个只有真做过才知道的坑（说出来直接区分层次）**： 1. **空串 vs NULL**：MySQL 里 `''` 是空串，Oracle 系（含达梦 Oracle 兼容模式）里 `''` **就是 NULL**。所以 `WHERE name = ''` 在两边结果不同，`NOT NULL` 约束下插入 `''` 一边成功一边报错。**这是迁移第一大坑，能举这个例子胜过说十句「有方言差异」。** 2. **大小写敏感性**：达梦建库时可指定 `CASE_SENSITIVE`，**建完不能改**；金仓默认大小写敏感（加引号的标识符区分大小写）。MySQL 表名是否敏感取决于 `lower_case_table_names`。所以原来 `select * from User_Info` 能跑的，到达梦可能报表不存在。规避办法：**统一小写下划线命名 + 不使用引号包裹标识符**。 3. **分页**：MySQL `LIMIT offset, size`；达梦 8 支持 `LIMIT` 也支持 `ROWNUM`，Oracle 兼容模式下建议用 `ROWNUM` 或 `OFFSET ... FETCH`；金仓（PG 系）支持 `LIMIT ... OFFSET`。MyBatis 的 `PageHelper` 里有 `helperDialect`，**必须改成 `dm` / `kingbasees`**，否则生成的分页 SQL 直接报错。 4. **函数替代清单**：`IFNULL` → `NVL`/`COALESCE`；`NOW()` → `SYSDATE`/`CURRENT_TIMESTAMP`；`DATE_FORMAT(d,'%Y-%m-%d')` → `TO_CHAR(d,'YYYY-MM-DD')`；`GROUP_CONCAT` → `WM_CONCAT`（DM）/ `STRING_AGG`（金仓）；`FIND_IN_SET` 两家都没有，得自己写函数或用 `LIKE` 改写；`LIMIT` 在子查询里的用法差异。 5. **自增主键回填**：MySQL 的 `AUTO_INCREMENT` + `getGeneratedKeys()` 在达梦 `IDENTITY` 上要确认驱动支持；金仓用 `SERIAL` 或 `IDENTITY`。**批量插入要拿主键的地方，迁移后必须单独验证**，否则会静默拿到 null。 6. **字符集**：MySQL `utf8mb4`；达梦默认 UTF-8（也支持 GB18030）；金仓 UTF-8。**emoji 和生僻字**在 GB18030 库上可能丢，要确认建库字符集。 7. **事务默认行为**：MySQL 默认 `autocommit=1`；达梦默认也是自动提交（可用 `SET AUTOCOMMIT OFF` 改）；**Oracle 兼容模式下部分语义偏向 Oracle**（比如某些 DDL 隐式提交）。迁移后要复查「依赖自动提交」的代码。 8. **批量操作**：MySQL 支持 `INSERT INTO t VALUES (...),(...),(...)` 多值插入，达梦在 MySQL 兼容模式下支持、Oracle 兼容模式下要用 `INSERT ALL` 或 JDBC batch。MyBatis 的 `foreach` 批量插入**在达梦上可能要改写成 JDBC batch**，这是性能优化点。 #### 9.11.8 达梦 / 人大金仓与 MySQL 的关键差异（补到能聊） > 他在真实面试里只说「接触过达梦但不太了解」。下面这张表背下来，下次至少能聊五分钟。 | 对比项 | MySQL 8.0 | 达梦 DM8 | 人大金仓 KingbaseES V8 | |---|---|---|---| | 血统 | 自有 | **Oracle 兼容度高**（DM SQL） | **PostgreSQL 基因** + Oracle/MySQL 兼容模式 | | 默认端口 | 3306 | 5236 | 54321 | | 安装形态 | 单机/主从/MGR | 单机/DMDSC 共享存储集群/DMRWC 读写分离 | 单机/主备/读写分离集群 | | 默认字符集 | utf8mb4 | UTF-8（可选 GB18030） | UTF-8（可选 GBK） | | **标识符大小写** | 表名依 `lower_case_table_names`（Linux 默认 0 = 敏感）；列名不敏感 | **建库时 `CASE_SENSITIVE` 决定，建后不可改**；默认敏感 | 默认敏感（双引号包裹时严格区分） | | **空串与 NULL** | `''` 是空串，`'' <> NULL` | Oracle 兼容模式下 **`''` 等同 NULL** | `''` 是空串（PG 系语义） | | 分页语法 | `LIMIT offset, size` | 支持 `LIMIT`；Oracle 模式用 `ROWNUM` / `OFFSET...FETCH` | `LIMIT size OFFSET offset` | | 自增主键 | `AUTO_INCREMENT` | `IDENTITY(1,1)`（也兼容 `AUTO_INCREMENT`） | `SERIAL` / `IDENTITY` | | 字符串拼接 | `CONCAT(a,b,...)` 多参 | `||`；`CONCAT` 只吃两参 | `||`；`CONCAT` 多参 | | NULL 处理函数 | `IFNULL` / `COALESCE` | `NVL` / `COALESCE`（`IFNULL` 兼容模式下可用） | `COALESCE`（部分版本有 `NVL`） | | 日期格式化 | `DATE_FORMAT(d,'%Y-%m-%d')` | `TO_CHAR(d,'YYYY-MM-DD')` | `TO_CHAR(d,'YYYY-MM-DD')` | | 分组拼接 | `GROUP_CONCAT(x)` | `WM_CONCAT(x)` / `LISTAGG` | `STRING_AGG(x, ',')` | | 当前时间 | `NOW()` / `CURRENT_TIMESTAMP` | `SYSDATE` / `CURRENT_TIMESTAMP` | `NOW()` / `CURRENT_TIMESTAMP` | | 引号 | 反引号 `` `col` `` | 双引号 `"col"`（且会变敏感） | 双引号 `"col"` | | 存储过程语言 | SQL/PSM | **DM SQL**（PL/SQL 风格） | **PL/pgSQL** | | 默认隔离级别 | REPEATABLE READ | READ COMMITTED | READ COMMITTED | | 默认提交方式 | autocommit=1 | 自动提交（可关） | 自动提交 | | 多值 INSERT | ✅ `VALUES (...),(...)` | MySQL 兼容模式下支持；Oracle 模式用 `INSERT ALL` | ✅ 支持（PG 语法也支持） | | JSON 支持 | JSON 类型 + 函数 | 大字段 + 部分 JSON 函数 | **JSONB（PG 基因，能力强）** | | 窗口函数 | 8.0 起支持 | 支持 | 支持 | | 驱动类 | `com.mysql.cj.jdbc.Driver` | `dm.jdbc.driver.DmDriver` | `com.kingbase8.Driver` | | JDBC URL | `jdbc:mysql://h:3306/db` | `jdbc:dm://h:5236/SCHEMA` | `jdbc:kingbase8://h:54321/db` | | 层级概念 | database → table | **用户即模式（SCHEMA）**，`模式.表` | database → schema → table | | 迁移工具 | mysqldump | **DTS / DMC**（达梦迁移工具） | **KDTS / KMA**（迁移评估） | | 典型客户 | 互联网 | 银行、政务、电力 | 政务、金融、能源 | **「模式（Schema）」这个差异要单独说**：Oracle 系和达梦都是「用户 = 模式」，连接串里指定的是模式名（通常大写），表在 `模式.表名` 下；MySQL 的 `database` 概念更接近。所以 `jdbc:dm://host:5236/BILLING` 里的 `BILLING` 是**模式名**，不是库名——这个说错很容易被听出来。 **迁移注意事项（按发生概率排序，这是能直接抄的 checklist）**： 1. **先定建库参数**（大小写敏感、字符集、兼容模式），定完不可改；决定了后面 80% 的适配工作。 2. **SQL 全量扫描**：用 `grep` 或厂商工具扫出所有 `LIMIT`、`IFNULL`、`DATE_FORMAT`、`GROUP_CONCAT`、反引号、`INSERT IGNORE`、`ON DUPLICATE KEY UPDATE`（这两条国产库普遍不支持，要改成 `MERGE` 或先查后写）。 3. **`ON DUPLICATE KEY UPDATE` 是硬伤**：MySQL 特有语法。达梦/金仓用 `MERGE INTO ... USING ... WHEN MATCHED THEN UPDATE WHEN NOT MATCHED THEN INSERT`，语法完全不同，**这条在改造里出现频率极高**（幂等写入都靠它）。 4. **`INSERT IGNORE` 同理**，要改成 `MERGE` 或捕获唯一键异常。 5. **分页插件方言**：PageHelper 的 `helperDialect=dm/kingbasees`，MyBatis-Plus 的 `DbType.DM / KINGBASE_ES`。 6. **执行计划复查**：迁移后**必须重跑关键 SQL 的 `EXPLAIN`**，统计信息要重新收集（达梦 `SP_TAB_STAT_INIT`、金仓 `ANALYZE`）。MySQL 上走索引的，到达梦可能因为统计信息缺失走全表。 7. **性能回归**：建一套基准 SQL 集（几十条核心 SQL），迁移前后各跑一遍对比耗时，出报告。**这是甲方最看重的交付物。** 8. **双跑对账**：新旧库并行一段时间，定时比对关键表的行数、金额汇总、抽样明细，一致后才切。 **面试口述版（这段是可以直接背下来救场的话）**： > 达梦和人大金仓我都接触过，主要是迁移适配这一层，不是调优专家，但差异点比较清楚。 > 达梦是 Oracle 兼容路线，模式概念、`NVL`、`TO_CHAR`、`WM_CONCAT`、`ROWNUM` 这些都是 Oracle 那套，所以从 Oracle 迁达梦相对顺，从 MySQL 迁就要改不少函数和分页。人大金仓是 PG 基因，`LIMIT/OFFSET`、`STRING_AGG`、`JSONB` 这些是 PostgreSQL 的，它对 MySQL 的兼容模式也能开，但我不建议长期依赖兼容模式，还是按原生语法写更稳。 > 最容易踩的三个坑：一是**空串语义**，MySQL 的 `''` 是空串，达梦 Oracle 兼容模式下 `''` 等于 NULL，`WHERE x = ''` 结果不一样；二是**大小写**，达梦建库时定死大小写敏感，建完不能改，所以上线前一定要确认建库参数，代码里统一小写下划线；三是 **`ON DUPLICATE KEY UPDATE` 和 `INSERT IGNORE` 这些 MySQL 特有语法国产库没有**，得改成 `MERGE`，这个在我们幂等写入的地方改得最多。 > 另外迁移后一定要重跑执行计划、重新收集统计信息，MySQL 上 50 毫秒的 SQL 到达梦可能变 500 毫秒，不做性能回归上线就炸。 #### 9.11.9 这一题完整的接法（被问「你接触过信创吗」时怎么答） **别再用「接触过达梦但不太了解」开场。** 换成这个结构，60 秒讲完，把主动权拿回来： > 接触过，主要是数据库替换这一层的适配。我理解信创本质是用国产软硬件替换掉 Intel + Oracle/Windows 这套底座，分七层：芯片、整机、操作系统、数据库、中间件、云、办公套件。芯片是鲲鹏飞腾龙芯海光申威，OS 是麒麟和统信 UOS，数据库是达梦、人大金仓、OceanBase、GaussDB 这些，中间件是东方通、金蝶、宝兰德、中创，办公是 WPS。 > > 我实际做过的是 MySQL 到达梦/金仓的适配：函数改写、分页方言、大小写和空串语义、`ON DUPLICATE KEY UPDATE` 改 `MERGE`，还有迁移后重新收集统计信息做性能回归。 > > 中间件这块我有个明确判断：像 RabbitMQ、Kafka、Redis、Nginx 这些社区件不在名录里，原因是主体不在国内、许可可能变、没有厂商兜底。所以新项目要么用国产替代——Redis 有东方通 TongRDS、华为云 DCS，Tomcat 有 TongWeb、Apusic、BES；要么干脆不引中间件。比如队列，如果没有 MQ，我会用两条路：量不大、要低延迟就用国产 Redis 协议产品做 Stream 消费者组，带 XACK 和 XAUTOCLAIM 保证不丢；要强一致、要可查可改，就用数据库任务表，状态字段加 version 做 CAS 抢占，失败指数退避，超阈值进死信表人工处理——这条路最大的好处是库本来就在名录里，不用引任何中间件，金融的批量跑批很多就是这么做的。 **为什么这个回答有效**：它在 60 秒里给出了 ① 定义 ② 分层名录 ③ 真实做过的事 ④ 对「为什么不在名录」的判断 ⑤ 两个可落地的替代方案。面试官无论从哪一层往下追问，都有东西可接——**这就是「准备过」和「临场想」的区别**。